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.