You may not know what a ADM-3, a TV910, or a H1420 are, but you probably have at least heard of a VT-100. They are all terminals from around the same time, but the DEC VT-100 is the terminal that practically everything today at least somewhat emulates. Even though a real VT-100 is rare, since it defined what have become ANSI escape sequences, most computers you’ve used in the last few decades speak some variation of the VT-100’s language. [Nikhil] wanted to see if you could use a VT-100 for real work today.
While the VT-100 wasn’t a general-purpose computer, it did have an 8080 inside. It only had about 3K of RAM, which was enough to act as a serial terminal. A USB serial port and a terminal with modern Linux, how hard could it be?
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.
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.
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)
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.
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”→
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.
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.
