Jamtronix

January 25, 2010

do the petsciimation

Filed under: c64 — jonno @ 10:48 am

What happened was, I got the telnet client in KipperTerm working pretty good, so I decided there needed to be something interesting to telnet to from a c64.

petsciimation2
So I’ve set up the ‘petsciimation’ server, for indulging in video piracy the old-fashioned way. What you do is, use a telnet client that understands PETSCII,  like KipperTerm (for a C64) or CGTerm (on anything built this millenium), and connect to port 6464 on jamtronix.com.

Then sit back, and relax, as the movie of your choice scrolls by, character after character, byte after byte, 80s BBS culture reference after 80s BBS culture reference.

Or not.

petsciimation1

 

Thanks to schema and rob for passing on the warez.

November 29, 2009

XMODEM in ruby

Filed under: Uncategorized, ruby, vintage — jonnosan @ 4:10 am

I’m working on adding support for XMODEM file transfers to KipperTerm, and I needed something to act as the “other end” of the XMODEM transmission. Obviously I could have used a real BBS, but that would have a pain to set up, plus the typically convoluted login/file selection process would have made the test itself quite cumbersome. So I decided to put together a simple ruby server that would accept telnet connections and just require transmission of a single character to start dishing out a file via XMODEM.

Unfortunately there didn’t seem to be any existing ruby implementations of XMODEM. So I have released a gem called “modem_protocols” – currently only XMODEM is implemented, although I may add ZMODEM support over Christmas.

The API is pretty simple – you  call “xmodem_tx” or “xmodem_rx” to send or receive a file respectively. Each function takes two IO objects – the “remote” object will typically be a TCP session or serial port connection, and the “local” object will typically be a file. The XMODEM protocol is spoken over the “remote” connection, and the file being transmitted is read from/written to the “local” connection.

Here’s the ”dummy BBS” I am using. In this case, I am using “StringIO” objects rather than ”File” objects on the ”local” side, but it should give you the flavour.

require 'modem_protocols'

LOCAL_PORT=1000

Thread.abort_on_exception = true
BasicSocket.do_not_reverse_lookup=true
ModemProtocols::logger.outputters = Outputter.stdout

def run_server
  server = TCPServer.new( LOCAL_PORT)
  loop do 
    puts "listening"
    begin
      session = server.accept
      puts "connected"
      command=nil
      loop do
        session <<"will you (R)eceive, (S)end with standard XMODEM, or send via XMODEM-(C)RC16 (R/S/C)?\r\n"
        command=session.readchar.chr.downcase
        break if ['c','s','r'].include?(command)
        session << "invalid option #{command}\r\n"
      end
     
     
      case command
        when 'c' then
          file=StringIO.new("")
          session << "start sending now\r\n"
          ModemProtocols::xmodem_rx(session,file,{:mode=>:crc})
          session <<  "rx complete\r\n"
          file.rewind
          puts file.read

        when 's' then
          file=StringIO.new("")
          session << "start sending now\r\n"
          ModemProtocols::xmodem_rx(session,file)
          session <<  "rx complete\r\n"
          file.rewind
          puts file.read
        when 'r' then
          file=StringIO.new("this is a test\n"*100)
          session << "start receiving now\r\n"
          ModemProtocols::xmodem_tx(session,file)
          session <<  "tx complete\r\n"
          file.rewind

      end   
      session.close
    rescue Exception=>e
      puts e
      puts e.backtrace
    end
  end
end

server_thread=Thread.new {run_server}
loop do
  break unless server_thread.alive?
  sleep(0.1)  #wake up occasionally to get keyboard input, so we break on ^C
 end

 

August 2, 2009

Future retro challenge – resurrect the Senior PROM?

Filed under: apple ii, retrochallenge — jonnosan @ 4:13 am

About 2 years ago I got interested in “copy cards” for the Apple 2. These are cards that have a button that when it is pressed while make a snapshot of RAM on disk. This lets an executing program be ‘frozen’ and then later restored. The ‘legitimate’ use of these cards is to allow people to save a game at any point, and come back and play it later. The obvious illegitimate use of these sorts of cards is it makes it  easy to make a copy of a game or other program.

These cards are not 100% effective, e.g. they won’t work if a program loads data from a protected disk between levels, but are nevertheless interesting. There is also a lot of overlap between this sort of “copy card”, home made “crack roms”, and legitimate “debugging” cards or ROMs.

Some examples :

As far as I know, there has never been any attempt to recreate any of these devices for the Apple 2 (c.f. the C64 which has the Retro Replay, a clone of the “Action Replay” )

