Retrochallenge 2024: Cat-644 Microcomputer

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.

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

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.