[TUHS] Unix use of VAX protection modes

[Tom Lyon via TUHS]

The 68000 didn't have any special logic for inserting wait states; one
merely asserted DTACK when the data was actually ready.
Thus the cult-status newsletter "DTACK Grounded" -
https://en.wikipedia.org/wiki/DTACK_Grounded

On Wed, Jan 21, 2026 at 2:51 PM Clem Cole via TUHS <tuhs at tuhs.org> wrote:

> Thanks, Jonathan - yes, it was COMPCON to Asilimar.
>
> On Wed, Jan 21, 2026 at 5:32 PM Clem Cole <clemc at ccc.com> wrote:
>
> > below
> >
> > On Tue, Jan 20, 2026 at 9:08 PM Erik E. Fair via TUHS <tuhs at tuhs.org>
> > wrote:
> >
> >>
> >> 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.
> >>
> > To be fair, the idea originated with Forest Baskett's Asilmar paper in
> > 1980, if I remember the date correctly.  Sadly, the paper appears to have
> > been lost to time, as far as I can tell.  As Erik mentioned, the problem
> is
> > that the instruction needs to be restarted and allowed to complete —
> after
> > the VM code makes the page available, it restarts the processor with the
> > original instruction that previously failed.
> >
> > Without getting into too many HW details, there were several types of
> > memory available, each with different characteristics for accessing them.
> > Also, the processors of that day used a synchronous bus -* i.e.*, the
> > processor put an address onto the memory bus and waited for the resulting
> > read or write before the instruction that created the address "complete."
> > [1]  Since different memories have different timing characteristics, the
> > 68000 has a "wait state" pin. Depending on how long it has been asserted,
> > it allows N clock cycles to go by while the processor waits for the
> memory
> > transaction to complete.
> >
> > So the Masscomp MC500 CPU board had 2 68000s on it, called the "executor"
> > and the "fixer."  The fixer did just that.  It ran the code to fetch a
> new
> > page for a read or to create a copy of the page on a write, which was in
> > the address space assigned to the process executing on the processor.
> When
> > an executor "faulted" instead of returning an error, the hardware just
> sent
> > wait states to it.  The fixer set the memory and released the wait pin on
> > the executor, which will complete the requested operation without
> faulting,
> > but at the expense of a very long time for that instruction to complete
> on
> > the executor.
> >
> > When Motorola came out with the 68010, which did save enough "microcode"
> > state so the executor could fault and was free to do something else while
> > the fixer redid everything.  We swapped out the executor and changed a
> > small amount of logic on the CPU board.  The executor was free to do
> > something else while the fixed cared for the memory.  When the fixer gave
> > the ok, the executor would pick up where it left off in the process that
> > originally hit the fault.
> >
> > A "fun" (undocumented) feature was discovered by us soon after the 68010
> > showed up.   Masscomp was the first UNIX vendor to build and sell an MP
> > machine (MC500/DP).  But we ran into a field issue with the 68010's.
> >
> >  It turns out that different microcode was implemented in different
> > "steps" of the chip.   And what was saved on the stack was different
> > between them.   So the problem was, if a CPU board was made with a 68010
> > from batch A, and its MP twin CPU board had a 68010 from batch B — thus
> > having slightly different microcode.   The issue we discovered was that
> > when the 68010-based executor on CPU card A faulted, the microcode state
> > was stored on the stack per Motorola's specs, but when we tried to
> restart
> > the process by allowing the previous faulting instruction to be retried,
> > batch B's 68010 executor could not grok the microcode state that had been
> > stored from executor A  (and vice versa).
> >
> > After many complaints to our Motorola rep, to get them to make the
> > microstate saved identical even when they "stepped" the processor.  In
> the
> > meantime, manufacturing and field service made the "field replaceable
> unit"
> > (FRU) a matched set of processor cards.
> >
> > Clem
> >
> >
> >
> >
> >
> >
> >
> > 1] The PDP-11 worked this way, but starting with the Vax and copied by
> > more modern processors is the idea of a "split transaction" bus. where
> the
> > processor makes a request of the memory system, and is free to do
> something
> > else.  The memory returns a bus transaction indicating whether data was
> > written or read, and the processor can retire the instructions.  This is
> > really useful when you start to break up instructions in a pipeline.
> >
>