cctech Digest, Vol 13, Issue 5

[Clem Cole]

On Sun, Jul 5, 2015 at 1:00 PM, <cctech-request at classiccmp.org> wrote:

> Having the primary CPU just stall, and have the second CPU normally just
> be idle until a page fault happens on the other hand is something I can see
> how it could be done.


​Indeed that is exactly how it was done on the Masscomp MC-500 and I
believe the original Apollo - this was know as "Forest Baskett Mode" - who
wrote up the idea in a letter/comment to one of the architecture groups in
the late 1970s when the chip was first released.

The primary processor is called the "executor" and the second ​is called
the "fixer."   The fixer is either halted or runs a small loop keeping the
translation buffer (TB) full.   When the TB logic detects a fault for the
executor, it is put in wait state and the fixer is restarted (if ned be)
and refills the TB.   When it's valid the executor is allowed to come out
of wait state (a very slow memory fill).

When the 68010 was released we make a small change the CPU board (a couple
of PALs) and allowed the executor to actually fault.  But the fixer still
did the TB fill.   But the executor could do a task switch and run some
other code, while the fill was taking place.

I'm not sure if Apollo updated their original CPU board or just designed a
new one with the 68010, I would have to ask some one like Les Crudele to
find out for sure.   And Sun never did the Forest Baskett dual 68K trick.
Sun-1's with 68000 ran a V7 version of swapping Unix (originally from
Unisoft) until the 68010 came out when they could support VM on the "SUN-2"
and Joy et all moved BSD 4.1 to it.

One other note about the MC-500.   If was the first commercial
Multiprocessor UNIX (predating the 386 bases symmetric boxes but a few
years) as well as being the first real time UNIX box.  I still have working
one in my basement.   It has 4 CPU boards in it with a 68010 and 68000 on
each, plus a 68000 in the display processor, a number of 29000's in the FP
and APP's units, more 29000 logic in the Data Acq Unit, as well as 80186 in
the network processor.  All in all, a pretty neat federation of processors
each doing their thing.

Pretty cool for early 1980s'

Clem