DUAL Systems documentation
Erik Fair <fair <at> netbsd.org>
2014-02-22 10:12:17 GMT
For those of you of a historical or digital archeological bent: while googling for something else, I came
across this URL:
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,