Jamtronix

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 M/L 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)  

*  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.

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
• No buffering - the “tcp_send” command won’t return to the caller until the other side has ACKed the data that was sent.

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).

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.

• Splitting Apart the Split Screen - The Journey to Find, Analyze, and Fix Pac Man’s Split Screen

• Bride of Kill Screen - The Journey to Find, Analyze, and Fix Ms. Pac Man’s Kill Screen

• Galaga’s Stage 0 Analyzed and Fixed - Patching Galaga’s Kill Screens

• How Deep Can You Dig Dug? - A Complete Analysis and Patching of Dig Dug’s Kill Screen

• Defender’s Extra Life Bonanza

• Secret Bonus Number 01 - Finding the long-lost secret bonus in Astro Blaster

• How High Can You Get? - Fixing Donkey Kong’s Kill Screen

This is my first post with wordpress - I’ve shifted over from movable type as part of a move to a new hosting provider.  There were two motivations for shifting - firstly, the provider I’d previously been hosting peekbot on seems to have recently done some kind of upgrade, at the end of which peekbot stopped working (specifically, the X-Sendfile feature in apache, which peekbot uses heavily, was broken - all files seemed to be prepended with a CR/LF which made (for example) png files unviewable). The second motivation was, I wanted to host a public ‘netboot65‘ server. This needed a clear (no firewall) channel to port 69 (tftp port) and root access to bind to said port, which wasn’t available on my previous shared server host.

So I’ve shifted to linode which seems pretty darn good. But I haven’t been able to get my public netboot65 server working - I can send & receive individual files OK, but I never get a response to a directory listing, even though I can see (via Wireshark on my PC, and tcpdump on the remote host) that the directory requests are getting to the server, and a response is being sent out. I believe now that my broadband router is discarding these responses, although oddly enough file transfers in both directions work fine. I suspect the problem will turn out to be due to NAT issues - in the tftp protocol the udp port that the server uses when sending stuff back to the host is not the same as the udp port that the client sends the original request to (read last part of section 15.3 of TCP Illustrated Vol 1 for an explanation of why) so the router needs to be a bit clever about how it matches up inbound packets (with the NATed host. It may well be that whatever trickery my router uses to know when to do some special handling for tftp requests only kicks in when the tftp opcode is a read or write. I could probably set up some custom NAT rules on my router and make it work, but then anyone else wanting to try netboot65 would need to do the same, which will be a drag, so I think the right thing to do is move away from using a custom opcode for directory listings, and instead use a RRQ but a special filename, e.g. “$.prg” for a directory listing of all .prg files.

I’ve been working on an update to netboot65, with an aim to getting a ‘1.0′ release out when the first lot of 64NIC+ carts go out.

The 64NIC+ cart is a project initiated on retrohackers.com that offers an RR-NET compatible ethernet interface, plus a 16KB EPROM socket. There seems to be a nicely symbiotic relationship between this cart and netboot65 - the latest netboot65 release will include an 8KB image that can be burned into an EPROM (probably with CBM BASIC in the upper 8KB) that 

• allows any ’single load’ program (up to about 47KB in size) to be downloaded via TFTP and immediately executed,
• provides an API (called the NB65 API) that programs can use to write UDP based applications without being tied to a specific MAC and IP address, or a specific device type ( the A2 and C64 IP libraries I am familiar with are all tied to a single device type and all require each program to specify MAC and IP address). If this API gets some support, that may encourage future development of different network interfaces that are not simply cs8900a based RR-NET clones (for example, a wifi cart would be nice).

The API is documented as a word doc in the NB65 API Technical Reference

I’ve just made a new ip65 release available for download from sourceforge

ip65 is an IP stack for 6502 based computers, with support for UDP/DHCP/DNS & TFTP, but not yet TCP .

Recent changes:

• I’ve taken over maintenance responsibility from Per Olofsson
• New project homepage - http://ip65.sourceforge.net/
• ‘ip65 technical reference‘ documentation (auto-generated from source code comments)
• Added support for DHCP, DNS and TFTP

• Stanford Advanced Logic Design Laboratory - tutorials, course notes, verilog crib sheet - excellent resources, slightly dated (2003)
• FPGA 4 Fun - great site, easy to understand theory + lots of examples
• Wikipedia articles on FPGAs and Verilog
• Digilent - cheap and good starter boards
• Xilinx download page - ISE webpack is a free IDE for FPGA development
• OPENCORES  - open source hardware, mix of Verilog & VHDL designs (free rego required to download any files)
• WISHBONE - open ’system on a chip’ bus (for connecting different FPGA modules in a single project).  Hosted by OPENCORES, so you need to sign in to d/l anything including the WISHBONE spec.
• FPGA Arcade - recreating gaming hardware from the past in  FPGAs
• ZXGATE -Old Computers in new FPGAs
• Accolade VHDL Reference Guide

I’ve just released version 0.7.2 of ripxplore (a command line tool and supporting ruby library for exploring disk images for Apple 2, C64, TRS-80, et al).

The major change was to incorporate the create/update/delete features from my previous ‘dsktool’ project. This means Apple DOS and Apple CPM file systems can be initialised and files added or removed from it. I’ve also added the ability to create a blank ‘Beautiful Boot‘ dsk image. As an example of how and why this is done, here’s an excerpt from the Makefile used to build a dsk with differest test apps on it I’m using to test different parts of the netboot65 code:

ip65test.dsk: testdns.pg2 testdottedquad.pg2
  ripxplore.rb –init BeautifulBoot ip65test.dsk -a testdns.pg2 -t AppleBinary
  ripxplore.rb ip65test.dsk -a testdottedquad.pg2 -t AppleBinary

If you’ve installed a previous version of ripxplore, you can update to 0.7.2 by typing ‘gem update ripxplore’ at a command prompt.

If you want to install ripxplore for the first time, you will first need to install ruby then once ruby is installed correctly, type ‘gem install ripxplore’ at a command prompt.

rands makes a frank disclosure : My management career began with a misunderstanding.

Deckard dissects Beautiful Boot  (in french, here’s the google translation)

The Jamtronix Wordle: