Inside SKALA: How Chernobyl’s Reactor Was Actually Controlled

March 3, 2026 by Maya Posch 3 Comments

Entering SKALA codes during RBMK operation. (Credit: Pripyat-Film studio)

Running a nuclear power plant isn’t an easy task, even with the level of automation available to a 1980s Soviet RBMK reactor. In their continuing efforts to build a full-sized, functional replica of an RBMK control room as at the Chornobyl Nuclear Power Plant – retired in the early 2000s – the [Chornobyl Family] channel has now moved on to the SKALA system.

Previously we saw how they replicated the visually very striking control panel for the reactor core, with its many buttons and status lights. SKALA is essentially the industrial control system, with multiple V-3M processor racks (‘frames’), each with 20k 24-bit words of RAM. Although less powerful than a PDP-11, its task was to gather all the sensor information and process them in real-time, which was done in dedicated racks.

Output from SKALA’s DREG program were also the last messages from the doomed #4 reactor. Unfortunately an industrial control system can only do so much if its operators have opted to disable every single safety feature. By the time the accident unfolded, the hardware was unable to even keep up with the rapid changes, and not all sensor information could even be recorded on the high-speed drum printer or RTA-80 teletypes, leaving gaps in our knowledge of the accident.

Continue reading “Inside SKALA: How Chernobyl’s Reactor Was Actually Controlled” →

SNES Controllers Are (Almost) SPI-Compatible

March 2, 2026 by Maya Posch 7 Comments

Considering that the Serial Peripheral Interface bus semi-standard has been around since the early 1980s, it’s perhaps not that shocking that the controllers of the Super Nintendo Entertainment System (SNES) would take at least some strong design hints for the used protocol. This does however raise the question of exactly how compatible a SNES controller is when connected to the SPI master peripheral of any random MCU. Recently [James Sharman] set out to answer this question decisively.

The impetus for answering this question came after [James] designed a separate SNES controller board for his homebrew computer system, which led to many comments on that video saying that he could just have hooked the controller up to the SPI board in said homebrew system.

Here the short answer is that the SNES controller protocol is very close to SPI Mode-1, with a similar arrangement of clock/data/chip select (latch) lines and clocking. If you think of the SNES controller as an SPI device with just a MISO line, you’re basically there already. The only niggle that popped up was that the ‘MISO’ line does not get pulled into a high-impedance state when the active-low latch connection is pulled high.

This was fixable by introducing a 74HC125 tri-state buffer IC, after which both the original SD card and twin SNES controllers could be used simultaneously.

Continue reading “SNES Controllers Are (Almost) SPI-Compatible” →

X-Ray A PCB Virtually

February 23, 2026 by Al Williams 20 Comments

If you want to reverse engineer a PC board, you could do worse than X-ray it. But thanks to [Philip Giacalone], you could just take a photo, load it into PCB Tracer, and annotate the images. You can see a few of a series of videos about the system below.

The tracer runs in your browser. It can let you mark traces, vias, components, and pads. You can annotate everything as you document it, and it can even call an AI model to help generate a schematic from the net list.

Continue reading “X-Ray A PCB Virtually” →

Inside A Compact Intel 3000 W Water-Cooled Power Supply

February 22, 2026 by Maya Posch 10 Comments

Recently [ElecrArc240] got his paws on an Intel-branded 3 kW power supply that apparently had been designed as a reference PSU for servers. At 3 kW in such a compact package air cooling would be rather challenging, so it has a big water block sandwiched between the two beefy PCBs. In the full teardown and analysis video of the PSU we can see the many design decisions made to optimize efficiency and minimize losses to hit its 80 Plus Platinum rating.

For the power input you’d obviously need to provide it with 240 VAC at sufficient amps, which get converted into 12 VDC at a maximum of 250 A. This also highlights why 48 VDC is becoming more common in server applications, as the same amount of power would take only 62.5 A at that higher voltage.

The reverse-engineered schematic shows it using an interleaved totem-pole PFC design with 600 V-rated TI LMG3422 600V GaN FETs in the power stages. After the PFC section we find a phase-shifted full bridge rectifier with OnSemi’s SiC UF3C065030K4S Power N-Channel JFETs.

There were a few oddities in the design, such as the Kelvin source of the SiC JFET being tied into the source, which renders that feature useless. Sadly the performance of the PSU was not characterized before it was torn apart which might have provided some clues here.

