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-boun...@classiccmp.org> on behalf of Eric Smith <space...@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 <dkel...@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.
