It’s just about the end of July, and while I haven’t accomplished everything I wanted for my Retrochallenge project, I have reached a good place to conclude. It’s been fun and challenging and occasionally frustrating – but definitely worth it. Most of all, I got stuff to work, and that makes me very happy.
Once I got my 6502 to talk to the Arduino and read data back from the SD card, I had to integrate all that code into the P:65’s primitive operating system, which lives in an 8 KB EEPROM. Shortly before the Retrochallenge started, I wrote a program that let the P:65 download and rewrite the EEPROM itself. It’s a lot easier than pulling the EEPROM out and sticking it in my homemade programmer every time I make a change.
The first time I tried that, I wrote a ROM image that was so bad the poor thing couldn’t even boot up again afterwards. It turned out my linker configuration was screwed up, and it put the “.rodata” section in front of where the code was supposed to start, and the EEPROM burner code proceeded to put everything in the wrong place.
Even when the code was right, sometimes I’ve been wrong. Several times now I’ve accidentally flashed the EEPROM with the wrong data file. In particular, at least once I’ve overwritten my operating system with the code for the EEPROM burning utility itself. This… did not work.
As for the actual software (all written in 6502 assembly), I’m happy to say that most of my bugs have turned out to be simple ones. That doesn’t mean they were easy to track down, by any means, but once they were identified they were easy to fix. That’s lucky, since it’s been really tricky to debug this software. Since I’m changing the way the low-level input/output system works, it’s hard to generate any debug output without further messing up the code I’m trying to fix.
Eventually, I got the basic I/O routines built into the OS and running correctly. I now have a generic device interface that can be used to talk to four virtual devices:
0 Serial port / console 1 SD Card command channel (list files, make directories, etc.) 2 SD Card file #1 3 SD Card file #2
For example, when I try to write a character to a file, I call a generic putc() function. The generic putc() looks up the specific device driver putc() function for the current device and passes the character to be written to it. Devices 2 and 3 can be used to open files on the SD card by name and read or write data to them.
With the basic functions all working, it was time to write some “shell commands” that I could use interactively from the P:65’s command prompt. Running out of time, I just implemented the basics:
ls directory Get a list of files in a directory. mkdir name Create a new directory. rmdir name Delete a directory. rm name Delete a file. more name Print the contents of the file name to the console. load name Load and run the named file. save name Save the most recently downloaded file to the SD card.
Out of all of these, the more command probably took the longest to get right – that’s because it was the first to use the full range of file open and read commands, and it required a lot of time tracking down a handful of really trivial (but hard to spot) bugs, on both the 6502 and Arduino sides of the communications.
The load command also had me stymied for a while because of a bug in my pointer math when putting the new data into memory. Luckily, once I figured that out I was able to avoid a similar problem in the save command, which came together very quickly earlier this evening.
Up to now, I’ve had to download programs to the P:65 using XMODEM over its serial port. Finally being able to load programs into memory from the SD card is a big step up in convenience – big enough that I can say I’ve completed the first phase of this project.
There’s certainly more to do with this project. For example, I can load my BASIC interpreter from the SD card, but the interpreter doesn’t know how to load or save BASIC files. I’m also interested in adding support for this IO code to the CC65 standard library, so that I can write (very short) C programs for the Project:65 computer that use functions like fprintf and fscanf. I’d hoped to get into that this month, but it’s going to be a significant project all on its own.
Overall, I’m happy with where I ended up. Having an explicit goal and a deadline made things go faster than they would have otherwise, and I mostly avoided distractions. Plus, watching the progress on some of the other Retrochallenge projects kept me motivated – if you haven’t yet, you should definitely check them out.