I'd have thought they had it better under control by the 432 time
but you never know.
Most times on the UPP, you could hit the reset a number of
times if there was a problem. The changes in randomness would
usually let it reset and start code that would reset.
Intel had a number of poorly designed circuits that were on the edge
of working. One of the disk controllers with the 3000 series bit slice
had a problem if the ROMs used were too fast. I forget which one.
They were using the wrong edge of the clock to latch the data.
Dwight
________________________________
From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Eric Smith <spacewar
at gmail.com>
Sent: Thursday, November 3, 2016 5:15:56 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Looking for Prompt-475
On Thu, Nov 3, 2016 at 8:42 AM, dwight <dkelvey at hotmail.com> wrote:
The UPP had a bug that was never fixed. The level for
the
[...]
The problem was in an app note. Their solution was to put
a few NOPs at the start of the code. It worked most of the time.
Wow! I noticed the NOPs when I disassembled the code, but had no idea why
it was there.
The first >NINE< microinstructions in the iAPX 432 GDP Release 1.0
microcode ROM (in the 43201 chip) are all "reset processor", which doesn't
affect the micro program counter, but resets much of the other hardware in
both the 43201 and 43202 chips. I wonder whether there might have been
similar issues.