Sega Master System Controllers, Now With USB C

USB wasn’t even a gleam in an engineer’s eye when the Sega Master System hit the market in 1985. Today, we’re up to USB 4 or something, and the USB C connector is becoming a defacto standard for just about everything except desktop computers. [Retrostalgia] is embracing this by mating the control pad from Sega’s first international console with the connector of today.

Naturally, the Sega Master System did not use the Universal Serial Bus to talk to its controllers, so some conversion was in order. That’s achieved with the use of a RP2040 microcontroller, which reads the D-pad and action buttons via its GPIO pins. It then acts as a HID device when plugged into a computer or other USB host, showing up as a simple game controller. This is a particularly easy hack as the Master System controller is so simple, there’s no need to decipher any protocols or anything like that. It’s just about wiring up a few simple buttons. Beyond that, it’s just a matter of hot-gluing the RP2040 into the Master System controller housing, and making some room for the USB C port to sneak out the top. We’d have loved to seen a little extra hackery on this one, perhaps adding some rumble to a controller that was never, ever supposed to have it.

If you want to adapt authentic old controllers to work with modern computers and emulators, this project is a great place to start. It doesn’t get much simpler than the Master System, after all. You can always work your way up to more advanced feats later, like working with the beloved Wavebird. Video after the break.

Continue reading “Sega Master System Controllers, Now With USB C”

Building An IBM PCjr BIOS From Source Using Original Printed Source Code

As unloved as IBM’s PCjr was, with only a one-year production run, it’s hard to complain about the documentation available for it. This includes the x86 assembly listing for the BIOS, which [dbalsom] recently used this print version to create an ASM project that can be built into a byte-identical copy of the PCjr BIOS.

In order to build the BIOS image, a ZIP file has been made available that contains the requisite assembler and linker tools, all of which can be run in DOS (or DOSBox) using the provided build.bat file. This creates an executable file, which can then be converted into a BIN file using the provided exe2bin.py Python script, or of course, manually.

Continue reading “Building An IBM PCjr BIOS From Source Using Original Printed Source Code”

Rescuing The Data On A 1960s LGP-21 Computer’s Disk Memory

One of the nice things about magnetic storage is that as long as the magnetic layer remains intact, the data it contains should stay readable pretty much indefinitely. That raises the prospect of recovering data from really old computer systems featuring magnetic memory, such as the 63-year old LGP-21 that [David Lovett] of Usagi Electric is currently restoring. Its magnetic memory disk is nothing amazing by modern standards, but after initial testing it seems to spin up and read data just fine, raising the question of what was left on the drive when it was last used, meaning what was in memory at the time.

The read/write head side of the LGP-21's magnetic memory. (Credit: Usagi Electric, YouTube)
The read/write head side of the LGP-21’s magnetic memory. (Credit: Usagi Electric, YouTube)

Non-invasive data recovery here involves writing a program that will simply read the entire disk from beginning to end. Tracks 0 and 1 were found to be unreadable due to some kind of hardware issue, but track 2 could be backed up by looking at the output on the CRT, thus providing a track to use. Fascinatingly the LGP-21’s memory disks uses interleaved tracks to reduce the number of read/write heads as part of the overall cost-saving measures relative to the more expensive LGP-30. As you might expect, this slows down memory access a lot over its big brother.

Before any recovery attempt could begin, the Flexowriter typewriter that forms the user interface to the computer had to be given some serious maintenance, along with a few other components like a switch and the paper tape reader. This restored the ability to even properly enter data and receive output instructions.

The subsequent effort to recover the stored data involved a bootstrap program that got loaded into memory, after which the remainder of the program was loaded from paper tape. Following this everything worked swimmingly, though with the caveat that with not even a floppy drive to use, the raw hexadecimal data was hammered out on paper with the Flexowriter over the course of 1.5 hours.

This data will now be scanned in and OCR-ed into something that can hopefully be easily analyzed. Hopefully we’ll know before long what this system was last used for.

Continue reading “Rescuing The Data On A 1960s LGP-21 Computer’s Disk Memory”

Itanium: The Great X86 Replacement That Never Was

Itanium was once meant to be the next step in computing, to compete with the likes of IBM, Sun and DEC, but also for Intel to have an architecture that couldn’t be taken from it, as the PC was from IBM by its clones. Today, however, Itanium is a relic of the past. [Asianometry] tells us the story of Itanium.

