Today is the last day for the retrochallenge. I ended up having a lot of unexpected things going on this month, but still managed to get out a tangible increment of KittyOS for the Cat-644. This is what got implemented:
Previously only character devices, which read and write 1 byte at a time were supported. This included the serial port, SPI bus, VGA drawchar function, and reading the keyboard. Block devices allow reading and writing discrete blocks of data, such as a disk. The SDCard block device driver actually uses the SPI character device to tak to the SDCard. Writing to the disk involves locking the SPI bus for exclusive use for the duration of the write. Theoeretically multiple SPI devices or even multiple SD Cards could be supported, as long as each SPI device driver uses the SPI lock API:
dev_spi0.chardev.ioctl(&dev_spi0, IOCTL_LOCK, SPI_MASTER | SPI_CLK_8); // The SDCard Driver locks the SPI bus, also asking that the bus be put in a particular configuration
low(SDCARD_CS); //Activate SD Card
for (...){
//read/write whatever is needed
dev_spi0.chardev.write1(&dev_spi0, c); .
}
high(SDCARD_CS); //Deactivate SD Card
dev_spi0.chardev.ioctl(&dev_spi0, IOCTL_UNLOCK, 0); //unlock the SPI bus. This returns whatever shared pins are back to what state they were before the SPI session.
The SPI Bus and external memory address lines both use PORTB. The external memory access lines are used for both XRAM usage and drawing the screen. This means two things: 1) SDCard transactions must read/write only internal AVR SRAM, but XRAM. This isn't too bad, since if we are reading or writing something, it is something we need, so it'll probably need to be in internal memory anyway. And if it is for later, copy to XRAM is much faster than the SPI transaction was anyway. 2) If the VGA driver timer goes off during an SDCard transaction, the SDCard driver keeps those bits of PORTB overridden... making the display show some 'garbage' for a few scanlines at a time. This can be mitigated by reading and writing blocks during the vertical blanking interval. This seems limiting, however there is enough time to read or write a whole block or two. This means the maximum speed, without interrupting the display, assuming 1 block per interval, is 512 bytes per frame, or 30,720 KB/sec. This sounds slow, but Commodore 64's Epyx Fast Load only reads at 2500 bytes a second... the original protocol shipped by Commodore is only 300 bytes/second. I don't consider this a serious limitation to this platform.
The OS contains functions to read and write linked lists and trees of blocks. A traditional filesystem is not provided, but creation of linear lists of bytes that look like a flat file is a use-case easily supported by this scheme, as well as transformations on these files in ways not possible in standard filesystems: Removing bytes from the middle of a file, directly appending two files together, etc. This OS will be an interesting experiment as it develops further. I feel like it will go two directions; it will either 1) as features are added, eventually end up looking like a traditional filesystem or 2)it is something very different. One thing I want to add is the ability for the handle-based allocator introduced in a previous retrochallenge to have handles that represent blocks on disk. This would allow navigation of disk structures as if they are XRAM objects. This is starting to look like some kind of Virtual Memory scheme.
The LLFS tree functions are only implemented in C, and are not exposed to the VM interpreter. This would just involve adding calls to the syscall() C function's swich block; I just simply ran out of time. I also want to add block move and delete routines functions. Currently things written in C can create structures on disk, grow them, or edit their data, but not prune.
So, that's the end of my retrochallenge entry. I am still quite excited about this project, and I got to a late start this month, so I'm going to keep working on it and posting updates, but everything that happens after now isn't really meant for the competition; it's just me continuing to play around.