A look at how the original Mac OS was structured is a solid foundation for an '816 based OS.

It suffers from similar issues. Notably, no MMU so no virtual memory or memory protection.

The mac limited code segments to 32K. The code segments had to be coded in a PIC fashion (which can be done on the '816, but it doesn't have first class support). Code could be loaded anywhere in the Mac memory space.

On the '816, code segments would be limited to at most 64K, as the PC can't organically cross a bank boundary anyway. The code loader would have to be conscious of the code segment size and ensure that the segment itself does not cross a bank boundary. Other than that, the code can be loaded anywhere.

The code segments on the Mac start with a jump table of entry points to internal routines. When compiled, this jump table is loaded with offsets that are translated in to actual jump instructions. During compilation, when the compiler makes call to external routines, it JSRs though the jump table entries.

At this point, you have code segments that can be place (within reason) anywhere in memory. Also, they can be moved if necessary by the OS.

However, in order to do that, the code needs to follow some limitations on how it accesses memory. Specifically, it can't hold on to any absolute pointers.

The Mac memory manager works with relocatable memory blocks represented by Handles. A Handle is stored in a static location, and is simply a list of pointers to pointers. You pointer to the handle is dereferenced to point to the object in question. In theory, you should be locking handles to prevent the memory from being relocated, then any pointers are fair game for the duration of the lock.

Ostensibly, the Mac had a documented list of routines that might move memory, and as long as you didn't call any of those routines, any pointers you were holding on to remained valid. So, you didn't have to be as judicious about locking your handles and releasing them. Or you could simply always lock them and never release them. But, that kind of a bad citizen.

With a pre-emptive system, you have to be much more careful, as you no longer have control when your memory might move. Again, you could just lock it all, but that's considered bad form.

In the end, though, you have dynamically loadable code modules.

The IIGS followed much of this, but it was early Macintosh, it wasn't clear to me that it relied on the segment model of the Mac, and the GS never graduated to a full multitasking environment like the Mac did. (In the end, the Mac wasn't a pre-emptive system, it would context switch in the core of the main event loop that was central to all of the applications.)

Obviously, you will still suffer from memory protection issues, but you can't stop that.

The stack would be portioned out of bank 0 in chunks to the individual processes. As long as the code didn't hang on to direct stack pointers, the stack chunks can be moved by the OS during context switches and program loads as well.

Minix 1 ran on an 8088, which would be close cousin to the '816, but I haven't been able to find how it managed its processes and code segments.

An MMU sure can make things easy.

I have to disagree.

My position is using 1980s-era machines such as the ][gs and Mac as examples is not the best approach to designing a modern 65C816 machine and operation system. Those systems reflected the hardware capabilities of those times, and things have certainly advanced since then. The MC68000 running the first generation Mac, Atari ST and Amiga machines had no memory management whatsoever, and only careful and disciplined software design kept things running smoothly. That would have been true with any '816 system, including current designs. However, we now have the ability to conjure an MMU (more correctly, a hardware management unit or HMU) in programmable logic and give the '816 the help it would need in running a true, preemptive multitasking operating environment.

Also, I'm not sure that dividing RAM into 4KB pages as you describe in an '816 system is the most efficient approach. Memory is not nearly as costly per megabyte right now as it was 30 years ago, so allocating RAM in 64KB pieces, while wasteful in comparison to a 4KB paging system, is reasonable and does give a system enough head room for numerous processes. If one were to build a machine with 4MB of RAM, perhaps by using one of Garth's SIMMs, support for 63 simultaneously loaded processes would exist, assuming memory is allocated in 64KB "pages."

As some sort of data structure is necessary to keep track of memory allocation, the amount of allocation data that must be maintained will be inversely proportional to the size of the individual pages being allocated and freed. Succinctly, as page size decreases the page table size increases, as does the workload imposed on the kernel in managing memory. A question for the designer would be just how much performance is he or she willing to sacrifice in order to minimize inefficient memory utilization. Also, there are those two gorillas in the room that a 65C816 designer must consider as he designs his HMU: direct page, which is hard-wired to bank $00, and the stack, which is likewise hard-wired to bank $00. Unless steps are taken to somehow isolate one process' DP and stack from another, true memory protection will not be possible.

That said, there is no point in reiterating what has already been discussed on this topic. Also, some discussion here.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!