Retrochallenge 2024: Cat-644 Microcomputer
Cat-644 Hardware
- Started in 2013 - This is already on its way to be a vintage computer.
- Atmega 644, 20Mhz, 4k internal SRAM (possibly upgradable to Atmega 1284 with 16k SRAM)
- 128k bitbanged SRAM: used as VRAM and XRAM
- 16-bit Virtual Machine interpreter.
- VGA output, maximum of 64 colors at 512x240, software cycle-counted race-the-beam
- PS/2 keyboard
- RS-232 serial port
- SD Card
- expandable SPI bus: some experiments have been done with SPI-based ethernet shield originally intended for arduino
- It has been 'hardware complete' for a long time, and I have test programs for each piece of hardware, and combinations of hardware. (VGA + sound + keyboard all together was hard, as they all need exact timing and some of the same pins)
- In previous retrochallenges, I started writing an OS for this thing, in a mix C and Assembly.
Previous Work
I left off last time by implementing the beginnings of a tree and list-based data store on an SD card. It is sort of a filesystem, but more like a LISP tree. The root node of the filesystem has a block of data (about 240 bytes), a pointer to the next node, and a pointer to the first child node. You can think of each linked list of nodes as a file, and a list of lists to be a folder. It is all really just a giant binary tree, where each node contains some data and two branches. Applications are directly in control of how their data is stored on disk. Applications can sort and organize their data in binary trees, lists, etc.
In a previous retrochallenge, I also created a memory allocator that uses the AVR SRAM as temporary storage for a much larger handle-based heap stored in external RAM. Malloc and Free are similar to C, but the physical memory blocks are reference-counted. A program can also Release a pointer, which frees a physical reference to it. That memory is not deallocated, just a candidate for being moved around in memory or swapped out to external ram. (Maybe even potentially disk?) When a pointer is Released, a handle is returned. That handle can later be used to Grab the object, where Grab returns a real physical void*. This is similar to virtual memory, but there are no page faults, instead applications explicitly control their working set.
Plan
I am listing all the things I need to do to finish the OS for this computer.
- add VM syscalls for disk access and memory allocation (currently only available to native AVR C)
- boot VM from the SD card: The ROM test program baked in the AVR flash image should also load a special block from the filesystem and run it
- expose graphics routies to the VM: In earlier test programs, I played around with rendering sprites and such. I need to expose these C functions through VM syscalls.
- Write a little game that boots from the SD card. This can be as silly as just snake.
- Add sound. Sound was tested on this hardware, but isn't enabled in KittyOS. I am not sure yet how applications will be interacting with the sound buffer. In the interest of performance, I probably don't want to have a VM program generating PCM data, so it will probably just start with a simple beep api.
- Write an assembler that runs on the machine itself. (Instead of assembling on the PC)
- Add syscals to read/write the AVR flash
(view all as one document)