In late 2007, Mike Maginnis (who hosts the magnificent Hardcore Computist archive) and Bill Garber (of garberstreet electronics) made available a scan of manuals and eprom images for Mike’s Senior PROM (accessable from the ‘download’ link Bill’s website, also mirrored here.

The EPROM images came from the version of the Senior PROM built for a beige //e, i.e. for motherboards where there is 1 ROM holding AppleSoft BASIC (residing in $D000..$DFFF) and another ROM holding the Monitor (residing in $E000..$FFFF).

The original Senior PROM consisted of a circuit board that plugged in the place of these 2 chips, and also included a wire that was to be clipped directly onto pin 6 (/NMI) on the 65c02 on the main board. That circuit board also included a button and a 3 position switch.

In the 1st position, the ‘normal’ BASIC & Monitor ROM code is  ative.
In the 3rd position, the special ‘Senior PROM’ code is active – this allows access to utility routines e.g. to save all or part of RAM, a disassembler, a sector editor etc.
In the2nd (middle) position, the system boots as normal, but activates the ‘Senior PROM’ code when the pushbutton is pressed (i.e. at the same time as an NMI is generated).

Since this circuit plugs straight in to EPROM sockets on the motherboard, it was pretty easy for me to replicate (I really only know how to make ‘dead bug‘ style circuits, the PCB fabrication necessary for making a card that plugs into an expension slot is beyond me).

Since I was using a ‘platinum’ //e which has a single EPROM for $D000..$FFFF) I needed to merge the 2 seperate .bin files into a single file ( available here ). Then I burned that merged file into a 27256 that had a toggle switch wired up to A15, and hooked a debounced pushbutton up to the /NMI pin on the 65c02.

This let me boot a single load program using the normal A2 ROM, then flip the toggle switch and trigger an NMI and get into the Senior PROM utilities.

Which was cute, but I was hoping to be able to actually generate a ‘resurrect’ disk, i.e. copy a running program to disk in a way that it could be restarted. Unfortunately the Senior PROM needs a seperate utility disk when it is making the ‘resurrect’ disk, and there didn’t seem to be a copy of that disk available.

There were copies of some versions of the Senior PROM utilities, but they were from different versions of the Senior PROM than the version I had the EPROM image of, and were incompatible. Despite a few plaintive posts on CSA2, I wasn’t able to ever find a matching set of EPROM images and disk images that were from the same version of Senior PROM.

So I gave up.

But just recently, Mike passed on a copy of a Senior PROM utility disk that is from version 3.0 of the Senior PROM which is not quite the same version number as the EPROM image (that is 3.01) but it’s very close and so there’s a good chance they are compatible.

Unfortunately I don’t have access to my old circuits or a workspace to build a new version and test this out in. So I’m posting this in the hope that someone may be interested enough to put together the necessary circuit and see if we really do have a winning combination. Which would be nice!

July 31, 2009

retro challenge roundup

Filed under: apple ii, retrochallenge — jonnosan @ 2:37 pm

In at least some parts of the world, it’s still July 31, so I’ll claim this Apple 2 gopher client as being a 1.0 release within the Retro Challenge timeframe. A last minute change of platform, to be sure, mainly because gopher really needs 80 columns. Here’s a screenshot:

A2 Gopher Sreenshot 

To use -

  • You must have an Apple 2 with an uthernet in slot 3 (or at least an emulator like AppleWin), and a functioning DHCP server on your LAN.
  • Press up and down arrows (or ^P / ^N) to scroll up and down between pages.
  • Press TAB to enter a new gopher server (just the server name e.g. gopher.floodgap.com, not a full URL like gopher://gopher.floodgap.com and bad luck if you want to connect to a non-standard port)
  • Press the left arrow (or ^B) to go back to the previously visited location.
  • Press any letter displayed in inverse to navigate to to the adjacent resource (e.g. pressing’c’ in the screen shot above would take you to arfink’s gopher space)
  • There are lots of bugs/issues etc, the most notable being pages over 16KB will crash the client. But hey, at least I hit the launch date. And 16KB should be enough for anyone. Except maybe luddite.

Some reflections:

  • UI design is harder than implementation. I believe that the Mac was the first operating system to provide APIs for applications to use a standard “look & feel”. The coding I’ve done this month is the first major app I’ve ever done where I couldn’t take for granted widgets or common interface metaphors. And it sucks, both as a user and a developer.
  • Although the end product may resemble an authentic Apple 2 application, this was far from an authentic Apple 2 development process. Kudos to the chaps I met from MtKfest who do it “the hard way”. I never could have done this without a decent text editor, google to find RFCs, irc and newsgroups for instant answers to questions, an edit/assemble/execute cycle measured in seconds not hours and all the other conveniences that eliminate the accidental and let one focus on the essential 
  •  State Machines are both a marker and a reducer of complexity. If a design has a state machine, it’s probably solving a complex problem, but it will be simpler (and easier to write) than an alternative design solving the same problem with a diffuse and intertwined set of globals.

July 28, 2009

retro linkfest 2009-07-28

Filed under: retrochallenge — jonnosan @ 11:08 am

While researching the gopher protocol, I came across “who killed gopher?”. part of a series on “transfer protocols” written in the late 90s (i.e. the internet gold rush 1.0) by Rohit Kare.  The series also includes histories of Telnet, FTP,  SMTP, and a memorial to Jon Postel and NNTP.

On a vaguely related not, the latest post on almost-always-intriguing pagetable.com is a discourse on LOAD”$”,8 - the somewhat unusual method that C64s used to catalogue the contents of a disk.

Finally, here’s some links to blogs etc for some of my fellow (Mt)KFest attendees

July 27, 2009

retro challenge diary # 3

Filed under: retrochallenge — jonnosan @ 9:30 pm

 I have been making some progress. However I’ve tended to prioritise coding new features + attending Mt Keira Fest over posting here or packaging anything up for release. So for the moment you’ll just have to take my word (or look in the svn repository at  http://netboot65.svn.sourceforge.net/viewvc/netboot65/  ) when I say that current state of play is:

  • single TCP connections work, as either a client (connecting out) or a server (listening on a known port)
  • C64 Gopher client works for gopher resource types ‘0′ (plain text), ‘1′ (gopher resource directory) and ‘7′ (search). Biggest issue is it’s 40 columns only, and pretty much every gopger dir or text assums 70+ columns.
  • The Gopher clientcode  only needs a few hours (this weekend perhaps) to get it working on the Apple 2 as well. This will be an 80 column mode client.
  • Telnet works for ‘native’ mode (i.e. petscii on a C64), ‘line’ mode (similar to how netcat behaves – local echo, you can edit your line, nothing is actually sent till you hit return) or ‘ascii’ mode (each character is sent as soon as you hit a key, and characters are converted to/from 7-bit ASCII. This includes proper telnet negotiation (by which I mean, the client will respond to all DO or WILL requests, declining all of them except WILL SUPRESS GO AHEAD and WILL LOCAL ECHO).  What’s not implemented yet, and is probably needed before I can legitemately claim to have a real telnet client, is vt100 emulation.  That seems like a biggish job so I will wait till I can get a few days solid focus before attempting that.

Assuming I get a few hours this weekend, I will polish up what I have, with an aim of releasing an A2 disk with telnet and gopher clients, and a 16KB C64 cartridge image (suitable for use in a 64NIC+ ) with telnet, gopher, nb65 API and a few other bits & bobs.

July 5, 2009

retro challenge diary #2

Filed under: retrochallenge — jonnosan @ 11:55 am

Making good progress on implementing gopher - here’s a screenshot showing how  gopher://retro-net.org/ renders.

gopher screenshot

I’m cheating a little bit – the code above is rendering gophertext hardcoded into the app – once I have the parsing and navigation sorted I’ll wire it up to  fetch the gophertext from a remote server.

Parsing gophertext turned out to be pretty easy (I think that was in fact a design goal for Gopher).  The trickiest bit was writing a 6502 routine to multiply a 16 bit number with an 8 bit number (which I needed to be able to parse as integers the port number fields).

Gopher seems the perfect protocol for retro-computing. It’s simple –  if I can code a client in 6502 assembler, I think you could code it in anything. There are some “real” sites out there in gopherspace (many with a heavy retrocomputing slant) so once you’ve got your client working there’s something to do with it. And since gopher was designed for text-mode terminals, content is legible (compared with e.g. pointing lynx at a typical modern website – assuming the site works at all without javascript, often you have to scroll past a few screenfulls of navigation options before the actual content on each page).

I’m tempted to expose some services via gopher (an rss reader being an obvious candidate, also peekbot could work) but probably won’t get to do much more coding till next weekend.

July 4, 2009

retro challenge diary 1

Filed under: retrochallenge — jonnosan @ 5:41 am

I’ve got a rough skeleton of the TCP code working (for outbound connections only). That means TCP segments are sequenced correctly, ACKs  are sent when appropriate, and duplicate TCP packets are discarded.   I don’t think I’ve quit got the handling of FINs correct, and I’m sure there’s a few other bugs in there, but it is at least at the point where I can connect to port 80 of a webserver, send a GET request, and dump a few KB of raw HTML to the screen.

I’m definately doing this a lot easier than a 6502 hacker would have back in the day. Probably the  most significant advantage is the editing tool – I use the SciTE IDE (which comes with Ruby). I don’t have syntax highlighting set up, but I’d find it very painful to not be able to have multiple tabs & windows at once, plus find/replace. Also, when it comes to understanding what a big messy hunk of code does, it makes a huge difference how much of it you can see at once - SciTE on my laptop gives 40 lines of 100+chars. compared to 24 lines of 40 chars each on a real 64.

Also by using CA65 + make + some batch files to call Vice, the time from making a change to the source code to seeing the code run is seconds, vs tens of minutes if I was working on the real thing. Effectively I am able to  see the effects of code changes “in real time” - turnaround times that were only possible in BASIC when these 8 bit machines were around. Which is about the only nice thing that can be said about 8 bit BASIC . As much as I am enjoying relearning 6502 assembler, and as much fun as I had PEEKing, GOSUBing and FOR-NEXTing in the mid 80s, I have no desire whatsoever to read or write code with meaningless variable names and subroutines referenced by numbers.

Now that I think about it, the original 8-bit assemblers had much  more meaningful identifiers, and more legible comments, and hence (I suspect) more maintainable source code than a typical pre-90s era BASIC did.

Case in point – here is the first 6 lines from a Memory Game for the Tandy Color Computer   (picked at random via the Peekbot Random Listing feature)

10 GOTO1380
20 CLS0:CLEAR200:DIMS(12,12),F(24),PP(24):T=RND(-TIMER):B$=STRING$(4,32)
30 'title page
40 FORT=1024TO1055:POKET,159:POKET+480,159:NEXT:FORT=1056TO1472STEP32:POKE
T,159:POKET+31,159:NEXT:FORT=1090TO1117:POKET,255:POKET+352,255:NEXT:FORT=
1122TO1442STEP32:POKET,255:POKET+27,255:NEXT
50 T$="MEMORY GAME":FORT=1TOLEN(T$):POKE1187+T*2,ASC(MID$(T$,T,1))AND63:
PLAY"L255CDEF":NEXT
60 T$="BY * BOB VAN DER POEL":FORT=1TOLEN(T$):POKE1381+T,ASC(MID$(T$,T,1))
AND63:PLAY";"+STR$(RND(12)):NEXT 

WTF? The comment gives a clue that this is a title page, but there’s so much packed into each line, and so many variables with meaningless names, my brain hurts thinking about how you would make changes.

Compare this to an extract from the 6502 assembler from Mrs Pacman (one of many Atari 7800 game sources recently released) . It may or may not help to know that in 6502 assembler ”JSR” is “Jump to SubRoutine” (i.e. call subroutine), “LDX” means “LoaD the X register with the following value”, “INX” means “Increment the X register”,  “CPX” means “Compare the X register with the following value” and “BMI” means “Branch (jump to) the specified location if the result of the previous comparison was a negative number”.

*  TITLE.S        ROUTINES TO CONTROL THE TITLE PAGE
*  THIS IS THE ENTRY ROUTINE.  IT DOES ALL THE WORK.
DOTITLE   JSR     TITLESET               ;DO BASIC SETUP
          JSR     INITSTMP               ;INITIALIZE THE STAMPS
          LDX     #$00
DTLOOP    JSR     WRTNAME                ;WRITE THE MONSTER'S NAME
          JSR     TMOVEMON               ;MOVE THE MONSTER
          INX                            ;GET THE NEXT ONE
          CPX     #$04
          BMI     DTLOOP
          JSR     WRTPNAME               ;WRITE MS PAC-MAN'S NAME
          JMP     TMOVEPAC               ;MOVE HER

So yeah, BASIC sux0rs, ASM rux0rs.

Anyway, making reasonable progress, might raise the bar a bit and aim for a gopher client by kfest.

June 28, 2009

tcp ambitions

Filed under: retrochallenge — jonnosan @ 11:07 am

I’ve decided to have a crack at RetroChallenge 2009 - my project will be to add TCP to the ip65 IP stack for the C64 and other 6502 computers.

I’ve made a bit of progress already (visible in the netboot65 SVN repository).  I’ve made a few design compromises – these are more the result of limitations in the language of choice (6502 assembler) rather than the C64 itself, as proven by the existance of uIP -  a full featured TCP/IP stack (written in C) for that includes the C64 in its many targets.

Here’s the shortcuts I’m taking:

  • Only a single TCP connection can be active at once (but can be initiated in either direction)
  • No IP fragment reassembly (does this matter? I just ran “netstat -s” on my laptop, it told me since last reboot it has received 388800 IPv4 packets, of which 0 required reassembly)
  • No buffering – the “tcp_send” command won’t return to the caller until the other side has ACKed the data that was sent.
  • TCP checksums are calculated for outbound, but not checked for inbound.

Only allowing a single TCP connection to be active at once makes the coding much much easier and as far as I can determine, the only application that would be renderd impossible as a result is FTP (which uses 1 connection for commands, and a seperate connection for data).

May 9, 2009

Filed under: Uncategorized — jonno @ 12:25 pm

I came across Don Hodges’ website, which is one of those that divide the world in 10 kinds of people (those that understand binary, and those that don’t). I’m going to skip over his commentary on George Bush and get straight to the good bits, scholarly dissections (with bugfixes!) of kill screens and other ‘undocumented features’ of  primordial video games.

Older Posts »

Powered by WordPress