Retrocomputing

1533 Articles

The ikea desk, with the spectrometer on the far left.

PDP-11 Lives In Literal Computer Desk Once More

March 30, 2026 by 5 Comments

When you think of iconic parings, your brain probably goes more to “cookies and milk” than “DEC and Ikea” but after watching [Dave]’s latest on Usagi Electric where he puts a PDP-11 into an Ikea desk, you may rethink that.

The PDP-11 is vintage hardware that actually lived inside of a different desk, once upon a time, serving as the control unit for an FTIR spectrometer. While the lab equipment has thankfully survived the decades, the desk did not and when [Dave] got the unit it was as a pile of parts. He revived it, of course– it’s kind of what he does– but it didn’t get a new desk for years, until his latest shop re-organization.

The one concession to modernity– and missing parts– is using switching power supplies rather than the bulky linear PSU that would have originally powered the unit. It’s a good thing, too, or we have trouble picturing how everything would fit! This particular PDP-11 comes with the high performance vector processing unit in order to crunch those spectrographs, and apparently those chips idle at about 60C, so the desk-case got some decent-sized 120V fans to keep everything cool and running for years to come.

This isn’t the most aesthetic or fanciest case-mod we’ve seen, mostly being made of surplus plywood and scrap metal fittings, but it certainly gets the job done. Given that the PDP-11 has been crammed into every form-factor known to man, from a system-on-a-chip (before anybody really talked about SOCs) to desktop workstations, and of course the hulking cabinets with their iconic blinkenlights-– it’s hard to say that this installation isn’t reasonably authentic, even if it isn’t the original desk.

Continue reading “PDP-11 Lives In Literal Computer Desk Once More” →

Recreating One Of The First Hackintoshes

March 30, 2026 by 22 Comments

Apple’s Intel era was a boon for many, especially for software developers who were able to bring their software to the platform much more easily than in the PowerPC era. Macs at the time were even able to run Windows fairly easily, which was unheard of. A niche benefit to few was that it made it much easier to build Hackintosh-style computers, which were built from hardware not explicitly sanctioned by Apple but could be tricked into running OSX nonetheless. Although the Hackintosh scene exploded during this era, it actually goes back much farther and [This Does Not Compute] has put together one of the earliest examples going all the way back to the 1980s.

The build began with a Macintosh SE which had the original motherboard swapped out for one with a CPU accelerator card installed. This left the original motherboard free, and rather than accumulate spare parts [This Does Not Compute] decided to use it to investigate the Hackintosh scene of the late 80s. There were a few publications put out at the time that documented how to get this done, so following those as guides he got to work. The only original Apple part needed for this era was a motherboard, which at the time could be found used for a bargain price. The rest of the parts could be made from PC components, which can also be found for lower prices than most Mac hardware. The cases at the time would be literally hacked together as well, but in the end a working Mac would come out of the process at a very reasonable cost.

[This Does Not Compute]’s case isn’t scrounged from 80s parts bins, though. He’s using a special beige filament to print a case with the appropriate color aesthetic for a computer of this era. There are also some modern parts that make this style computer a little easier to use in today’s world like a card that lets the Mac output a VGA signal, an SD card reader, and a much less clunky power supply than the original would have had. He’s using an original floppy disk drive though, so not everything needs to be modernized. But, with these classic Macintosh computers, modernization can go to whatever extreme suits your needs.

Thanks to [Stephen] for the tip!

Continue reading “Recreating One Of The First Hackintoshes” →

Writing An Open-World Engine For The Nintendo 64

March 29, 2026 by 7 Comments

Anyone who has ever played Nintendo 64 games is probably familiar with the ways that large worlds in these games got split up, with many loading zones. Another noticeable aspect is that of the limited drawing distance, which is why even a large open area such as in Ocarina of Time‘s Hyrule Field has many features that limit how far you can actually see, such as hills and a big farming homestead in the center. Yet as [James Lambert] demonstrates in a recent video, it’s actually possible to create an open world on the N64, including large drawing distances.

As explained in the video, the drawing distance is something that the developer controls, and thus may want to restrict to hit certain performance goals. In effect he developer sets where the far clipping plane is set, beyond which items are no longer rendered. Of course, there are issues with just ramping up the distance to the far clipping plane, as the N64 only has a 15-bit Z-buffer, after which you get ‘Z fighting’, where render order becomes an issue as it’s no longer clear what is in front of what.

