The origins of JR/OS date back to my ill-fated COLE-2 project. I had originally envisioned it as being a simple single-tasking OS that could run on a variety of hardware. There would be a BIOS layer that interfaced to the hardware, with the actual operating system interfacing to the BIOS. JR/OS would not provide much functionality other than device and file system management.
Over the last year it has become apparent that there will probably never will be a plethora of 65816-based systems. It’s just not as popular a target for hobbyists compared to the 6502. I decided that the only systems I should worry about supporting are my own. Thus the BIOS/OS separation fell away to become just JR/OS.
Freed from the constraints of having to run on a variety of differing hardware, a more ambitious goal for JR/OS began to crystallize. JR/OS will be a full multitasking OS with memory protection, virtual memory, and a POSIX user space environment. It goes without saying that this is a much bigger project than my original plans. However, I think the journey will be fun and educational even if it doesn’t get to its destination.
To maximize my chance of success I am going to do this in phases. The idea is to make JR/OS usable for user space programs as quickly as possible. I will then add functionality in manageable chunks. Each phase will add tangible functionality, which should hopefully keep me motivated to keep moving to the next phase.
Required Features
Before I delve into the phases of this road map i want to go over some requirements I have. These are in addition to the core OS features such as multitasking and memory protection:
- The system must be usable at power-on even without booting from storage. This means booting into a ROM-based BASIC interpreter.
- The BASIC interpreter must support storage (LOAD, SAVE, OPEN, etc).
- If storage is detected at boot time the system must attempt to boot from it.
- The system monitor must always be available.
If it is not obvious I am basing my design on the Apple II (or more accurately the IIGS). This should not be surprising, given my stated desire to create a modern evolution of the IIGS.
With these requirements out of the way let’s take a look at how I’m planning to build all this.
Phase 1: User space environment
The first phase is the easiest, and the one on which I will be starting work this week. In this phase I will get the user space environment fleshed out enough that it’s possible to write functional applications.
For me to consider this phase “done” the user space must provide the following minimum features:
- Full console I/O
- Memory management (allocate and deallocate memory)
- Device access (serial ports, SPI devices, SD cards)
Much, if not most, of this is already implemented in some form, but there are some gaps to plug. The largest of these is that memory allocation needs to be wrapped in some sort of standard library. This is because memory management will eventually move to user space, and I want the change to be transparent.
Phase 2: File system support
The next step will be to implement a file system. The ability to load and save files is critical for writing any truly usable software. Since the hardware only supports SD cards it makes sense to use FAT32 as my file system. The current JR/OS code already has some support for this: FAT32 partitions are detected and enumerated at boot time.
It is in this phase that I’ll also be adding the ability to automatically boot from storage. If no boot media is found then the built-in BASIC will be launched.
Phase 3: Preemptive multitasking
This is where things will start getting really interesting. In this phase JR/OS will gain support for multiple processes and preemptive multitasking, but without virtual memory or memory protection. In this sense it will resemble GNO/ME.
It is also in this phase that JR/OS will implement multiple user IDs and multiple privilege levels. Theoretically at this point JR/OS could support multiple simultaneous users by spawning a console on the second serial port. However, I am not actively planning on implementing this at this point.
One thing I will need to iron out in this phase is how to support the system monitor going forward. Currently the monitor is basically a user application running with root privileges. It uses the JR/OS direct page and stack, and directly accesses some JR/OS internals. The monitor will need converted to a regular application here and divorced as much as possible from JR/OS itself.
Phase 4: Virtual memory support
This phase will begin once JRC-2 hardware is available, as it will require a PMMU. In this phase I will move memory management into the user space runtime. JR/OS will continue to manage its own memory allocations, but only provide VM support for user space.
Phases 5+: ???
Beyond phase 4 my road map is currently undefined. A major part of these phases will likely be making fleshing out POSIX support in user space.
I may add networking support here, though it would probably be limited to a PPP link. I don’t even know where to begin building an Ethernet card.
Another very lofty goal that would fit in here somewhere is to implement a IIGS-compatibility mode in JR/OS. This is purely a pie-in-the-sky idea right now. I have barely scratched the surface of how this might be accomplished.
Final Thoughts
As I mentioned at the start, this is a very ambitious road map. I can’t even begin to estimate how long it will take, especially considering my unpredictable periods of burnout. Only time will tell…