The Intel 8087 And Conditional Microcode Tests

Continuing his reverse-engineering of the Intel 8087, [Ken Shirriff] covers the conditional tests that are implemented in the microcode of this floating point processing unit (FPU). This microcode contains the details on how to perform the many types of specialized instructions, like cos and arctan, all of which decode into many microcode ops. These micro ops are executed by the microcode engine, which [Ken] will cover in more detail in an upcoming article, but which is effectively its own CPU.

Conditional instructions are implemented in hardware, integrating the states of various functional blocks across the die, ranging from the instruction decoder to a register. Here, the evaluation is performed as close as possible to the source of said parameter to save on wiring.

Implementing this circuitry are multiplexers, with an example shown in the top die shot image. Depending on the local conditions, any of four pass transistors is energized, passing through that input. Not shown in the die shot image are the inverters or buffers that are required with the use of pass transistors to amplify the signal, since pass transistors do not provide that feature.

Despite how firmly obsolete the 8087 is today, it still provides an amazing learning opportunity for anyone interested in ASIC design, which is why it’s so great that [Ken] and his fellow reverse-engineering enthusiasts keep plugging away at recovering all this knowledge.

Reverse-Engineering The Tamagotchi IR Connection

The Tamagotchi Connection is a series of Tamagotchi toys that took the original portable pet concept and mixed things up with a wireless connection, which allowed you to interact with the pets of other proud Tamagotchi owners. This wireless connection is implemented using an infrared transceiver, somewhat like IrDA, but as [Zach Resmer] discovered while reverse-engineering this connection, it’s actually what is called ‘Nearly NEC’ by [Natalie Silvanovich], who has a GitHub repository full of related Tamagotchi hacking tools and ROM dumps.

With the protocol figured out, creating a transceiver for low-bitrate infrared communication isn’t particularly hard. In this case, it was implemented using an RP2040 MCU and an appropriate IR LED and receiver pair. This Tamagometer project was also implemented as an app for the Flipper Zero, and a custom PCB called the Pico TamaBadge by [Daniel Weidman].

There’s a web application associated with [Zach]’s project using a Web Serial-enabled browser (i.e. Chrome). The serial protocol is somewhat documented in the patent for the device’s connection feature, which makes it relatively easy to implement yourself.

The Issue With Wii U Gamepads And How To Clone Them

The Wii U running Mario Kart with the Gamepad duplicating the main screen. (Credit: MattKC, YouTube)
The Wii U running Mario Kart with the Gamepad duplicating the main screen. (Credit: MattKC, YouTube)

How hard would it be to clone the Wii U gamepad, the quirky controller with its unique embedded screen? This is the question that [MattKC] faced as he noticed the complete lack of Wii U gamepad replacements from either Nintendo or third-parties, leading him down the rabbit hole of answering said question.

Although unloved and even despised in compared to the Nintendo Wii, the Wii U was a solid system in its own right. One of its interesting additions was the gamepad controller, whose screen games used for features like a private screen during multiplayer and 3DS-like map screens. Its main weakness is however that the Wii U gamepad was considered an irreplaceable part of the console, which is obviously not fun if your gamepad breaks and your console along with it.

The Wii U console and gamepad communicate via 5 GHz 802.11n WiFi, but in order to deter other parties from simply hopping onto the access point, Nintendo slightly obfuscated this WiFi standard. Specifically the WPA authentication was modified by a byte swap in the PTK, rendering every existing WiFi stack incompatible with the Wii U.

Continue reading “The Issue With Wii U Gamepads And How To Clone Them”

Ken Shirriff working on the Commodore PET

This 8-Bit Commodore PET Was Hard To Fix

Over on [Ken Shirriff]’s blog is a tricky Commodore PET repair: tracking down 6 1/2 bad chips. WARNING: contains 8-bit assembly code.

The Trinity of 1977 which started the personal computer revolution were the Apple II, the Commodore PET, and the TRS-80. In this project it’s a failing Commodore PET which is being restored.

Continue reading “This 8-Bit Commodore PET Was Hard To Fix”

39C3: Recreating Sandstorm

Some synthesizer sounds are just catchy, but some of them are genre-defining. We think you could make that case for the Roland JP-8000 patch “Sandstorm”, which you’ve heard if you listened to any trance from the 90’s, but especially the song that was named after it.