One fix is to push the near clipping plane further away from the player, but this comes with its own share of issues. Ergo [James] fixed it by doing two render passes: first all the far-away objects with Z-buffer disabled, and then all the nearby objects. These far-away objects can be rendered back-to-front with low level-of-detail (LoD), so this is relatively fast and also saves a lot of RAM, as the N64 is scraping by in this department at the best of times.

In the video the full details of this rendering approach, as well as a new fog rendering method, are explained, with the code and such available on GitHub for those who wish to tinker with it themselves. [James] and friends intend to develop a full game using this engine as well, so that’s definitely something to look forward to.

Continue reading “Writing An Open-World Engine For The Nintendo 64” →

Play A .WAV Instead Of Typing Line After Line Into Vintage Microcomputer

March 28, 2026 by 26 Comments

[Casey Bralla] got his hands on a Rockwell AIM 65 microcomputer, a fantastic example of vintage computing from the late 70s. It sports a full QWERTY keyboard, and a twenty character wide display complemented by a small thermal printer. The keyboard is remarkably comfortable, but doing software development on a one-line, twenty-character display is just not anyone’s idea of a good time. [Casey] made his own tools to let him write programs on his main PC, and transfer them easily to the AIM 65 instead.

A one-line, twenty-character wide display was a fantastic feature, but certainly lacking for development work.

Moving data wasn’t as straightforward in 1978 as it is today. While the Rockwell AIM 65 is a great machine, it has no disk drive and no filesystem. Programs can be written in assembler or BASIC (which had ROM support) but getting them into running memory where they could execute is not as simple as it is on modern machines. One can type a program in by hand, but no one wants to do that twice.

Fortunately the AIM 65 had a tape interface (two, actually) and could read and store data in an audio-encoded format. Rather than typing a program by hand, one could play an audio tape instead.

This is the angle [Casey]’s tools take, in the form of two Python programs: one for encoding into audio, and one for decoding. He can write a program on his main desktop, and encode it into a .wav file. To load the program, he sets up the AIM 65 then hits play on that same .wav file, sending the audio to the AIM 65 and essentially automating the process of typing it in. We’ve seen people emulate vintage tape drive hardware, but the approach of simply encoding text to and from .wav files is much more fitting in this case.

The audio encoding format Rockwell used for the AIM is very well-documented but no tools existed that [Casey] could find, so he made his own with the help of Anthropic’s Claude AI. The results were great, as Claude was able to read the documentation and, with [Casey]’s direction, generate working encoding and decoding tools that implemented the spec perfectly. It went so swimmingly he even went on to also make a two-pass assembler and source code formatter for the AIM, as well. With them, development is far friendlier.

Watch a demonstration in the video [Casey] made (embedded under the page break) that shows the encoded data being transferred at a screaming 300 baud, before being run on the AIM 65.

Continue reading “Play A .WAV Instead Of Typing Line After Line Into Vintage Microcomputer” →

SEGA Music To MODfile, (Semi)Automatically

March 27, 2026 by 7 Comments

One thing SEGA’s MegaDrive/Genesis and the Commodore Amiga had in common was–aside from the Motorola 68000 processor– being known for excellent music in games. As [reassembler] continues his quest to de-assemble Sonic: The Hedgehog and re-assemble the code to run on Amiga, getting the music right is a key challenge. Rather than pull MIDI info or recreate the sound by ear, [reassembler] has written a program called Sonic2MOD to automatically take the assembly file music from the MegaDrive cartridge and turn it into an Amiga-style MODfile. He’s also made a video about it that you’ll find embedded below.

Of course how music gets made differs widly on the two systems. Amiga, famously has Paula, a custom ASIC designed for sampling, allowing you to play four eight-bit voices. The Sega, of course, has that glorious FM-synthesis chip from Yamaha synthesizing five channels of CD-quality sound and one channel of sample. It’s not as well known, but the Sega also has a bonus TI-compatible programmable sound chip (PSG) that can handle 3 square-wave tone channels and one noise channel. That’s ten total channels to the Amiga’s four, and CD-quality to 8-bit voices. Knowing all that, we were very curious how close to SEGA’s original music [reassembler] could get on the Amiga.

