Software Getting Firmer
We're getting close to having the system software take center stage as the hardware nears completion.
The test software already has a lot of useful routines in it. The final software will allow the system to be programmed directly, from the keypad, without the use of an external device programmer.
A System MonitorThe system software will initially be a simple monitor that will allow the user to view and edit memory and CPU register values, run programs, and break back out to the monitor using the non-maskable interrupt (TRAP.) There will be a hardware interrupt available for user programs (RST5.5) and probably some software interrupts for user routine vectors. I'll be reserving 4K of the memory for the monitor and future expansions, leaving 4K of memory for user programs (or more if you want to cheat and use my reserved space until I fill it with software.) This is far more than the original SDK-85 had, and comparable to a "larger" small system, like a VIC-20.
System routines will be accessed using a jump table, so the address you use to get to any system routine won't change no matter how I--or you--rewrite it. That way you won't have to change all the system routine addresses in your programs if the system routines move in memory.
Aside from the obvious I/O routines, I expect to have at least data type conversion and integer math routines for 8 and 16 bit operands. I'll probably put in some data structure management code as well, and maybe even floating point.
There are a few possibilities for expansion I'm looking at. My favorite is an assembler/disassembler. This would allow programming using assembly code mnemonics instead of machine language. I'd expect it to be pretty basic--no relocation or macro capability. Though it'd probably convert data types and know names for system routines to translate into addresses. You could just type LDI A,"X", JMP CHAROUT to send an "X" to the LCD.
Another possibility would be a simple BASIC implementation. I'm less enamoured of this idea for this particular system, though I may choose to write a Tiny BASIC as an alternative to the assembler after the assembler is complete.
A Small C interpreter is another possibility. If I go crazy writing data structure support system routines, this might just sort of happen on its own. Don't expect any ANSI standards here, though!
Yet another approach would be a FORTH-like language. A true FORTH would sort of take over and change the whole of the system software. I might consider it. I'd more likely build a stack-based in interpreter more along the lines of the HP-41's programming language.
We'll see. I think once the monitor is done an assembler/disassembler/editor is very likely. I may put in a simple assembly-based interpreter for interactive code testing or calculation.