So, since the computer ended up not needing any adjustments to the VGA code at all, the next step was getting my development environment running again.
Serial Communication: Logging and Bootloader I tried connecting the CAT644 up to my Windows computer (which runs Atmel Studio), but I couldn't the serial connection to work... turns out a wire broke in the connector... soldering iron time. Fixed it all up. I use Hyperterminal in Windows... and I was back to being able to see the debugging log come through on the serial port. I also tried out the bootloader, and it said it was connecting OK. I use Chip45 for my bootloader, and I highly recommend it if you are developing for AVR in a Windows environment. This allows me to reflash the AVR through the actual DB9 serial port, instead of using the ISP pins, or an Arduino bootloader through USB.
Rebuilding Code:I have to make sure the OS still compiles from where I left off a few years ago... and it does! The new build does everything the old build did, but has today's date in the startup screen.
Rebuilding Assembler: The CAT-644 is meant to ultimately run user-written programs... In a previous retrochallenge, I wrote a high performance 16-bit interpreter in AVR assembly langauge. This bytecode interpreter needed an assembler, so I needed to make sure it still worked. I had lost whatever script or bat file actually runs the assembler, so it took a little time looking at the assembler's source code trying to remember how to run it, what command line parameters it took, etc. I got it to asseemble a slightly different program and include it in a new build of the OS. (The OS at boot loads a bytecode program from ROM... currenlty it's a simple Hello World program that also takes some keyboard input.)
Now that the hardware and development environment are back to working, it's time to code up some new features for this OS:
Block device support: Previous work on the SDCard was pretty simple: Write a driver that can initialize the card, and then read or write a given block. That's it. There is no filesystem. I don't think I want a completely traditional filesystem either. I'm currently thinking of starting with a simple block allocator which can allocate or free individual blocks. Then on top of that, an API that lets applications create LISP-like data structures... trees and lists... out of those blocks. A 'file' wouldn't be a linear stream of bytes, but instead a completly custom data structure that is defined by the application. The filesystem is more like a RAM heap with the granularity of a block size.
Executable handles: Previous work also created a handle-based memory allocator for the bitbang'ed external RAM. Data can be swapped in and out of the AVR's internal SRAM and the external SRAM using a grab/release API on handles, which swaps in and out data, giving the user a potentially new pointed each time. This allows much larger data structures (64K external RAM heap) than the internal (4K) RAM that AVR contains. The bytecode program is interpreted out of SRAM... and I want the code structure to also be able to be bigger than the interal SRAM. This will require adding in either an extra instruction or a syscall, to 'call' code, not with a real SRAM address, but instead call a function by handle. This would trigger swapping of code in and out of external memory, if it isn't already internal.
Graphics Support: The VGA scanline driver took a lot of work previously, and I probably won't be touching it for a while. But, apart from drawing characters to the screen using the VGA driver's chardevice interface, there is no real graphics support. I did write a draw_sprite function a few years ago when I was testing out graphics... I am going to expose some basic graphics functionality through syscalls. I want to pass the OS an array of sprite parameters. The bytecode application will fill out an array with parameters for sprites to draw, and then a syscall will draw several sprites at once. An actual game might be a little challenging because there currently isn't any double-buffering support, so screen updates have to either happen during vertical blanking, or drawing of sprites race-the-beam. I think I do want a double-buffered display at some point, but that will require using more memory or lowering the resolution... for many games half resolution would be fine... the old Game Boy is only 160x144, and 256x120 or 128x240 is more pixels than that, and I have more colors. Modifying the graphics driver to do 1/2 resolution in either vertical or horizontal direction without changing any of the instruction timings would be very easy, and is one of the few changes to the VGA driver I wouldn't mind doing.