GTOS
Posted: 23 Dec 2019, 12:04
[This is a good moment to split the expander board software development from the hardware thread.]
To make the SD card reading somewhat meaningful, we must evolve CardTest into a tiny "card operating system". It can be loosely modelled after CP/M and MS-DOS. But an OS is a big thing. The challenge is to keep this minimalistic, but extendible. While at first there's no need for FAT32 writing it's good to think a bit about the organisation and the API. But let's not go overboard with features. Otherwise it will be much better to implement v8080, ADM3A emulation and simply run CP/M itself on the Gigatron and be done. But that's a too big project for me now (2-3 months).
I figure the following programs can be forked from CardTest and make up a tiny system. Let's call the ensemble GTOS (GigaTron OS...):
CardBoot
The ROM-embedded boot loader called from Reset. It will try to load System.gt1. CardBoot isn't a full blown FAT32 implementation, nor an efficient GT1 loader. Just the bare minimum. If System.gt1 can stay under 4K, CardBoot can even ignore the allocation tables.
System.gt1
The GTOS' core. A kind of resident RAM library for Basic Operating System Services ("BOSS" is a cooler name than "BIOS" ). Initially just some video terminal I/O based on the ubiquitous PrintChar and Newline functions, plus FAT32 directory and file reading. No card writing at first. Additionally it can load a second program called Command.gt1. It automatically does this after startup.
GTOS defines an API that should be stable over time. It must also have a minimal footprint to leave most memory available for user programs. If the system grows, GTOS could take ownership of the banked memory above 64K. It can then maintain a file system cache there. It can also hide parts of itself in there so that most of the "live" 64K address space remains available for user programs.
I suggest to allocate $200..$4f9 to the visible part of GTOS, and $500..$6ff for a sector buffer and other single-use purposes. Zero-page use must be minimised.
Command.gt1
A tiny command line shell that builds on top of the services provided by GTOS. It can search for a file whose name is typed by the user. When it detects the file is a GTOS-compatible command it will load and run it directly. GTOS commands can be recognised by the load address of their first segment (in my draft notes that would be $503). GTOS commands use GTOS services to do something interesting. Then they return to Command.gt1 with the vCPU RET instruction, or through the GTOS entry point that reloads Command.gt1. This makes it possible to extend GTOS with new commands in the same way as CP/M and MS-DOS.
If the file isn't a GTOS command, Command.gt1 should reset the video terminal, load the GT1 in a similar way as Loader and launch it. That effectively ends the GTOS session. This launch functionality can also be delegated to a separate Launch.gt1 application: its overall function is really different from loading commands, because general GT1 files will load almost anywhere. And they typically expect an unmangled video table. Commands behave the opposite: there you want to preserve the updated video display between typed commands. (Remember that text scrolling is done my changing the video display list instead of moving text data.)
The Dir command can be a built-in. That's not much extra with respect to what Command.gt1 must already be capable of. At least, for as long as Dir only displays names, not attributes.
List.gt1
This would be a GTOS command that lists the directory, showing its date attribute and file size. All the functions are already in CardTest.gcl, so we can evolve it from there.
This may sounds like a big project, but all building blocks for the above are already present in CardTest and other programs. We just have to reorganise them.
To make the SD card reading somewhat meaningful, we must evolve CardTest into a tiny "card operating system". It can be loosely modelled after CP/M and MS-DOS. But an OS is a big thing. The challenge is to keep this minimalistic, but extendible. While at first there's no need for FAT32 writing it's good to think a bit about the organisation and the API. But let's not go overboard with features. Otherwise it will be much better to implement v8080, ADM3A emulation and simply run CP/M itself on the Gigatron and be done. But that's a too big project for me now (2-3 months).
I figure the following programs can be forked from CardTest and make up a tiny system. Let's call the ensemble GTOS (GigaTron OS...):
CardBoot
The ROM-embedded boot loader called from Reset. It will try to load System.gt1. CardBoot isn't a full blown FAT32 implementation, nor an efficient GT1 loader. Just the bare minimum. If System.gt1 can stay under 4K, CardBoot can even ignore the allocation tables.
System.gt1
The GTOS' core. A kind of resident RAM library for Basic Operating System Services ("BOSS" is a cooler name than "BIOS" ). Initially just some video terminal I/O based on the ubiquitous PrintChar and Newline functions, plus FAT32 directory and file reading. No card writing at first. Additionally it can load a second program called Command.gt1. It automatically does this after startup.
GTOS defines an API that should be stable over time. It must also have a minimal footprint to leave most memory available for user programs. If the system grows, GTOS could take ownership of the banked memory above 64K. It can then maintain a file system cache there. It can also hide parts of itself in there so that most of the "live" 64K address space remains available for user programs.
I suggest to allocate $200..$4f9 to the visible part of GTOS, and $500..$6ff for a sector buffer and other single-use purposes. Zero-page use must be minimised.
Command.gt1
A tiny command line shell that builds on top of the services provided by GTOS. It can search for a file whose name is typed by the user. When it detects the file is a GTOS-compatible command it will load and run it directly. GTOS commands can be recognised by the load address of their first segment (in my draft notes that would be $503). GTOS commands use GTOS services to do something interesting. Then they return to Command.gt1 with the vCPU RET instruction, or through the GTOS entry point that reloads Command.gt1. This makes it possible to extend GTOS with new commands in the same way as CP/M and MS-DOS.
If the file isn't a GTOS command, Command.gt1 should reset the video terminal, load the GT1 in a similar way as Loader and launch it. That effectively ends the GTOS session. This launch functionality can also be delegated to a separate Launch.gt1 application: its overall function is really different from loading commands, because general GT1 files will load almost anywhere. And they typically expect an unmangled video table. Commands behave the opposite: there you want to preserve the updated video display between typed commands. (Remember that text scrolling is done my changing the video display list instead of moving text data.)
The Dir command can be a built-in. That's not much extra with respect to what Command.gt1 must already be capable of. At least, for as long as Dir only displays names, not attributes.
List.gt1
This would be a GTOS command that lists the directory, showing its date attribute and file size. All the functions are already in CardTest.gcl, so we can evolve it from there.
This may sounds like a big project, but all building blocks for the above are already present in CardTest and other programs. We just have to reorganise them.