The Apple II MouseCard (Credit: AppleLogic.org)

The Apple II MouseCard IRQ Is Synced To Vertical Blanking After All

May 9, 2025 by Maya Posch 5 Comments

Recently [Colin Leroy-Mira] found himself slipping into a bit of a rabbit hole while investigating why only under Apple II MAME emulation there was a lot of flickering when using the (emulated) Apple II MouseCard. This issue could not be reproduced on real (PAL or NTSC) hardware. The answer all comes down to how the card synchronizes with the system’s vertical blanking (VBL) while drawing to the screen.

The Apple II MouseCard is one of the many peripheral cards produced for the system, originally bundled with a version of MacPaint for the Apple II. While not a super popular card at the time, it nevertheless got used by other software despite this Apple system still being based around a command line interface.

According to the card’s documentation the interrupt call (IRQ) can be set to 50 or 60 Hz to match the local standard. Confusingly, certain knowledgeable people told him that the card could not be synced to the VBL as it had no knowledge of this. As covered in the article and associated MAME issue ticket, it turns out that the card is very much synced with the VBL exactly as described in The Friendly Manual, with the card’s firmware being run by the system’s CPU, which informs the card of synchronization events.

The 386's main register bank, at the bottom of the datapath. The numbers show how many bits of the register can be accessed. (Credit: Ken Shirriff)

The Convoluted Way Intel’s 386 Implemented Its Registers

May 5, 2025 by Maya Posch 5 Comments

The fact that modern-day x86 processors still pretty much support the same operating systems and software as their ancestors did is quite a feat. Much of this effort had already been accomplished with the release of the 80386 (later 386) CPU in 1985, which was not only the first 32-bit x86 CPU, but was also backwards compatible with 8- and 16-bit software dating back to the 1970s. Making this work transparently was anything but straightforward, as [Ken Shirriff]’s recent analysis of the 80386’s main register file shows.

Labelled Intel 80386 die shot. (Credit: Ken Shirriff)

Using die shots of the 386’s registers and surrounding silicon, it’s possible to piece together how backwards compatibility was implemented. The storage cells of the registers are implemented using static memory (SRAM) as is typical, with much of the register file triple-ported (two read, one write).

Most interestingly is the presence of different circuits (6) to support accessing the register file for 8-, 16- or 32-bit writes and reads. The ‘shuffle’ network as [Ken] calls it is responsible for handling these distinct writes and reads, which also leads to the finding that the bottom 16 bits in the registers are actually interleaved to make this process work smoother.

Fortunately for Intel (and AMD) engineers, this feat wouldn’t have to be repeated again with the arrival of AMD64 and x86_64 many years later, when the 386’s mere 275,000 transistors on a 1 µm process would already be ancient history.

Want to dive even deeper in to the 386? This isn’t the first time [Ken] has looked at the iconic chip.

Modernizing An Enigma Machine

April 17, 2025 by Matt Varian 6 Comments

This project by [Miro] is awesome, not only did he build a replica Enigma machine using modern technologies, but after completing it, he went back and revised several components to make it more usable. We’ve featured Enigma machines here before; they are complex combinations of mechanical and electrical components that form one of the most recognizable encryption methods in history.

His first Enigma machine was designed closely after the original. He used custom PCBs for the plugboard and lightboard, which significantly cleaned up the internal wiring. For the lightboard, he cleverly used a laser printer on semi-transparent paper to create crisp letters, illuminated from behind. For the keyboard, he again designed a custom PCB to connect all the switches. However, he encountered an unexpected setback due to error stack-up. We love that he took the time to document this issue and explain that the project didn’t come together perfectly on the first try and how some adjustments were needed along the way.
Continue reading “Modernizing An Enigma Machine” →

A Tricky Commodore PET Repair And A Lesson About Assumptions

April 14, 2025 by Maya Posch 11 Comments

The PET opened, showing the motherboard. (Credit: Ken Shirriff)

An unavoidable part of old home computer systems and kin like the Commodore PET is that due to the age of their components they will develop issues that go far beyond what was covered in the official repair manual, not to mention require unconventional repairs. A case in point is the 2001 series Commodore PET that [Ken Shirriff] recently repaired.

The initial diagnosis was quite straightforward: it did turn on, but only displayed random symbols on the CRT, so obviously the ICs weren’t entirely happy, but at least the power supply and the basic display routines seemed to be more or less functional. Surely this meant that only a few bad ICs and maybe a few capacitors had to be replaced, and everything would be fully functional again.

Initially two bad MOS MPS6540 ROM chips had to be replaced with 2716 EPROMs using an adapter, but this did not fix the original symptom. After a logic analyzer session three bad RAM ICs were identified, which mostly fixed the display issue, aside from a quaint 2×2 checkerboard pattern and completely bizarre behavior upon running BASIC programs.

Using the logic analyzer capture the 6502 MPU was identified as writing to the wrong addresses. Ironically, this turned out to be due to a wrong byte in one of the replacement 2716 EPROMs as the used programmer wasn’t quite capable of hitting the right programming voltage. Using a better programmer fixed this, but on the next boot another RAM IC turned out to have failed, upping the total of failed silicon to four RAM & two ROM ICs, as pictured above, and teaching the important lesson to test replacement ROMs before you stick them into a system.

