Retrochallenge 2018/09, 2019/03

VM Interpreter and Syscalls

I took a VM interpreter I wrote a couple years ago as a proof of concept, and integrated it into the OS. I exposed a syscall interface that calls into C with 3 parameters: an 8-bit syscall number, and two 16-bit values. The syscall can also return a 16-bit value. I haven't implemented much in the way of syscalls, other than printing out that the VM requested a syscall.

I also created the first system 'mux' device, which allows the listing and finding of other devices. There is now a mux named mainmux that lists all the current devices. This is the current kittyOS boot process:

1. Chip45 boot loader runs and timeouts, jumps to the AVR application section (contains kittyOS)
2. main() of the application section is where kittyOS starts. The first thing it does it print 'kernel start' to the system dmesg_dev, which isn't pointing anywhere yet. This was a test to see the writing to an unitialized device doesn't do anything bad.
3. The serial port (ser0) is initialized, and the dmesg device now points to it. All debugging messages after this are sent to the serial port
4. External RAM and VGA interrupt is initialized. This brings the screen and keyboard to live
5. dmesg is changed to point to the 'scr' device, which is a virtual console that draws characters on the VGA screen. The scr device is found using findDevice, which uses the mainmux device.
6. As a test, all the devices in mainmux are enumerated, and their type is displayed on the screen.
7. The system now transfers control over to the virtual machine interpreter. There is a short test program stored in a char array 'introm.c' This program just adds a couple numbers to test the VM is alive, then does a couple syscalls. It then ends in a halt loop.

This is what I want to do to finish off the retrochallenge:

• FIND_DEV: return device handle by name, such as 'scr' or 'ser0'
• WRITE_CHAR
• READ_CHAR
• HEAP_INFO: return address and bytecount of unused memory

How am I doing on memory? Just a little over 8k of flash is used, and I can use up to 60k without having to find a smaller bootloader. There is plenty of program space free. On RAM? So far, I get to give the VM over 2k, and there's still unused space. One thing I can do in the future is reposition the stack. Once I enter the VM interpreter, there is no reason to ever come back, except for an interrupt or a syscall. These go 'deeper' in the stack, and don't backtrack. The interpreter should be able to carefully move the stack back to the end of RAM, overwriting the stack frame for main(), which will never be needed again.