hes@ecsvax.UUCP (Henry Schaffer) (09/10/85)
<>When I bought an 8087 to put in my IBM PC, it came with a new 8088. I was told to replace the 8088 when I put in the 8087 because the old 8088 might not work properly with the 8087. I didn't feel like experimenting, so I did the replacement. <>Question: Is this kind of matching really necessary, and, if so, does one have to worry about replacing an 8088 with a V20 in a system with an 8087? (Also same question for 80286, V30, 80287.) --henry schaffer
sdyer@bbncc5.UUCP (Steve Dyer) (09/13/85)
> <>When I bought an 8087 to put in my IBM PC, it came with a new 8088. > I was told to replace the 8088 when I put in the 8087 because the old > 8088 might not work properly with the 8087. I didn't feel like > experimenting, so I did the replacement. > > <>Question: Is this kind of matching really necessary, and, if so, > does one have to worry about replacing an 8088 with a V20 in a system > with an 8087? (Also same question for 80286, V30, 80287.) This was IBM marketing hype. There may have been a *very* small chance that your 8088 wouldn't work with an arbitrary 8087, but hardly enough to worry over. I have purchased two 8087s and a 287 for use in PC-type machines and they work just fine. Buy the V20 and don't worry. -- /Steve Dyer {harvard,seismo}!bbnccv!bbncc5!sdyer sdyer@bbncc5.ARPA
hall@ittral.UUCP (Doug Hall) (09/13/85)
I am using the NEC V20 in my ITT Xtra (a little known but very nice MS-DOS machine) with the 8087 co-processor. I have had no problems with it. Anybody want to buy a used 8088? ;-) Douglas Hall ITT Telecom Raleigh, NC ittatc!ittral!hall
kim@mips.UUCP (Kim DeVaughn) (09/14/85)
[ ... ] > <>When I bought an 8087 to put in my IBM PC, it came with a new 8088. > I was told to replace the 8088 when I put in the 8087 because the old > 8088 might not work properly with the 8087. > <>Question: Is this kind of matching really necessary, and, if so, > does one have to worry about replacing an 8088 with a V20 in a system > with an 8087? (Also same question for 80286, V30, 80287.) Ummm, let's see if I remember this correctly ... It seems that in a very early release of the 8088 (8086, both, ?), there was a bug that could cause problems when altering a segment register. The most common manifestation was in restoration of the SS:SP reg pair from a previously stored pair of values such as: mov SS,StakSegSav mov SP,StakOffSav The 808x chips are designed such that an interrupt (should one occur) will not be recognized immediately after the seg-reg altering instruction, but will be held pending until after the execution of the instruction that *follows* it has completed. This is so you don't end up with a meaningless SS:SP pointer, for example. Well, these early chips would go ahead and take the rupt immediately, which led to an occasional crash ... a tough one to isolate, I might add. I believe that the inclusion of a new 8088 with the 8087 purchase was just used as an opportunity to try and purge the early chips out of as many systems as possible. While it is true that the 8087 can be setup to generate a rupt on various error conditions (so a user written handler can try to clean things up), in practice, I believe most packages rely on the internal 8087 error-handlers (defined as part of the IEEE-754 standard). In summary, I would not expect a problem with the V20/V30 chips, as the 808x architecture is very well understood now ... of course there may be other surprises lurking in this new implementation of (and extension to) that architecture. Now if I can just get my hands on an 8 MHz V30 ... BTW ... there *was* a release of PC-DOS that had a related problem. There were several places in the code where the programmer coded: mov SP,fooPlace mov SS,barPlace instead of: mov SS,... mov SP,... I don't recall the particular release, and I *think* it was only for the PC-Jr. There was a set of patches to correct this problem published in "PC Tech Journal" magazine sometime within the past year or so. Anyone experiencing occasional, unexplainable, un-reproducable crashes might want to check this out. /kim "You can have peace. Or you can have freedom. Don't ever count on having both at once." --- Lazarus Long. [Generic disclaimer.] -- UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!kim DDD: 415-960-1200 USPS: MIPS Computer Systems Inc, 1330 Charleston Rd, Mt View, CA 94043