The host stands in his electronics lab with the image of four remote controls overlaid.

Introducing Infrared Remote Control Protocols

April 13, 2025 by John Elliot V 23 Comments

Over on his YouTube channel [Electronic Wizard] has released a video that explains how infrared (IR) remote controllers work: IR Remote Controllers protocol: 101 to advanced.

This video covers the NEC family of protocols, which are widely used in typical consumer IR remote control devices, and explains how the 38 kHz carrier wave is used to encode a binary signal. [Electronic Wizard] uses his Rigol DS1102 oscilloscope and a breadboard jig to sniff the signal from an example IR controller.

There is also an honorable mention of the HS0038 integrated-circuit which can interpret the light waves and output a digital signal. Of course if you’re a tough guy you don’t need no stinkin’ integrated-circuit IR receiver implementation because you can build your own!

Before the video concludes there is a brief discussion about how to interpret the binary signal using a combination of long and short pulses. If this looks similar to Morse Code to you that’s because it is similar to Morse Code! But not entirely the same, as you will learn if you watch the video!

Hacking A Cheap Rechargeable Lamp With Non-Standard USB-C Connector

April 12, 2025 by Maya Posch 40 Comments

Recently [Dillan Stock] bought a $17 ‘mushroom’ lamp from his local Kmart that listed ‘USB-C rechargeable’ as one of its features. Unfortunately while this is technically true, there’s a pretty major asterisk. This Inaya-branded lamp comes with a USB-C cable with a rather prominent label attached to it that tells you that this lamp requires that specific cable. After trying with a regular USB-C cable, [Dillan] indeed confirmed that the lamp does not charge from a standard USB-C cable. So he did what any reasonable person would do: he bought a second unit and set about to hacking it.

The "USB C" cable that comes with the Inaya Portable Rechargeable Lamp. (Credit: The Stock Pot, YouTube) — The “USB C” cable that comes with the Inaya Portable Rechargeable Lamp. (Credit: The Stock Pot, YouTube)

[Dillan] also dug more into what’s so unusual about this cable and the connector inside the lamp. As it turns out, while GND & VCC are connected as normal, the two data lines (D+, D-) are also connected to VCC. Presumably on the lamp side this is the expected configuration, while using a regular USB-C cable causes issues. Vice versa, this cable’s configuration may actually be harmful to compliant USB-C devices, though [Dillan] did not try this.

With the second unit in hand, he started hacking in earnest. The changes include a regular USB-C port for charging, an ESP32 board with integrated battery charger for the 18650 Li-ion cell of the lamp, and an N-channel MOSFET to switch the power to the lamp’s LED. He’s made the full plans and schematics available on his website.

With all of the raw power from the ESP32 available, the two lamps got integrated into the Home Assistant network which enables features such as turning the lamps on when the alarm goes off in the morning. All of this took about $7 in parts and a few hours of work.

Although we commend [Dillan] on hacking his device instead of just returning it to the store, it’s worrying that apparently there’s now a flood of ‘USB C-powered’ devices out there that come with non-compliant cables. It brings back fond memories of hunting down proprietary charging cables, which was the issue that USB power was supposed to fix.

Continue reading “Hacking A Cheap Rechargeable Lamp With Non-Standard USB-C Connector” →

A Toothbrush Hacked, In Three Parts

April 2, 2025 by Tom Nardi 7 Comments

It’s official, we’re living in the future. Certainly that’s the only explanation for how [wrongbaud] was able to write a three-part series of posts on hacking a cheap electric toothbrush off of AliExpress.

As you might have guessed, this isn’t exactly a hack out of necessity. With a flair for explaining hardware hacking, [wrongbaud] has put this together as a practical “brush-up” (get it?) on the tools and concepts involved in reverse engineering. In this case, the Raspberry Pi is used as a sort of hardware hacking multi-tool, which should make it relatively easy to follow along.

Modified image data on the SPI flash chip.

The first post in the series goes over getting the Pi up and running, which includes setting up OpenOCD. From there, [wrongbaud] actually cracks the toothbrush open and starts identifying interesting components, which pretty quickly leads to the discovery of a debug serial port. The next step is harassing the SPI flash chip on the board to extract its contents. As the toothbrush has a high-res color display (of course it does), it turns out this chip holds the images which indicate the various modes of operation. He’s eventually able to determine how the images are stored, inject new graphics data, and write it back to the chip.

Being able to display the Wrencher logo on our toothbrush would already be a win in our book, but [wrongbaud] isn’t done yet. For the last series in the post, he shows how to extract the actual firmware from the microcontroller using OpenOCD. This includes how to analyze the image, modify it, and eventually flash the new version back to the hardware — using that debug port discovered earlier to confirm the patched code is running as expected.

If you like his work with a toothbrush, you’ll love seeing what [wrongbaud] can do with an SSD or even an Xbox controller.