Continue reading “Inside A Compact Intel 3000 W Water-Cooled Power Supply” →

How The Intel 8087 FPU Knows Which Instructions To Execute

February 21, 2026 by Maya Posch 5 Comments

An interesting detail about the Intel 8087 floating point processor (FPU) is that it’s a co-processor that shares a bus with the 8086 or 8088 CPU and system memory, which means that somehow both the CPU and FPU need to know which instructions are intended for the FPU. Key to this are eight so-called ESCAPE opcodes that are assigned to the co-processor, as explained in a recent article by [Ken Shirriff].

The 8087 thus waits to see whether it sees these opcodes, but since it doesn’t have access to the CPU’s registers, sharing data has to occur via system memory. The address for this is calculated by the CPU and read from by the CPU, with this address registered by the FPU and stores for later use in its BIU register. From there the instruction can be fully decoded and executed.

This decoding is mostly done by the microcode engine, with conditional instructions like cos featuring circuitry that sprawls all over the IC. Explained in the article is how the microcode engine even knows how to begin this decoding process, considering the complexity of these instructions. The biggest limitation at the time was that even a 2 kB ROM was already quite large, which resulted in the 8087 using only 22 microcode entry points, using a combination of logic gates and PLAs to fully implement the entire ROM.

Only some instructions are directly implemented in hardware at the bus interface (BIU), which means that a lot depends on this microcode engine and the ROM for things to work half-way efficiently. This need to solve problems like e.g. fetching constants resulted in a similarly complex-but-transistor-saving approach for such cases.

Even if the 8087 architecture is convoluted and the ISA not well-regarded today, you absolutely have to respect the sheer engineering skills and out-of-the-box thinking of the 8087 project’s engineers.

HD On A VHS Tape? How Did They Do It?

February 20, 2026 by Jenny List 10 Comments

There was a period from the 1970s to the mid-2000s or so when a fixture underneath the family TV set was a VHS videocassette recorder. These were a masterpiece of cramming a color video signal into the restricted bandwidth of an affordable 1970s helical-scan tape deck, which was achieved by clever use of frequency shifting and FM carrier modulation. Very few of us will have had the ultimate iteration of the VHS format though, W-VHS, which managed the same trick but with HD video. But how? [Superchromat] is here with the answer.

W-VHS used a frequency modulated carrier, but instead of splitting luminance and chrominance in the frequency domain like its VHS ancestor, it did so in the time domain in the same way as some 1980s satellite TV standards did. Each line first contained the color information, then the brightness. Thus it sacrificed some color resolution and a little horizontal image resolution, but kept a much higher vertical image resolution. In the video below the break we go into significant detail about the compromises required to pull this off, and if you watch it through you’ll learn something about magnetic tape recording as well as FM.

The W-VHS standard is largely forgotten now as a last hurrah for the format, but it’s still in the sights of the VHS Decode project. The work in this video is helping them retrieve the highest quality images from these tapes, by capturing the raw RF from the heads and using DSP techniques to decode them.

Continue reading “HD On A VHS Tape? How Did They Do It?” →

Poking At The ESP32-P4 And -C6 Dies In An ESP32-P4-M3 Module

February 19, 2026 by Maya Posch 7 Comments

The RF section of the ESP32-C6 die. (Credit: electronupdate, YouTube)

With the ESP32-P4 not having any wireless functionality and instead focusing on being a small SoC, it makes sense to combine it with a second chip that handles features like WiFi and Bluetooth. This makes the Guition ESP32-P4-M3 module both a pretty good example of how the P4 will be used, and an excellent opportunity to tear into, decap and shoot photos of the dies of both the P4 and the ESP32-C6 in this particular module, courtesy of [electronupdate]. There also the blog post for those who just want to ogle the shinies.

After popping the metal shield on the module, you can see the contents as in the above photo. The P4 inside is a variant with 32 MB of PSRAM integrated along with the SoC die. This results in a die shot both of this PSRAM and the P4 die, though enough of the top metal seems to remain to clearly see the latter.

The Boya brand Flash chip is quite standard inside, and along with a glance at the inside of one of the crystal oscillators we get to glance at the inside of the C6 MCU. This is a much more simple chip than the P4, with the RF section quite obvious. The total die sizes are 2.7 x 2.7 mm for the C6 and 4.29 x 3.66 mm for the P4.

Continue reading “Poking At The ESP32-P4 And -C6 Dies In An ESP32-P4-M3 Module” →