Retrochallenge 2024: Cat-644 Microcomputer

The Cat-644 is a computer I've been developing around an Atmega 644 microcontroller. It has been a long running side project that I get out every once in a while to work on. I've decided to work on it some more for this round of the retrochallenge.

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






---

October 14, 2024

We are about halfway through the retrochallenge. This is what I've managed to get done so far:

Boot Shell

When the computer starts up, a short C program runs after the hardware and drivers are initialized. This program displays a "@>" prompt, and accepts a few short commands. The motivation behind this was to be able to boot bytecode programs without having to reflash the AVR... previously the bytecode was copied from the ROM.

Working shell commands:
• e arg:Echos arg to user.
• s:Switches control to the serial port. User I/O for all future commands are done on the serial port.
• k:Switches control to the keyboard and screen. User I/O is now through the keyboard and screen.
• x:The prompt changes to "x:", and the OS expects a hex string up to 512 characters long. When the line is terminated, the hex is decoded, and an up-to 256 byte program is ran. This is how I've been testing the interpreter: Pasting a hex string into hyperterminal.
• r:Runs whatever bytecode program is stored in the AVR firmware image.

Syscalls

I added several syscalls reachable from the bytecode interpreter. The previous demo has only basic keyboard/screen terminal style syscalls: read1, write1, and ready, which are the equivalent of getc, putc and kbhit from C. These are the syscalls currently supported:

Character Device Syscalls: Operate on serial port, keyboard (readonly) and screen. The screen device, if asked to read, will read from the keyboard and forward them to the application. Programs that read/write from a character device work either the screen, or over the serial port.

• findDevice:Finds a device by name. For instance a the screen is called "scr", keyboard is "key", and the serial port is "ser0".
• read1:Reads a single byte from a device, blocking if necessary.
• write1:Writes a single byte to a device.
• ready:Returns true if there is a byte ready to read. (non-blocking)

Graphics Syscalls: These are implied direct to the video driver.

• clearScreen:Fills the screen with the specified color, and reset cursor and scroll settings.
• drawSprite:Draw specified sprite at x/y coordinates. Sprite can have transparent pixels.
• textColor:Specify text forground and background color. (Text background can be transparent)
• textPos:Set X and Y position of text cursor.
• scroll:Set horizonal and vertical framebuffer scrolling values. Video memory is 256x256 framebuffer, with a 248x240 visible window. X and Y coordinates wrap around. This is to enable smooth-scrolling w/ a small hidden portion.
Memory Syscalls

The OS has several memory syscalls. On the surface, alloc and free look like classic malloc. However, progams should take advance of the handle api. An object that is not immediately needed can be "released." The OS is free to move released objects around... when the working set of memory exceeds internal SRAM, objects will be moved to external memory. Data structures like trees and lists are preferable on this OS... the tree can be much larger than the internal 4k SRAM, if the application uses handles for its next/prev and parent/child pointers. Applications should pass handles around until it actually needs to access the data. At any time, the program can call "hgrab" on a handle to get a real pointer to it. This may trigger a copy from XRAM. The pointer is valid until the object is released again. If the system it out of internal memory, and too many objects are grabbed at once, grab can fail. Programs should grab only what is needed, when its needed. There are some more calls I want to implement, mostly as optimization opportunties. For instance, if an object was grabbed and released without writing to it, there is no reason to copy it back to XRAM; there needs to be a read-only version of hgrab.

• alloc:Allocates memory, returns a real pointer that can be written to.
• hrelease:Releases memory, does not free it. This accepts a void*, and returns a handle that can be used to later read the data. If needed, the OS will move this object to another location in the heap, or move it to external memory.
• hgrab:Accepts a handle, and returns a void*. This is the opposite of the release call. The object can be read/written. The application should call release when it no longer needs it in the working set.
• hfree:Accepts a handle deletes the object.
• free:Accepts a real pointer, and frees it. This also frees any copy of the object in xram.

Disk Syscalls

In the last retrochallenge, I got a simple linked list tree filesystem partly running. This is not yet available to the bytecode interpreter. I need to add a directory API on top the the tree API, so that the root can contain a list of named subtrees. These, I suppose, would roughly be directories. Each subtree can then either be a named list of subtrees (I suppose subdirectories), or a program-specific tree structure. (Files)

What next?

I have enough syscalls to interact with the screen and keyboard, including sprites. Instead of diving into disk syscalls, I want to write a simple game. The best way to keep me motivated on a project is to get it actually doing something.