DUAL Systems documentation

[Erik Fair <fair%netbsd.org@localhost>]

For those of you of a historical or digital archeological bent: while googling 
for something else, I came across this URL:

http://www.hartetechnologies.com/manuals/DUAL/

which contains PDFs of a few manuals & a price list from DUAL Systems of 
Berkeley, CA. DUAL produced the very first mc68000-based UNIX system (V7 UNIX 
on the S-100 (IEEE-696) bus), starting in November of 1981. I worked there as a 
UNIX systems programmer (kernel hacker) as my first job out of U.C. Berkeley 
from March 1983 to May 1985.

Of particular interest to this group: the CPU/MMU board manual. Please note: 
the mc68000 could not demand-page (i.e. no virtual memory) because the CPU did 
not save enough state from a memory access fault to restart the faulted 
instruction, so UNIX was a swapping OS (whole process in RAM, whole process out 
to swap area on disk if not enough RAM is available for whatever else needed to 
run).

Motorola corrected the fault state save in the mc68010, which provided the 
ability to make a proper VM system ... except for the mc68451 MMU (yes, a 
discrete MMU chip, in a package every bit as big as the CPU) which had only 32 
descriptor registers (translation table entries). Motorola's theory was that if 
you wanted more (as one might for a lots of smaller-sized pages), add more MMU 
chips to your CPU board. Unfortunately, that doesn't fly on a board size as 
small as allowed by the S-100 standard. They were working on a proper paged MMU 
(PMMU) chip to go along with the mc68020 (the first fully 32-bit (address & 
data) 68k family CPU), but it was very, very late (DUAL was moving onto VMEbus 
from S-100 for the mc68020).

An aside, before Motorola shipped the mc68010, I saw another solution to the 
faulted-instruction state save problem from MassComp: their CPU board had two 
mc68k CPUs on it, one running a cycle behind the other, so a page fault would 
stop them both, the missing page could be paged in (I think they designed their 
own MMU; long since forgotten), and then execution resumed on the second, 
following CPU which hadn't taken the memory-access fault. Throw hardware at the 
problem ...

        faulting my way down memory lane,

        Erik <fair%netbsd.org@localhost>
        formerly 
{ihnp4,ucbvax,hplabs,decwrl,cbosgd,sun,nsc,apple,pyramid}!dual!fair