“Sandstorm” is powered by the Roland Supersaw, and synth nerds have argued for a decade about how it’s made. The JP-8000 is a digital synthesizer, though, so it’s just code, run through custom DSP chips. If you could reverse engineer these chips, make a virtual machine, and send them the right program, you could get the sound 100% right. Think MAME but for synthesizers.

That brings us to [giulioz]’s talk at the 39th Chaos Communication Congress, where he dives deep into the custom DSP chip at the heart of the JP-8000. He and his crew had approached older digital synths by decapping and mapping out the logic, as you often do in video game emulation. Here, getting the connections right turned out to be simply too daunting, so he found a simpler device that had a test mode that, combined with knowledge of the chip architecture, helped him to figure out the undocumented DSP chip’s instruction set.

After essentially recreating the datasheet from first principles for a custom chip, [guiloz] and team could finally answer the burning question: “how does the Supersaw work”?  The horrifying answer, after all this effort, is that it’s exactly what you’d expect — seven sawtooth waves, slightly detuned, and layered over each other. Just what it sounds like.

The real end result is an emulation that’s every bit (tee-hee!) as good as the original, because it’s been checked out on a logic analyzer. But the real fun is the voyage. Go give the talk a watch.

39C3: Hacking Washing Machines

Many of us have them, few of us really hack on them: well, here we’re talking about large home appliances. [Severin von Wnuck-Lipinski] and [Hajo Noerenberg] were both working on washing machines, found each other, and formed a glorious cooperation that ended in the unholy union of German super-brands Miele and B/S/H — a Miele washer remote controlled by Siemens’ web app.

This talk, given at the 39th Chaos Communication Congress (39C3), is about much more than the stunt hack, however. In fact, we covered [Severin]’s work on the very clever, but proprietary, Miele Diagnostic Interface a little while ago. But now, he’s got it fully integrated into his home automation system. It’s a great hack, and you can implement it without even opening the box.

About halfway through the talk, [Hajo] takes over, dissecting the internal D-Bus communication protocol. Here, you have to open up the box, but then you get easy access to everything about the internal state of the machine. And D-Bus seems to be used in a wide range of B/S/H/ home appliances, so this overview should give you footing for your own experimentation on coffee machines or dishwashers as well. Of course, he wires up an ESP32 to the bus, and connects everything, at the lowest level, to his home automation system, but he also went the extra mile and wrote up a software stack to support it.

It’s a great talk, with equal parts humor and heroic hacking. If you’re thinking about expanding out your own home automation setup, or are even just curious about what goes on inside those machines these days, you should absolutely give it a watch.

Editor Note: The “S” is Siemens, which is Hackaday’s parent company’s parent company. Needless to say, they had nothing to do with this work or our reporting on it.

Reverse-Engineering The Intel 8087 Stack Circuitry

Although something that’s taken for granted these days, the ability to perform floating-point operations in hardware was, for the longest time, something reserved for people with big wallets. This began to change around the time that Intel released the 8087 FPU coprocessor in 1980, featuring hardware support for floating-point arithmetic at a blistering 50 KFLOPS. Notably, the 8087 uses a stack-based architecture, a major departure from existing FPUs. Recently [Ken Shirriff] took a literal closer look at this stack circuitry to see what it looks like and how it works.

Nearly half of the 8087’s die is taken up by the microcode frontend and bus controller, with a block containing constants like π alongside the FP calculation-processing datapath section taking up much of the rest. Nestled along the side are the eight registers and the stack controller. At 80 bits per FP number, the required registers and related were pretty sizeable for the era, especially when you consider that the roughly 60,000 transistors in the 8087 were paired alongside the 29,000 transistors in the 16-bit 8086.

Each of the 8087’s registers is selected by the decoded instructions via a lot of wiring that can still be fairly easily traced despite the FPU’s die being larger than the CPU it accompanied. As for the unique stack-based register approach, this turned out to be mostly a hindrance, and the reason why the x87 FP instructions in the x86 ISA are still quite maligned today. Yet with careful use, providing a big boost over traditional code, this made it a success by that benchmark, even if MMX, SSE, and others reverted to a stackless design.