I think we're going to have a design disagreement here since you've mentioned this approach at least twice now.

I think the OS should be loaded into code RAM when the system is booted and it should remain in memory thereafter. Some kind of shell must be resident to load and unload programs. Once a program is loaded the OS still must remain resident to, as you said, provide library routines that the program should call.

All access to the hardware should be through the OS and programs should not avoid the OS in an attempt to speed things up. Instead we should design the OS to be as efficient as possible for the vast majority of cases so there is no reason to circumvent the OS in the first place.



It was also the most common reason for programs to fail on new hardware that included new versions of the OS or had different hardware. I think we need to design the OS in such a way as to provide the raw functionality that programmers will need and remove any motivation for them to circumvent the OS.

Especially if we're going to design as much modularity and expandability into this as we've been discussing. The only way to achieve this reliably is if programs commit to using the OS. An expandable and flexible platform that can have any combination of devices attached to it that software programs try to access by circumventing the OS is a recipe for disaster.

One other point is the issue of relocatable code. If the OS is stored at the bottom of memory and programs are loaded immediately following the OS in code RAM then the programs could conceivably be loaded anywhere in memory. LJMPs to specific addresses in the program will fail since the program may not be loaded where the assembler thought it would.

This could be resolved by having all programs have the first two bytes indicate the length of the *CODE* in the program being loaded. Those two bytes would immediately be followed by the assembled code itself with no embedded data, with all non-instruction data contained at the end of the file. The OS program loader would then automatically adjust absolute addresses in the code area of the program. The non-instruction data would not be adjusted, of course. AJMPs and ACALLs could not be used in user programs since programs could be relocated to areas of memory that cross 2k boundaries.

The other solution is to have the OS occupy code RAM from 0000h-0050h (init/ISR vectors) and then high code RAM (48k+ or whatever). This is what the Ataris did. Then the OS loads into the top of memory while all user programs must always begin at 0050h. That way LJMPs and LCALLs in the user program will always work since the program ORG is always known to be 0050h. The downside to this is only one program can be running at a time. You couldn't very well have anything like TSRs.

Regards,
Craig Steiner