By the ’90s, servers were an established market dominated by RISC architectures and Unix-like operating systems. Intel wanted to compete in this market, due in part to worries of losing control over x86. So, when Hewlett Packard came to Intel in late ’93, Intel eventually agreed to collaborate on a new project in EPIC (Explicitly Parallel Instruction Computing).
Continue reading “Itanium: The Great X86 Replacement That Never Was”

SuperDisk: The Better Floppy That Never Caught On

Once the microcomputer era got going in earnest, the floppy disk quickly supplanted the tape as the portable storage method of choice. They were never particularly large, but they were fine for the average user to get by.

At the same time, it wasn’t long before heavier-duty removable storage solutions hit the market for power users who needed to move many megabytes at a time. In the 1980s, these were primarily the preserve of big print shops, corporate users, and governments. By the 1990s, even the mildly savvy computerist was starting to chafe against the tyrannical 1.44 MB limit of the regular 3.5″ diskette. Against this backdrop launched the SuperDisk—the product which hoped to take the floppy format to the next level, yet faltered all the same.

Continue reading “SuperDisk: The Better Floppy That Never Caught On”

Why Some S3 Videocards Have A Brightness Issue

Once a pioneer in videocards, S3’s legacy is today mostly found in details like texture compression as well as the strong presence of S3-branded videocards in the retro-computing world. There’s however a bit of a funny issue with some of these S3 cards in what is often called a ‘brightness bug’, but which as [Bits und Bolts] covers in a recent video was actually a hardware feature that we can once again blame composite video for.

This issue appears with AGP cards like the Trio 3D, Trio64 and ViRGE, where the brightness on the output signal is set too high, easily seen with the washed out look on boot, where especially on CRTs you’d expect to see the nice deep black background. Using an S3 Trio 3D 2X card that was saved from the e-waste pile this so-called Pedestal Bit responsible is investigated and tweaked to show what difference it makes.

At the core is adjusting the black level to make scanline changes easier to detect for TVs, which is no longer relevant for CRTs, LCDs, etc., while adjusting the brightness for one videocard in a system can cause issues elsewhere, such as when using said card alongside a 3dfx Voodoo II card or with inconsistent brightness levels inside 3D games.

Fortunately S3 provided in-depth datasheets on their chips, including how to address the responsible bit. After demonstrating the principle, the BIOS is then patched to set this Pedestal Bit to the value of 0 on boot, solving the issue once and for all.

Continue reading “Why Some S3 Videocards Have A Brightness Issue”

Vintage Chyron TV Hardware? Of Course It Runs NetBSD

Perhaps at this point, getting NetBSD running on an obscure piece of hardware is a dog-bites-man story, and not worth reporting– their motto, after all, is “Of course it runs NetBSD”. So, the fact that [RetroComputingRanch] has got NetBSD running on a vintage Chyron Maxine broadcast computer is perhaps remarkable only for the fact that few people have even heard of Chyron before.

He’s already done a series of videos in which they explore this odd, old computer, which is powered by a Motorola 68040 on a VME bus and was once used to generate digital overlays– text and the like– on broadcast TV. NetBSD does have a port for the Motorolla VME SBCs, so he was able to vibe it onto the specific vme168 board that the Chyron is based on. It happens off screen, but apparently it was AI agent work that went into condensing the documentation for this machine as well as getting the NetBSD port set up. That’s a bit ironic, since NetBSD would never allow that in its commits. 

Again, the Chyron Maxine was never intended to be a general-purpose-computer, and certainly never intended to run UNIX– it was meant to overlay text onto TV signals. With 4 MB of RAM, NetBSD leaves very little free once booted in single-user mode, but he realized that with a few extra chips the proprietary RAM board could become an 8 MB module. It seems like a pittance nowadays, but anyone who’s played with classic UNIX knows you can do a lot in 8 MB– even if only about 3MB is ‘free’ according to TOP.

There’s work still to be done– right now, it boots, but he wants to use NetBSD to really own this machine, so that’ll mean getting the vintage video hardware set up. Last time we saw a NetBSD user, they were doing game dev on a G4 Macbook, but nothing will ever match the legendary NetBSD toaster– not even toaster-shaped callbacks.

Continue reading “Vintage Chyron TV Hardware? Of Course It Runs NetBSD”