Capacitor Memory Makes Homebrew Relay Computer Historically Plausible

It’s one thing to create your own relay-based computer; that’s already impressive enough, but what really makes [DiPDoT]’s design special– at least after this latest video— is swapping the SRAM he had been using for historically-plausible capacitor-based memory.

A relay-based computer is really a 1940s type of design. There are various memory types that would have been available in those days, but suitable CRTs for Williams Tues are hard to come by these days, mercury delay lines have the obvious toxicity issue, and core rope memory requires granny-level threading skills. That leaves mechanical or electromechanical memory like [Konrad Zuse] used in the 30s, or capacitors. he chose to make his memory with capacitors.

It’s pretty obvious when you think about it that you can use a capacitor as memory: charged/discharged lets each capacitor store one bit. Charge is 1, discharged is 0. Of course to read the capacitor it must be discharged (if charged) but most early memory has that same read-means-erase pattern. More annoying is that you can’t overwrite a 1 with a 0– a separate ‘clear’ circuit is needed to empty the capacitor. Since his relay computer was using SRAM, it wasn’t set up to do this clear operation.

He demonstrates an auto-clearing memory circuit on breadboard, using 3 relays and a capacitor, so the existing relay computer architecture doesn’t need to change. Addressing is a bit of a cheat, in terms of 1940s tech, as he’s using modern diodes– though of course, tube diodes or point-contact diodes could conceivably pressed into service if one was playing purist. He’s also using LEDs to avoid the voltage draw and power requirements of incandescent indicator lamps. Call it a hack.

He demonstrates his circuit on breadboard– first with a 4-bit word, and then scaled up to 16-bit, before going all way to a massive 8-bytes hooked into the backplane of his Altair-esque relay computer. If you watch nothing else, jump fifteen minutes in to have the rare pleasure of watching a program being input via front panel with a complete explanation. If you have a few extra seconds, stay for the satisfyingly clicky run of the loop. The bonus 8-byte program [DiPDoT] runs at the end of the video is pure AMSR, too.

Yeah, it’s not going to solve the rampocalypse, any more than the initial build of this computer helped with GPU prices. That’s not the point. The point is clack clack clack clack clack, and if that doesn’t appeal, we don’t know what to tell you.

Continue reading “Capacitor Memory Makes Homebrew Relay Computer Historically Plausible”

Success With FreeDOS On A Modern Platform

Last summer we took a look at FreeDOS as part of the Daily Drivers series, and found a faster and more complete successor to the DOS of old. The sojourn into the 16-bit OS wasn’t perfect though, as we couldn’t find drivers for the 2010-era network card on our newly DOS-ified netbook. Here’s [Inkbox] following the same path, and bringing with it a fix for that networking issue.

The video below is an affectionate look at the OS alongside coding a TRON clone in assembler, and it shows a capable environment within the limitations of the 16-bit mode. The modern laptop here can’t emulate a BIOS as it’s UEFI only, and after trying a UEFI-to-BIOS emulator with limited success, he hits on a different approach. With just enough Linux to support QEMU, he has a lightweight and extremely fast x86 BIOS platform with the advantage of legacy emulation of network cards and the like.

The point of Daily Drivers is wherever possible to use real hardware and not an emulator, as it’s trying to be the machine you’d use day to day. But we can see in a world where a BIOS is no longer a thing it becomes ever more necessary to improvise, and this approach is better than just firing up an emulator from a full-fat Linux desktop. If you fancy giving it a try, it seems less pain than the route we took.

You can read our look at FreeDOS 1.4 here.

Continue reading “Success With FreeDOS On A Modern Platform”

Making A 286 Think It’s Alive Again

[Nagy Krisztián] had an Intel 286 CPU, only… There was no motherboard to install it in. Perhaps not wanting the processor to be lonely, [Nagy] built a simulated system to bring the chip back to life.

Okay, 68 pins does look like a lot when you arrange them like that.

The concept is simple enough. [Nagy] merely intended to wire the 286 up to a Raspberry Pi Pico that could emulate other parts of a computer that it would normally expect to talk to. This isn’t so hard with an ancient CPU like the 286, which has just 68 pins compared to the 1000+ pins on modern CPUs. All it took was a PLCC-68 socket, an adapter PCB, a breadboard, and some MCP23s17 logic expanders to give the diminutive microcontroller enough I/O. With a bit of work, [Nagy] was able to get the Pi Pico running the 286, allowing it to execute a simple program that retrieves numbers from “memory” and writes them back in turn.