Before he could show us, [reassembler] needed to decode the SMPS files used on Sonic: The Hedgehog and many other MegaDrive games. Presumably he could have gotten a MIDI file online somewhere– there are oodles– but the goal was to reverse engineer Sonic from its cartridge for the Amiga, not download a lot of resources from the web. SMPS is a sort of programing language for sound, telling the Yamaha and PSG chips what to do.

In some ways, it’s not unlike the Amiga’s MOD format, which programmatically specifies how to play the sampled voices also stored in the file. Translating from one to another is a matter of reading the SMPS files, extracting the timing, volume, vibrato, et cetera, and translate that into a form the MOD file can use. Then [reassembler] needed to generate samples, which was an added hiccup because the Amiga can only handle 3 octaves vs the seven of the SEGA’s FM synthesizer. He’s able to solve this simply by generating multiple samples to span the Yamaha chip’s range, though, again, at only 8-bit fidelity. It doesn’t sound half bad.

What about the four-channel limit? That’s where a bit of artistry comes in; the automated tool produces MOD files with more voices, which MOD trackers can handle at increased computational load. Computational load you don’t need when trying to play a game. Scaling down the soundtrack to the Amiga’s limits is something [reassembler] already has practice with from his famous OutRun port, though, so we’re sure he’ll get it done.

All of this effort just to match the Mega Drive makes us appreciate what a capable little computer the Sega console was; why, you can even check your stocks with it! We’ve already featured [reassembler]’s Sonic port once before, but this music tool was interesting enough we couldn’t help ourselves coming back to it. The ability to play MOD files were pretty impressive when the Amiga came out, but nowadays all you need is a ten-cent microcontroller.

Continue reading “SEGA Music To MODfile, (Semi)Automatically” →

Reconstructed SC62015 Opcode Reference For Sharp Pocket Computers

March 26, 2026 by 4 Comments

Pocket computers like Sharp’s 8-bit computing marvels were a big part of the 1980s, providing super-portable processing power to anyone who wanted a bit more than what something like a scientific calculator could provide at the time. These days they are mostly just a collector’s item for retrocomputing enthusiasts, which also means that a lot of the knowledge about how to program the CPUs in them is at risk of being lost.

This is why [gikonekos] decided to combine as much knowledge they can glean from official documentation into a reference project on GitHub for the SC62015 equipped Sharp pocket computers like the PC-E550.

Generally you’d program in Sharp’s dialect of BASIC on these computers, such as the ‘PLAY3’ program that [gikonekos] recently unearthed from a November 1993 copy of ‘Pocket Computer Journal’ using which you can create polyphonic tunes. This only unlocks a small part of what the hardware can do, of course, so having a full opcode reference like this is important.

While still a work in progress, it’ll eventually contain the full opcode and register tables, addressing modes, instruction summaries and of course a full accounting of how all of this was reconstructed. As the original Sharp documentation wasn’t released to the public, providing these scans is also not a goal, especially not under any kind of free license.

A cursory search reveals an instruction table for the PC-E500 from 1995 by [Andrew Woods], so documenting this is not a new thing, although at the time these Sharp pocket PCs didn’t count as ‘retro systems’ yet.

Retail Fail: The :CueCat Disaster

March 25, 2026 by 71 Comments

Digital Convergence Corporation is hardly a household name, and there’s a good reason for that. However, it raised about $185 million in investments around the year 2000 from companies such as Coca-Cola, Radio Shack, GE, E. W. Scripps, and the media giant Belo Corporation. So what did all these companies want, and why didn’t it catch on? If you are old enough, you might remember the :CueCat, but you probably thought it was Radio Shack’s disaster. They were simply investors.

The Big Idea

The :CueCat was a barcode scanner that, usually, plugged into a PC’s keyboard port (in those days, that was normally a PS/2 port). A special cable, often called a wedge, was like a Y-cable, allowing you to use your keyboard and the scanner on the same port. The scanner looked like a cat, of course.

However, the :CueCat was not just a generic barcode scanner. It was made to only scan “cues” which were to appear in catalogs, newspapers, and other publications. The idea was that you’d see something in an ad or a catalog, rush to your computer to scan the barcode, and be transported to the retailer’s website to learn more and complete the purchase.

The software could also listen using your sound card for special audio codes that would play on radio or TV commercials and then automatically pop up the associated webpage. So, a piece of software that was reading your keyboard, listening to your room audio at all times, and could inject keystrokes into your computer. What could go wrong?

Continue reading “Retail Fail: The :CueCat Disaster” →