[TUHS] Unix use of VAX protection modes

[Clem Cole via TUHS]

Ah yes. Thank you. I had forgotten, unlike some the other contemporary
chips, the 68000 just waits for the memory system to tell it to continue.
The faster the access time on your memory, the faster it could complete the
instructions.

Sent from a handheld expect more typos than usual


On Wed, Jan 21, 2026 at 6:44 PM Tom Lyon <pugs78 at gmail.com> wrote:

> 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.
>> >
>>
>