Notably, this setup won’t run the 286 at its full clock speed of 12 MHz, and it’s a long way off from doing anything complex like talking to peripherals or booting an OS. Still, it’s neat to see the old metal live again, even if it’s just rattling through a few simple machine instructions that don’t mean a whole lot. [Nagy] equates this project to The Matrix; you might also think of it as a brain in a jar. The 286 is not in a real computer; it’s just hooked up to a microcontroller stimulating its various pins in a way that is indistinguishable from its own perspective. Continue reading “Making A 286 Think It’s Alive Again”

Computer Terminal Replica Inspired By 70s Hardware

Not so long ago, most computer users didn’t own their own machines. Instead, they shared time on mainframes or servers, interacting with this new technology through remote terminals. While the rise of cloud computing and AI might feel like a modern, more dystopian echo of that era, some look back on those early days with genuine fondness. If you agree, check out this 70s-era terminal replica from [David Green].

The inspiration for this build was a Lear Siegler ADM-3A terminal seen at a local computer festival. These machines had no local computing resources and were only connected to their host computer via a serial connection. The new enclosure, modeled on this design, was 3D-printed and then assembled and finished for the classic 70s look. There are a few deviations from a 70s terminal, though: notably, a flat LCD panel and a Raspberry Pi 3, which, despite being a bit limited by today’s standards, still offers orders of magnitude more computing power than the average user in the 70s would have had access to.

Continue reading “Computer Terminal Replica Inspired By 70s Hardware”

Fixing The Damage Of A Botched SNES SuperCIC Mod

Not what you want to see when testing that 'repaired' SNES. (Credit: Skawo, YouTube)
Not what you want to see when testing that ‘repaired’ SNES. (Credit: Skawo, YouTube)

The good part about older game consoles like the Super Nintendo is that they have rather rudimentary region locks, but unfortunately this also gives some people the idea that installing something like the SuperCIC mod chip to make a SNES region-free is easy. The patient that arrived on [Skawo]’s surgery table was one such victim, with the patient requiring immediate surgery to remove the botched installation before assessing the damage.

Here the good news was that the patient features the revision B CPU, making it a good console to rescue. The bad news was that the pads of the old CIC chip had been ripped up, there was a solder bridge on S-PPU1 between two pins and both the installed wiring and soldering were atrocious, requiring plenty of touch-ups.

With the CIC pads already a loss, finishing the SuperCIC mod seemed like a good plan, also since this would make for a nice region-free console. This mod involves a PIC16F630 with special firmware that works with the corresponding CIC IC in each cartridge, while also switching between 50/60 Hz mode to fit the cartridge’s region. After an initial test with PAL and NTSC cartridges everything seemed all right. Then [Skawo] ran the SuperNES Burn-In test from its cartridge, which gave dire news.

Continue reading “Fixing The Damage Of A Botched SNES SuperCIC Mod”

ATABoy Is An Open Source USB Bridge For Old IDE Drives

You can get an IDE to USB bridge from all the usual sources, but you may find those fail on the older drives in your collection– apparently they require drives using logical block addressing, which did not become standard until the mid-1990s. Some while some older drives got in on the LBA game early, you were more likely to see Cylinder-Head-Sector (CHS) addressing. That’s why [JJ Dasher], a.k.a [redruM0381] created ATABoy, an open-source IDE bridge that can handle the oldest drives that fit on the bus.

The heart of the build is an RP2350, which serves as both IDE and USB host controller. To computer, after a little bit of setup, the drive attached to ATABoy shows up as a regular USB mass storage device. A little bit of setup is to be expected with drives of this vintage, you may remember. Luckily [JJ] included a handy BIOS-themed configuration utility that can be accessed through any serial console. He says you’ll usually be able to get away with “Auto Detect & Set Geometry,” but if you need to plug in the CHS values yourself, well, it’ll feel just like old times. Seeing is believing, so check it out in the demo video embedded below.

Though the custom PCB has a USB-C connector, and the USB-C standard could provide enough power for ye olde spinning rust drives, [JJ] didn’t include any power delivery with ATABoy. If you’re using it with a desktop, you can use the PSU in the box; MOLEX hasn’t changed. If you’re on a laptop, you’ll need another power supply– perhaps this USB-C powered benchtop unit.

If you’re using a Raspberry Pi or similar SBC, go ahead and skip USB entirely–the GIPO can do PATA IDE. Continue reading “ATABoy Is An Open Source USB Bridge For Old IDE Drives”

How The Intel 8087 FPU Knows Which Instructions To Execute

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.