sorry...    all *MPU* boards had to be the revision but we may have done
the same with the CPU boards.

On Tue, Jan 21, 2020 at 1:43 PM Clem Cole <clemc@ccc.com> wrote:

>
>
> On Tue, Jan 21, 2020 at 12:18 PM Jon Steinhart <jon@fourwinds.com> wrote:
>
>> My memory is very very very fuzzy on this.  I seem to recall that
>> microcode
>> state was pushed onto a stack in certain cases,
>
> State, not the code.
>
> In fact, Masscomp having built the first MP UNIX box, ran into this
> problem early on.  Different processor stepping had different internal
> microcode state on the stack after an IRQ.  If you resumed with a processor
> that was a different processor revision, the wrong state was returned.
>
> Will may remember this, but Masscomp issues strick orders to the FE that
> all CPU boards had to be the revision.  You could not just swap a CPU
> board, they had to go as sets. It was a real bummer.
>
> Moto fixed that with the 020 and later devices as more people made MP
> systems.
>
>
>
>
>
>> ...  just heard grumbles from other folks about it.
>>
> Probably me ...  it took me, tjt and Terry Hayes about 3-4 weeks to figure
> out that problem.   It was not originally documented, other than to state
> on certain faults X bytes of reserved information was pushed on the stack.
>
>
> BTS: I don't remember, but it may have started with the 68010.
>  Becuase before that, the 'executor' was wait stated and the fixor handled
> and fixed the fault so the 68000 never actually saw  fault in the original
> Masscomp CPU board.   The "MPU" board was the same board with a couple of
> PAL's changed and an 68010 as the executor.   It was allowed to actually
> fault and do something else while the fixor corrected the fault.  But the
> key is that when the fault was repaired, another executor on a different
> MPU board could be the processor that 'returned' from the fault.   That
> ended up being a no-no.
>