I found one of these when I was Autodesk back in the early 90s.
It's been awhile, so I'm undoubtedly remembering something incorrectly.
This was in the early days of protected mode DOS software. Some customers were reporting an lockup issue with AutoCAD in rare instances when a particular command was used.
It took awhile, but I finally narrowed it down to running the "3-point arc" command on a system with a math co-processor and low memory (so it's paging) on certain 386-20 chips.
I don't recall the exact fix, but we did put some Intel-recommended code in the app to workaround the lockup. The 386 was quickly superseded by the 486 (which had its math co-processor built in which was huge for AutoCAD users back then) so this entire issue quickly disappeared.
The 486DX was the original 486 and it definitely did include an FPU. The FPU-free 486SX came along a couple of years later. My recollection is that the SX was originally a way to make use of 486DX chips that failed manufacturing tests on the FPU; they'd disconnect the FPU portion of the die and sell the busted chips as "486SX". Same trick AMD pulled with the 3-core Phenom.
My apologies; I thought you were making a comment which was intended to be relevant to the one you were replying to, which concerned the change from the 386 to 486DX. I am not sure what relevance the configuration of the later 486SX would have to the situation msisk6 described.
Assembling a detailed and accurate history of the 80386, including a complete listing of all the "steppings" (revisions), when they were released, what "errata" (problems) each stepping suffered from, and which of those problems were fixed by a later stepping, seems virtually impossible at this late date.
I'd guess that part of this could be because a lot of interesting info used to be on various small now-defunct or deindexed sites. Even if it's largely historical information, it doesn't feel right to just let it disappear, as sometimes it can be used to solve some mysteries. It's too bad the Internet Archive doesn't have a Google-like search function.
However, as long as this list is, it seems to be missing the somewhat more famous POPA(D) bug:
That list is still easy to find via Google? I believe it is bundled with the Ralph Brown interrupt list.
What "doesn't feel right to me" is Google's treatment of Usenet archives.
It should still be possible to download these messages in their original plain text format, in bulk using only the internet... i.e., without using the www and all the cruft that comes with it.
Hah, this resonates with me. I was so excited about the PIC32MZ family (MIPS M4K with a decent amount of RAM and some peripherals, cool!) but the errata is just staggering. These chips are "in production" but the errata is long, and it's not just bugs and functions that fail to meet datasheet specs (which is pretty bad by itself)... a lot of functionality is simply listed as "does not function" or "not operational."
Yeah, this tends to happen a lot on modern microcontrollers with lots of complicated peripherals from what I've seen, especially in pre-production steppings of the chip
Some things seem downright scary in the first erratas
> Misaligned Selectors: If a 16-bit memory operand is loaded into a segment register, the 80386 hangs if the selector is not word-aligned
> Incorrect Interrupt Vector: If a maskable interrupt occurs immediately after the 80386 has executed an instruction with an 8-bit operand, the interrupt is always assigned a vector number of 0.
I can understand, since they probably did a lot of it by hand. It was also more advanced than the 80286 being 32-bit, memory protection (though I think some of it was on the 80286), etc
I'm not entirely sure if it was quite so heavily software synthesized at that point. I think a lot of the logic and datapath was still done by hand.
The grad student I think you're talking about is (now) Dr. Carl Sechen who developed an Auto Place and Route tool he named Timberwolf. Those tools don't synthesize logic so much as they choose optimal locations and orientations for the standard cells on the wafer and then attempt to route the metal interconnects (all with respect to timing). I think it wound up being rather buggy (to the point they had to keep calling him back from school work to patch some things up) and a fair number of things had to be corrected by hand.
I did hear that some of the units on the 386 were written in some Stanford devised programming language from the pre Verilog/VHDL toolstack days and that a few engineers in design automate hacked up a tool flow to turn that programming language into something synthesizable.
That said I wasn't there and so I can't claim to know for sure. I would wager there are some good interviews and documents either with the Intel Museum folks or the Computer History Museum in Mountain View (which seems to always have both contacts from the day and documents for all the old fun computing hardware).
The 386 was certainly an ambitious design in comparison to the 286, but the iAPX 432 which was several years before that was even more complex. I wonder what errata there were for the '432...
I believe the 286 supported virtual memory and memory protection but lacked a way to go from protected mode back to real mode, so it couldn't multitask real-mode DOS programs.
It's been awhile, so I'm undoubtedly remembering something incorrectly.
This was in the early days of protected mode DOS software. Some customers were reporting an lockup issue with AutoCAD in rare instances when a particular command was used.
It took awhile, but I finally narrowed it down to running the "3-point arc" command on a system with a math co-processor and low memory (so it's paging) on certain 386-20 chips.
I don't recall the exact fix, but we did put some Intel-recommended code in the app to workaround the lockup. The 386 was quickly superseded by the 486 (which had its math co-processor built in which was huge for AutoCAD users back then) so this entire issue quickly disappeared.
Fun times.