How Would A Field Sequential Home Computer Have Worked?

The early history of colour TV had several false starts, of which perhaps one of the most interesting might-have-beens was the CBS field-sequential system. This was a rival to the nascent system which would become NTSC, which instead of encoding red, green, and blue all at once for each pixel, made sequential frames carry them.

The Korean war stopped colour TV development for its duration in the early 1950s, and by the end of hostilities NTSC had matured into what we know today, so field-sequential colour became a historical footnote. But what if it had survived? [Nicole Express] takes into this alternative history, with a look at how a field-sequential 8-bit home computer might have worked.

The CBS system had a much higher line frequency in order to squeeze in those extra frames without lowering the overall frame rate, so given the clock speeds of the 8-bit era it rapidly becomes obvious that a field-sequential computer would be restricted to a lower pixel resolution than its NTSC cousin. The fantasy computer discussed leans heavily on the Apple II, and we explore in depth the clock scheme of that machine.

While it would have been possible with the faster memory chips of the day to achieve a higher resolution, the conclusion is that the processor itself wasn’t up to matching the required speed. So the field-sequential computer would end up with wide pixels. After a look at a Breakout clone and how a field-sequential Atari 2600 might have worked, there’s a conclusion that field-sequential 8-bit machines would not be as practical as their NTSC cousins. From where we’re sitting we’d expect them to have used dedicated field-sequential CRT controller chips to take away some of the heartache, but such fantasy silicon really is pushing the boundaries.

Meanwhile, while field-sequential broadcast TV never made it, we do have field-sequential TV here in 2026, in the form of DLP projectors. We’ve seen their spinning filter disks in a project or two.


1950 CBS color logo: Archive.org, CC0.

Diagnosing A Mysterious Fault With A Commodore 1541 Disk Drive

Some PCB corrosion on the bottom of the 1541 drive. (Credit: TheRetroChannel, YouTube)
Some PCB corrosion on the bottom of the 1541 drive. (Credit: TheRetroChannel, YouTube)

Recently [TheRetroChannel] came across an interesting failure mode on a Commodore 1541 5.25″ floppy disk drive, in the form of the activity LED blinking just once after power-up with the drive motor continuously spinning. Since the Flash Codes that Commodore implemented and bothered to document start at 2 flashes (for RAM-related Zero Page), this raised the question of what fault this drive had, and whether a single flash is some kind of undocumented error code.

A cursory check showed that the heads were okay and not shorted, ruling out a common fault with the used floppy mechanism. Cleaning up the corrosion on IC sockets and similar basic operations were performed next, without making a change, nor did removing the ICs to induce it to produce the documented error codes, but this helped narrow down the potential causes. Especially after swapping in known-good ICs failed to make a difference. One possibility was that the drive was boot looping, as the activity LED is lit up once on boot.

Some probing around with an oscilloscope between the faulty and a working drive seemed to point to a faulty RAM IC, but while probing the faulty drive suddenly initialized successfully. After some more poking around it appeared that the drive was fine after it had a chance to warm up, which just deepened the mystery.

The drive did talk to a C64 with diagnostic cartridge at this point, but would often glitch out. Ultimately it appears that a dodgy IC socket and a few bad traces were to blame for the behavior, making it an ‘obvious in hindsight’ repair. The bottom of the PCB had some clear corrosion on it, but the affected traces were apparently still hanging on for dear life with the drive still initializing once warmed up.

Continue reading “Diagnosing A Mysterious Fault With A Commodore 1541 Disk Drive”

How Usable Is Windows 98 In 2026?

With the RAM and storage crisis hitting personal computing very hard – along with new software increasingly suffering the effects of metastasizing ‘AI’ – more people than ever are pining for the ‘good old days’. For example, using that early 2000s desktop PC with Windows 98 SE might now seem to be a viable alternative in 2026, because it couldn’t possibly make things worse. Or could it? As a reality check, [SteelsOfLiquid] over on YouTube gave this setup a whirl.

The computer of choice is a very common Dell Dimension 2100, featuring a zippy 1.1 GHz Intel Celeron, 256 MB  of DDR1, and a spacious 38 GB HDD. Graphics are provided by the iGPU in the Intel i810 chipset, all in a compact, 6.9 kg light package. As an early Windows XP PC, this gives Windows 98 SE probably a pretty solid shot at keeping up with the times. At least the early 2000s, natch.

Of course, there is a lot of period-correct software you can install, such as Adobe Photoshop 5, MS Office 97 (featuring everyone’s beloved Clippy), but a lot of modern software also runs, with the Retro Systems Revival blog documenting many that still run on Win98SE in some manner, including Audacity 2.0. This makes it totally suitable for basic productivity things.

Continue reading “How Usable Is Windows 98 In 2026?”

Restoring A Commodore PET 3032 In Rough Condition

The restored PET/CBM 3032. (Credit: Drygol, retrohax.net)
The restored PET/CBM 3032. (Credit: Drygol, retrohax.net)

The Commodore CBM 3032 is a successor to the original Commodore PET 2001, yet due a conflicting trademark issue with Philips these first European PETs were called ‘CBM’ instead. Hence the labeling on the CBM 3032 that [Drygol] had in for a restoration, which would have been produced somewhere between 1979 and the cessation of its manufacturing a few years later. This former machine of the University of Szcezecin in Poland had languished in a basement until a local demoscene group came across it and wanted to use it, after a restoration.

Although at first glance from just the front it didn’t look too shabby, problems were apparent from just a walkaround, including rusty and buckled paneling, showing that the time spent in storage had not done it any favors. Internally there was decades worth of dust, along with a dodgy potentiometer, cold joints and some PCB-level bodges that may or may not have been there from the factory.

The main case was disassembled by drilling out the rivets to gain full access to every nook and cranny, allowing for a good cleaning and repainting prior to putting in fresh rivets. On the PCB side of things, a potentiometer and an LM340KC-12 linear regulator in a TO-3 package had to be replaced, after which the system managed to boot reliably once in every three attempts.

Fixing this took basically cleaning all contacts and IC sockets, as well as refurbishing the keyboard, with corrosion and the occasional broken trace causing a lot of grief. Ultimately the system was restored and ready to be put into demoscene service.

 

How The Chornobyl NPP Got Modernized In The 1990s

During the 1990s the Chornobyl Nuclear Power Plant – formerly the Chernobyl NPP – continued operating with its remaining three RBMK reactors, but of course the 1970s-era automation with its very limited SKALA computer required some serious modernization. What was interesting here is that instead of just replacing this entire Soviet-era mainframe with a brand-new 1990s one, the engineers responsible opted to build a new system – called DIIS – around it. This is detailed in a recent video by the [Chornobyl Family] on YouTube.

This SKALA industrial control system was previously detailed in a video, covering this 24-bit mainframe computer and its many limitations. It wasn’t quite a real-time control system, but it basically did what it was designed to do. Since at the time it was not clear for how long these three RBMKs would be kept running, they didn’t want to go overboard with investments either.

Ultimately Unit 2 only was active until 1991 due to a turbine fire, Unit 1 until 1996 and Unit 3 was shutdown for the last time in 2000, so this a sensible decision. During those years, an auxiliary information-measurement system (DIIS) was the big upgrade, which got bridged into SKALA via a Ukrainian-made SM-1210 minicomputer, with the latter connected to an 80386 PC which itself was connected to an ARCnet hub.

Continue reading “How The Chornobyl NPP Got Modernized In The 1990s”

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”