A Die-Level Look At The Pentium FDIV Bug

The early 1990s were an interesting time in the PC world, mainly because PCs were entering the zeitgeist for the first time. This was fueled in part by companies like Intel and AMD going head-to-head in the marketplace with massive ad campaigns to build brand recognition; remember “Intel Inside”?

In 1993, Intel was making some headway in that regard. The splashy launch of their new Pentium chip in 1993 was a huge event. Unfortunately an esoteric bug in the floating-point division module came to the public’s attention. [Ken Shirriff]’s excellent account of that kerfuffle goes into great detail about the discovery of the bug. The issue was discovered by [Dr. Thomas R. Nicely] as he searched for prime numbers. It’s a bit of an understatement to say this bug created a mess for Intel. The really interesting stuff is how the so-called FDIV bug, named after the floating-point division instruction affected, was actually executed in silicon.

We won’t presume to explain it better than [Professor Ken] does, but the gist is that floating-point division in the Pentium relied on a lookup table implemented in a programmable logic array on the chip. The bug was caused by five missing table entries, and [Ken] was able to find the corresponding PLA defects on a decapped Pentium. What’s more, his analysis suggests that Intel’s characterization of the bug as a transcription error is a bit misleading; the pattern of the missing entries in the lookup table is more consistent with a mathematical error in the program that generated the table.

The Pentium bug was a big deal at the time, and in some ways a master class on how not to handle a complex technical problem. To be fair, this was the first time something like this had happened on a global scale, so Intel didn’t really have a playbook to go by. [Ken]’s account of the bug and the dustup surrounding it is first-rate, and if you ever wanted to really understand how floating-point math works in silicon, this is one article you won’t want to miss.

Amiga Gets A PS/2 Keyboard Port

Name any retrocomputer — Apple II, Sinclair, even TRS-80s — and you’ll find a community that’s deeply committed to keeping it alive and kicking. It’s hard to say which platform has the most rabid fans, but we’d guess Commodore is right up there, and the Amiga aficionados seem particularly devoted. Which is where this Amiga PS/2 mouse port comes from.

The Amiga was a machine that was so far ahead of its time that people just didn’t get it. It was a true multimedia machine before multimedia was even a thing, capable of sound and graphics that hold up pretty well to this day. From the looks of [jtsiomb]’s workstation, he’s still putting his Amiga to good use, albeit with an inconvenient amount of cable-swapping each time he needs to use it. The remedy this, [jtsiomb] put together an emulator that translates scancodes from an external PS/2 keyboard into Amiga keyboard signals. Embedded inside the Amiga case where it can intercept the internal keyboard connector, the emulator is an ATmega168 that does a brute-force translation by way of lookup tables. A switch on the back allows him to choose the internal keyboard or his PS/2 keyboard via a KVM switch.

Are Amigas really still relevant? As of two years ago, one was still running an HVAC system for a school. We’re not sure that’s a testament to the machine or more a case of bureaucratic inertia, but it’s pretty impressive either way.

[via r/electronics]

Morse Decoder’s Lean And Sexy Search Algorithm

Often the Morse Code centered projects that we feature are to help you practice transmitting messages. This one takes a tack and builds an automatic decoder. We think [Nicola Cimmino’s] project is well worth featuring simply based on his explanation of the Digital Signal Processing used on the signal coming in from the microphone. Well done. But he’s really just getting warmed up.

What makes this really stand out is a brilliant algorithm that allows conversion from Morse to ASCII using a lookup table of only 64 bytes. This provides enough room for A-Z and 0-9 without chance of collision but could be expanded to allow for more characters. Below is a concise description of how the algorithm works but make sure you take the time to read [Nicola’s] project description in its entirety.

The algorithm can be decribed as follows. Have an index inside the lookup string inizialied to zero. Have an initial dash jump size of 64. At every received element (dot or dash) halve the initial dash jump and then increase by 1 the index inside the lookup string if a dot was received and by dash jump size if a dash was received. Repeat until a letter separator is reached, at that point the index inside the lookup string will point to the ASCII corresponding to the decoded morse.

Have you heard of this technique before? If so, tell us about it in the comments below. Before you jump all over this one, realize that Magic Morse uses a different technique.