Sometimes an offhand comment can start you down the path of making something you hadn’t thought possible. For me, it was a lamentation by the DJ and coder Hoffman on Twitch about the Gravis Ultrasound, an old PC sound card with a cult following that’s now eye-wateringly expensive. In that moment, a half-remembered old social media post by hardware hacker Foone Turing entered my mind: that it’d be cool to interface a retro PC’s bus with a Raspberry Pi’s GPIO pins. Huh, I thought: what if you could use a Raspberry Pi to emulate the Gravis Ultrasound in a PC? There’s lots of open-source code for that card out there in PC emulators like DOSBox already, so it might actually be possible! I believe that the retrocomputing hobby needs to be more accessible to people and high prices on interesting cards keep them out, so I felt like something needed to be done about it. I hadn’t made anything nearly as complex before, but the seeds were planted long before that moment.
History
A computer’s ability to make music and sound has always been the most interesting thing to me. When I was a kid in the early ‘90s, I realized the capabilities that a sound card could bring to our family PC, and knew we had to get one. Once I finally convinced my parents to get a Sound Blaster, I learned it wasn’t just about its ability to add sound effects and music to games. On the disks that came with the card was a demo of a program called Tetra Compositor. It played music that was far more advanced-sounding than anything else I heard from the Sound Blaster: a full length song with “real” sounds, and the file was only 40 kilobytes. I knew I had to find more of these files, so I dialed into every BBS in the area on a hunt for them and eventually I landed on what they were: MOD files, also known as tracker music. I had just found my new favorite thing. I downloaded as many songs as I could find, as well as a more general-purpose player: MODPlay by Mark J. Cox. For a kid like me with an insatiable appetite for music but too young to have a job, these MOD files were gold. In the days before MP3s, having a source of practically unlimited new music completely for free was incredible.
Included with MODPlay were instructions for how to build your own sound card that connects to the computer’s parallel printer port. The schematics were pretty simple: just a few resistors and a capacitor. I had played a little bit with wiring up lights, switches, and buzzers with parts from Radio Shack, so it seemed like a doable project. Even though the family PC had a Sound Blaster already, the idea of making my own device that could make “real” music sounded like a ton of fun. After visiting multiple electronics stores in my city, I finally found the 1% tolerance resistors that the instructions said worked best, and I wired it up in a Radio Shack project box. Incredibly, it worked, and it actually sounded good! While I never made anything else as complicated on my own, that experience taught me that it was possible to make something myself with basic electronic components that could make more than just beeps and boops.
Later, as I entered my teens, the internet became more accessible, and I got online as soon as I could. Once I had access to the internet, I got more and more into tracker music as well as the hacker-mindset community that spawned it: the Demoscene. The Demoscene got its start in the 80s when software crackers wanted to show off their skills by putting short intros that would play before starting the software that they cracked the copy protection on, and eventually those intros became standalone demos with envelope-pushing visuals and ever-more sophisticated music. The music was always the most interesting thing about those demos to me, and on the Commodore Amiga and PC, they were MOD files composed in music tracker programs.
I started writing my own MOD files and eventually I caught onto the fact that a simple Sound Blaster card wasn’t going to cut it if I wanted the best quality music playback and the ability to watch the coolest demos. I’d need a Gravis Ultrasound, also known as the GUS. I asked my parents for one for Christmas, and while I’m really not sure how I sold them on the idea, amazingly, I actually got one! The hype was warranted: it sounded so much better than my old Sound Blaster or homemade sound card, and it also meant the anemic family PC could keep up with the ever-more complex tracker formats that kept coming out. Having the GUS caused me to get even deeper into the tracker music scene, and I kept writing more and more of my own bad music. The friends I made in that community back then I still have today. Even after I moved on from using those old PCs, I never could bring myself to get rid of my GUS. Maybe somehow, I knew it’d remain iconic.
Rediscovering Retro
In 2021, I stumbled upon my GUS card in a box of old stuff. Right then, in that moment, I got a feeling that I had to hear that card make music again. I got to work putting a retro system together, and when the moment came to use the GUS…the system froze solid while trying to initialize it. I couldn’t let go, so I started throwing parts at the problem: new capacitors, a new GAL chip for the bus logic, and finally, a replacement for the GUS’s main chip: the GF1. I had to get the chip from a broker in China, and after a bit of a wait for the chip to arrive, once installed, the card fired back to life, and again made beautiful music. The GF1 chip almost certainly came from an e-wasted Gravis Ultrasound, and while it broke my heart a bit, at least it went to getting another card working again.
Once I had my system working, I started getting into the retro scene on social media, YouTube, and Twitch. That’s when I began watching streams like the one with Hoffman where I first got the inspiration to work on emulating the GUS. I kept on hearing more and more people say they wish they had a GUS, so that increased my resolve to open up the experience of having one.
Diving in on Re-Making the GUS
At this point, I really didn’t know what I was doing. I’d dabbled in electronics and designed a PCB with a friend, but I decided to just dive in. Prices on prototype PCBs have fallen like crazy, thanks to things like OSH Park and companies in China like JLCPCB and PCBWay, so there wasn’t much risk in just making a PCB and seeing how it worked out. I already had a couple of Raspberry Pi boards hanging around, so that helped. Early DOS PCs took expansion cards based on the Industry Standard Architecture (ISA) bus, and it’s pretty well documented. After I determined the signals that I thought I needed, I dove in on designing a prototype PCB. I called my first version “very dumb prototype” and immortalized that in the board’s silkscreen printing, along with the name “PiGUS”.
Of course, this being my first board, I made a lot of mistakes. The connector for the Raspberry Pi was rotated, meaning the Pi couldn’t physically plug into the board, because it was too large, so I had to connect it with a ribbon cable. Later, I realized I missed adding a critical signal to the board, and accidentally grounded another one, so it could never fully emulate a Gravis Ultrasound, but fortunately there was nothing to prevent basic emulation. When I finally plugged the board in, nothing exploded, so I was good to proceed on trying to get sound out of it.
Extremely Motivating Early Success
I found another open-source project that connects a Pi to the ISA bus in a simpler way: eigenco’s RPiISA. That project had successfully implemented AdLib sound card emulation. The AdLib was probably the first truly successful sound card for PCs, and it uses Yamaha’s OPL2 FM synthesis chip. While accurately emulating its sound is a challenge, interfacing with it over ISA is very simple. I still wasn’t quite confident that the Pi could respond to reads on the ISA bus fast enough, but discussions with Claude Schwarz, the creator of the PiStorm project that replaces the CPU in a Commodore Amiga with a Raspberry Pi, gave me the confidence that it could be. I adapted the AdLib code from the RPiISA project to my board and pretty quickly got AdLib sound from my prototype! Having an open source example to follow, and reassurance from people who had done similar projects, sped up my progress greatly.
With AdLib sound working, it was finally time to try GUS emulation. There are a few ways that the GUS can be programmed, and quite a few music players use the simplest way that doesn’t need any tricky timing-sensitive DMA (direct memory access) sample uploading or interrupt-driven playback. This means that the barrier to getting actual sound out can be pretty low! I started picking apart the GUS emulation code from the DOSBox Staging project, and in the course of about a week, I finally experienced that glorious moment: real, actual music playing from the prototype that I made! The song I chose was one of my favorites from back in the 90s: Satellite One by Purple Motion. It’s still the first song that I use to test new cards or new playback routines, since I’m so familiar with how it should sound.
Moving to the Pico due to Raspberry Pi Shortage
I shared my results on social media and the Vogons forum. Vogons is a forum full of retro DOS enthusiasts, so I thought they’d be interested. People liked the project! Pretty early on in the thread, a short comment by the user rasz_pl set me off in yet another direction: using the Raspbery Pi Pico. He mentioned that a Pico, paired with an external serial PSRAM chip, could possibly emulate any sound card. Hearing this completely upended my project in a good way: at this point of time in the middle of 2022, we were in the depths of the semiconductor component shortage, and Raspberry Pi single-board computers were extremely hard to come by. The Pi Pico, however, was plentiful, and cost just $4 in the US. The Pico’s RP2040 microcontroller also has PIO, an extremely fast and powerful method for interfacing with external devices. So I had to at least try to see if the Pico could interface with the ISA bus.
Using an unpopulated copy of one of my original prototype boards, I broke the connections out from the Raspberry Pi connector to a mess of a breadboard filled with a Pi Pico, multiplexer chips, and an external DAC for audio output. It took me a while to get used to the Pico SDK, but after a lot of work, I finally had the RP2040’s PIO reading and writing data on the ISA bus. Getting AdLib working was the next logical step, but I ran into an issue: most OPL2 emulation code out there runs too slowly on the RP2040, which lacks the ability to do floating point math. Again, I was saved by open source, as I remembered an amazing feat that had been pulled off on the Pico: running Doom, the classic, graphically-impressive 1993 DOS game. Graham Sanderson, the author of that project, performed incredible optimizations to get the game to run on the Pico, complete with sound and VGA output. As a part of getting sound to work, he massively sped up the code of an OPL2 emulator, and fortunately I was able to get his optimized version to run on its own. That code ran with no issues on the Pico when combined with my bus interfacing code, and amazingly, I had AdLib sound playing on a Raspberry Pi Pico!
Encouraged by this success, I designed the first PicoGUS PCB in a hurry. That hurry meant I made a lot of mistakes, and getting my AdLib code working was a major challenge. A couple of signal lines were swapped, so I was getting nonsensical data, and it took some precision “bodge” work to swap those lines around on the board, using fine magnet wire and lifting individual pins on the small surface-mount chips.
Next was GUS, and while I was able to get the same DOSBox Staging emulator to start to make GUS music pretty quickly, I ran into two stumbling blocks: first, the emulator was too slow to play more than 8 voices at one time – far from the GUS’s 32; and second, the RP2040 only has 264 kilobytes of RAM, while the GUS needs one full megabyte for the samples alone. The DOSBox Staging emulator has quite a bit of floating-point math, but fortunately I found the GUS code in the related DOSBox-X emulator didn’t. And as a bonus, that emulator is well-tested with Demoscene productions. After more hacking, the DOSBox-X emulator was in, and performing great with lots of voices, so I had to solve the next issue: the sample RAM.
In the original comment on Vogons that made me consider the RP2040 in the first place, rasz_pl suggested a specific serial SPI PSRAM chip, and I included it on my board for the GUS sample RAM. Using that chip at the speed the GUS demands was a major challenge, though. It took some very close reading of the chip’s datasheet and writing of a custom PIO program to speak SPI slightly differently from the RP2040’s built-in SPI interface. Getting the PSRAM to work reliably and fast enough took about a month.
Challenges
As I had to implement more and more of the ISA bus, I started running into problems with the subtleties of how it operates, and the assumptions made by programs that operate on actual period hardware. Due to the limitation of emulating hardware within firmware running on the RP2040, timing can be slower than on real hardware, and several DOS programs cheat a bit. To give one example, some programs assume that multiple interrupt events can’t overlap with each other, which took a lot of capturing of bus events with a logic analyzer to determine. Sometimes this can be worked around in the firmware, but sometimes the only solution is to just be faster, so that the PicoGUS works more like the original hardware.
The ISA bus’s history as an ad-hoc standard with many implementations meant that many systems work differently in very subtle ways. The biggest hurdle was with direct memory access, better known as DMA. This allows audio samples to be uploaded to the GUS card directly from system memory with no involvement from the computer’s CPU, and many games use it for streaming audio such as sound effects. I got a bare-bones implementation of DMA working based on the historical specification documents I could find, but I kept getting noisy-sounding audio while reading data when the DMA acknowledge signal was asserted. I was following the spec, but that was producing garbage or data that was off by a bit. Once again, I had to return to the logic analyzer to see the truth of what was happening on the bus. This revealed that almost every single timing diagram that I could find for DMA wasn’t telling the whole truth: in fact, the data on the data pins wasn’t ready until much further on in the DMA process. Fortunately, there was another signal I could trigger data reads on in order to give reliable data reads. I later ran into a similar issue on older computers like the original IBM PC/AT where even basic data IO operations would fail because the data wasn’t ready when the IO write signal triggered.
while correcting the bodgy bits of v1.0 (left). Photo by Ian Scott.
Democratizing Access to Hard-to-Find Technology
The PicoGUS hardware design meant that it could support just about any kind of sound card. There are many other rare sound cards for retro PCs out there, and PicoGUS has the potential to emulate a lot of them. In an early hardware revision, I added a MIDI port to drive an external synthesizer module. Many DOS games had amazing MIDI soundtracks composed for Roland MIDI modules like the MT-32 and SC-55, and the earliest ones required a genuine Roland MPU-401 MIDI interface with “intelligent mode.” As per usual, original units sell for big money, and while there are clones or hardware emulators out there, they’re not cheap. PicoGUS could easily emulate an MPU-401 with intelligent mode by using open-source code, so I was able to add that. I also had the original AdLib sound card support from my first experiments, so the PicoGUS was starting to become an emulator for multiple cards. Supporting several other early PC sound standards like the Creative Music System and the 3-voice audio on the IBM PCjr and Tandy 1000 was possible on the PicoGUS, so I added those as well. A generous contribution of code for the sound chips in those systems was made by emulator developer Aaron Giles.
PicoGUS’s original goal of bringing hard-to-find sound card support to the masses was expanding to more sound standards. As I finalized the public release of the PicoGUS hardware, I always kept in mind to use parts with high availability and low cost. I tried to avoid adding features that added additional cost unless they were really necessary. All of this was with the ultimate goal of creating a board that was relatively simple to make, with a low cost of materials, that was easy to use.
Creating a Community
As I continued making progress on the project, I kept posting about it on social media and forums. Just as I was inspired by others, I found several other people who had long wanted to emulate other kinds of retro computer add-ons who were inspired by the progress I had made with the Pico. For example, after seeing PicoGUS, Freddy Vetele created a card called PicoMEM that can emulate memory expansion cards, disk drives, network devices, and eventually even overlap some of the sound abilities of the PicoGUS. And on the portable computer front, Kevin Moonlight has created cards based on the Pico that easily add modern Wi-Fi support to old laptops with PCMCIA slots. It seems like every month there’s a new retro computer or gaming hardware device based on the Pico or RP2040, and it’s gratifying to know I’m a small part of this flourishing ecosystem. My project is open source and open hardware, and many of these projects are as well, allowing for cross-pollination of designs and interfacing techniques.
Throughout this time, PicoGUS remained a purely do-it-yourself project. I was happy to see people in the community producing cards and selling them and making new versions that were smaller or could plug into PC/104 embedded PC systems. I decided to exhibit PicoGUS and other Pico-based projects at the Vintage Computer Festival Midwest, held in the Chicago area in September 2023, so I made some cards to sell at the event. Once I started building these cards by hand, I came to the realization that I wanted to make a new version of the card that could be mass produced. This ended up as PicoGUS v2.0: an all-in-one card that could be 100% assembled by low-cost PCB assembly services.
At VCF Midwest, I ran into Adrian Black, who makes the Adrian’s Digital Basement YouTube channel. He was really blown away by PicoGUS, and when he made a video about the project, interest exploded. Luckily, not long after that video went out, PicoGUS v2.0 was ready. Getting to that point was tough: I ran into issues getting the parts I needed to JLCPCB, the PCB manufacturer I used, and there were also issues with some defective parts. But once I worked past those and put the boards up for sale on Tindie, they sold out in two and a half hours! Keeping up with the continuing demand and dealing with random issues people have had with computer chipsets I haven’t tested with has been a challenge. I also want to keep supporting the maker community that wants to make their own boards, so I “backported” a lot of the improvements from v2.0 to a DIY-friendly revision of my v1 board.
Conclusion
For a first major hardware maker project, this has been way more successful than I ever could have imagined. Being able to leverage the hard work people have put into open source accelerated my progress incredibly, and I’ve been excited to see what people have done with the work I’ve contributed back to the community. It’s been an incredibly gratifying experience seeing the flywheel of progress in the open retro hardware community. As for what’s next, there are plenty of other platforms that need similarly available and affordable hardware, and I have my eye on a couple. For example, the Sharp X68000, a computer sold only in Japan that has great audio/visual capabilities for its time has long had addons in short supply…
Grab your own PicoGUS on Tindie, or find out more on GitHub. A version of this article appeared in Make: Volume 89.
ADVERTISEMENT
