Looking for Prompt-475

[dwight]

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.