Retrocomputing

1523 Articles

Image

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

March 28, 2026 by 4 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.

Image
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” →

Image

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” →

Image

Reconstructed SC62015 Opcode Reference For Sharp Pocket Computers

March 26, 2026 by 3 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.

Image

Retail Fail: The :CueCat Disaster

March 25, 2026 by 63 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” →

Image

You Can Now Run MS-DOS Applications On The Apple IIe

March 25, 2026 by 20 Comments

After a lot of debugging, [Seth Kushniryk] has managed to get the last issuess shaken out of his port of MS-DOS 2.0 to the Apple II, and has released the project to the public. If you have the requisite AD8088 or similar co-processor expansion card with onboard x86 CPU, this should be all you need to get started.

Although this co-processor card contains effectively a self-contained x86 system, its only I/O goes via the expansion bus, so it has to play nice with the 6502 CPU of the Apple II system. When we last reported on [Seth]’s efforts he had just managed to get MS-DOS 2.0 booting and basically in a barebones working state.

Since then he’s been working on the bridge program that provides communication between the 8088 on the card and the Apple II’s 6502, relocating it in RAM to enable high-resolution graphics, as well as other tweaks and optimizations. Also a lot of bug hunting, including an undocumented ProDOS constraint with a request count.

With all of this done it’s now possible to run basically any MS-DOS 2.0 compatible software, assuming it doesn’t try to write directly to video memory. This does limit the software selection somewhat, but back in the day it would probably have been amazing to have that 8 MHz 8088 purring along the 6502 to run both Apple and DOS software titles. Props to [Seth] for restoring this software functionality that had been lost to the ages.

Continue reading “You Can Now Run MS-DOS Applications On The Apple IIe” →

Image

PicoZ80 Is A Drop-in Replacement For Everyone’s Favorite Zilog CPU

March 23, 2026 by 25 Comments

The Z80 has been gone a couple of years now, but it’s very much not forgotten. Still, the day when new-old-stock and salvaged DIP-40 packaged Z80s will be hard to come by is slowly approaching, and [eaw] is going to be ready with the picoZ80 project.

You can probably guess where this is going: an RP2350B on a DIP-40 sized PCB can easily sit on the bus and emulate a Z80. It can do so with only one core, without breaking a sweat. That left [eaw] a second core to play with, allowing the picoZ80 to act as a heck of an accelerator, memory expander, USB host, disk emulator– you name it. He even tossed in an ESP32 co-processor to act as a WiFi, Bluetooth, and SD-card controller to use as a virtual, wirelessly accessible disk drive.

The onboard ram that comes with an RP2350B would be generous by 1980s standards, but [eaw] bumped that up with an 8 MB SPRAM chip–accessed in 64 pages of 64 kB each, naturally. If more RAM than a very pricey hard drive wasn’t luxury enough, there’s also 16 MB of flash memory available. That’s configured to store ROM images that are transferred to the RAM at boot– the virtual Z80 isn’t grabbing from the flash at runtime in [eaw]’s architecture, because apparently there are limits to how much he wants to boost his retro machines. Continue reading “PicoZ80 Is A Drop-in Replacement For Everyone’s Favorite Zilog CPU” →

Image

The Zero-Power Flight Computer

March 23, 2026 by 27 Comments

In the early days of aviation, pilots or their navigators used a plethora of tools to solve common navigation and piloting problems. There was definitely a need for some kind of computing aid that could replace slide rules, tables, and tedious dead-reckoning computations. This would become even more important during World War II, when there was a massive push to quickly train young men to be pilots.

Image
The same, but different. A Pickett slide rule (top) and an E6B slide rule (bottom). (Own Work).

Today, we’d whip up some sort of computer device, but in the 1930s, computers weren’t anything you’d cram on a plane, even if they’d had any. For example, the Mark 1 Fire Control Computer during WW2 was 3,000 pounds of gears and motors.

The computer is made to answer flight questions like “how many pounds of fuel do I need for another hour of flying time?” or “How do I adjust my course if I have a particular crosswind?”

History

There were a rash of flight computers starting in the 1920s that were essentially specialized slide rules. The most popular one appeared in the late 1930s. Philip Dalton’s circular slide rule was cheap to produce and easy to use. As you’ll see, it is more than just an ordinary slide rule. Keep in mind, these were not computers in the sense we think of today. They were simple slide rules that easily did specialized math useful to pilots.

Dalton actually developed a number of computers. The popular Model B appeared in 1933, and there were refinements leading to additional models. The Mark VII was very popular. Even Fred Noonan, Amelia Earhart’s navigator, used a Mark VII. Continue reading “The Zero-Power Flight Computer” →