DUAL Systems documentation

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 <[email protected]>
	formerly {ihnp4,ucbvax,hplabs,decwrl,cbosgd,sun,nsc,apple,pyramid}!dual!fair