8088 vs. 80c88

Allison ajp166 at bellatlantic.net
Mon Feb 23 17:36:18 CST 2009

>Subject: Re: 8088 vs. 80c88
>   From: "Chuck Guzis" <cclist at sydex.com>
>   Date: Sun, 22 Feb 2009 23:58:23 -0800
>     To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>On 22 Feb 2009 at 22:17, Allison wrote:
>> Your kidding tight?  ;)  
>> JRT pascal was fairly buggy itself and it was till arond V3 that it stopped being
>> noticalbly so.
>Buggy or not, the V20 wouldn't run it.  Rich Naro verified the bug 
>and published a MicroNote on it.  And JRT was comparatively popular 
>for the time.  It boils down to the V20 not being able to run a 
>commercially available 8080 product because of a fault in the CPU.

That may be true, bought it too but found it buggy on both 8085 and Z80 too.
Why did I buy it, $29.95 and I even got a copy, some didn't!

However using a buggy suite to prove a bug is weak even if it got lucky.

That it had bugs, can't argue that.  They could have just as easily given 
it the base uCOM78 instruction set instead.  But how many V20s were bought
to run 8080 rather than as a faster varient of the 8088?

>Suppose a customer used an application written and deployed with JRT 
>Pascal.  What do we tell him?  "JRT Pascal--ho, ho, ha, you must be 
>Nope, serious business.  Who knows what other product could have used 
>the same coding technique?

That's a regression testing issue.  Generally getting functional code out 
of it was at best luck till later versions.

>In a way, this was deja vu of a much earlier problem with the NEC 
>version of the 8080, where NEC left the carry bit unaffected after a 
>boolean operation, where Intel reset it.  Considering that many 8080 
>programs cleared the carry bit with something like "ORA A", do you 
>think that CP/M would have run with the old NEC chip?

Yep, I as working for NEC then. What's also forgotton is Intel changed 
the spec to match there part as it was deemed fine that way.  Since NEC
was ground up from spec, oops.  They also fixed it and copied many other 
subtle timing bugs as well.  Sometimes you get it wrong and other times 
you don't.

In the industry the number of second source flubs are legion.. remember the 
8251,2651, and friends.  

FYI at the time CP/M did run with the old chip.



More information about the cctalk mailing list