[TUHS] Unix use of VAX protection modes

[Bakul Shah via TUHS]

Fortune, a 68K based system, had a custom external MMU with 4 segments, built using MSI TTL chips. Recall that the orig 68K supported up to 16MB of memory (24 bit ptrs):


purpose	base	 limit
text	0x000000 base+size
data	0x400000 base+size
extra	0xbfffff base-size (i.e. segment could grow downward)
stack	0xffffff base-size

IIRC the kernel was loaded a 0x0 physical address (or may be the ROM was there -- wherever the 68k started after being brought out from a reset state). Upto 4 256KB memory cards could be plugged in. To context switch you had to reload the segment registers with the physical addr and limits of the new process. copyin/copyout of syscall args were asm functions to deal with these segments.

The compiler generated function entry prolog code to access end of the needed local frame. If this was past the stack limit, the stack would be grown in the trap handler. IIRC this was one instruction that could be restarted safely?

The swap was needed only when the sum total of process space exceeded physmem - kernel space (256K to 1MB max on the original system).

Another neat hack: IO driver for an IO device was stored on the relevant IO card itself. Each IO slot was at diff. address and the system queried for the presence of a card. If one was found it had to follow the IO API we had defined to provide device name, what kind of device etc.etc. 

> On Jan 20, 2026, at 6:08 PM, Erik E. Fair via TUHS <tuhs at tuhs.org> wrote:
> 
> With regard to systems which didn't have address 0 in their user process address space (and thus dereferencing address 0 resulted in SIGSEGV), the first Unix (7th Edition) on a mc68000 was that way: the Dual Systems 83/80 S-100 (IEEE-696) bus system in November 1981.
> 
> Jeff Schriebman did the port, and founded UniSoft Systems not very far away from Dual in West Berkeley. Dual was UniSoft's first customer. Others: Apple Computer (for the Lisa - the parallel port based "Profile" hard drive was a horror), and a host of (Intel) MultiBus-based systems: Fortune, Pixel, Plexus, WiCat, CoData ...
> 
> Plop a 5 MHz mc68000 alas without an mc68451 (or other) MMU on an S-100 card, and how to protect the kernel? Split the 24-bit address space in half: bottom (from 0) for the kernel, top half (0x800000 and above) for user processes, and simple logic to test processor mode vs high (most significant) bit in any memory reference: any access of kernel address space (address msb  0) while the processor is in user mode generates a trap or interrupt, such that the kernel can deliver SIGSEGV to the offending process. Base system configuration: 128KB RAM, 64KB for kernel, 64KB for user, literally in two S-100 DRAM cards with appropriate base addresses set in their DIP switches.
> 
> Naturally, all user software that dereferenced address 0 failed, and there was a lot of that to be cleaned up. Also, some customers told us that our hardware was wrong (nope - logic error on the part of the programmers who assumed address 0 was accessible, i.e., (*NULL); we didn't sell you a DEC PDP-11 which started this whole mess).
> 
> Also, yeah, Bourne shell's ... interesting ... notions of memory management: SEG fault? Catch it, and sbrk(2)! Doesn't work on the mc68000 because it didn't keep enough state for restarting faulted instructions unlike the DEC PDP-11 (Clem, do you want to chime in here to describe MassComp's extravagant solution to that?). Asa Romberger recounted the tale of refactoring Bourne shell for mc68000 to me while I was working for Dual and visiting UniSoft relatively frequently. The mc68010 fixed that incomplete fault state bug, and made demand-paged virtual memory possible for mc68k-family-based systems.
> 
> Virtually addressed memory came with the mc68451 MMU (but that had other awful problems which is probably so many mc68k box system manufacturers rolled their own MMUs). Before that, IIRC, Dual's Unix was swap-based: had to run each user process loaded from 0x800000 ... so put the ones you're not running in the swap partition of the system disk. Slow. It was even possible to run Unix from 8-inch floppies, which was even slower, but I knew a guy who did for a while.
> 
> I still have a lot of hate for USL because I spent a year cleaning up their bugs in System III, plus it was missing basically all BSD enhancements for better usability (the worst was not having the BSD tty line discipline, and job control). Dual never fully released it - by the time we were ready, System V was out, and we had to do it all over again.
> 
> 	Erik