PicoGUS: emulating a Gravis Ultrasound on a Raspberry Pi Pico

An ISA bus device built on a microcontroller

PicoGUS is ISA sound card and CD-ROM drive emulation on the Raspberry Pi Pico's RP2040 microcontroller, and the list of what it emulates is the whole of the project.

The Gravis Ultrasound is the primary focus, which is where the name comes from. Then there is the family of Adlib and OPL cards: the Sound Blaster 16 with OPL3, the Sound Blaster Pro 2 with OPL3, and the original AdLib with OPL2. There is the MPU-401 in intelligent mode, which outputs MIDI data on a 3.5mm MIDI TRS connector. There is the Tandy three voice chip and the CMS, which is the Game Blaster. And there is a game port joystick.

The CD-ROM side is a Panasonic, or MKE, interface, which is the interface that the MS-DOS era CD-ROM drives used and that later drives kept for compatibility.

The device sits between a real DOS-era machine and the period software running on it. The PC sees an ISA card with a sound chip and a CD-ROM drive; the Pico does the emulation and the audio processing, and the repository description also mentions USB mouse and joystick support, which is how the game port joystick is wired to a modern system.

That is an unusual and quite elegant piece of hardware. It is also a niche one: the machine it plugs into has to have an ISA bus, which means a 1990s PC.

Why the Ultrasound is the focus

The README explains the concentration on the Gravis Ultrasound in one line, and it is a historical argument.

The project has a heavy demoscene focus because of the card's history, so that is what the author concentrated on, and the GUS support in games is described as very good to excellent.

That matters because the Ultrasound was never a mainstream consumer card in the way the Sound Blaster was. It was an expensive 16 bit sample card that a certain kind of scene and a certain kind of game loved, and because it had that reputation, the software that used it tends to be the demanding kind. A demoscene production that plays GUS samples is exactly the workload that would expose an emulation mistake.

So the project chose the hard target first. If the emulation is good enough for demoscene productions and for games with GUS support, the simpler cards follow, because an OPL2 or OPL3 emulation is a comparatively well understood problem.

The README is also direct about the limits of that approach. There are three reasons given for why some things will likely never be perfect: the specs of the Pico itself, the assumptions made by programs written to use the Ultrasound, and the imprecise nature of emulation in general, plus the varying specs of retro DOS PC hardware.

The status line is the same message in shorter form. Current status: perpetual beta, with the wiki holding the current status and a compatibility list for the support status of various DOS programs.

Buying one, or building one

There are two routes, and the README treats them differently.

The first is buying a fully assembled PicoGUS 2.0 card. Three sellers ship them worldwide: a shop in the United States, one in the European Union and one in the United Kingdom. The README also shows photographs of the 2.0 printed circuit board and of an earlier beta board, so you can see what you are buying.

The second is building your own, using the build guide in the wiki. And here the README is unusually forthcoming about a flaw: the more DIY friendly version 1.1.1 hardware has some documented issues with reset, and a forthcoming version 1.2 revision will fix them.

That reset detail is the kind of thing that decides whether a first build goes smoothly. A card whose reset line misbehaves will not be recognised reliably by a machine that expects a well behaved ISA device, and the fix is a hardware revision rather than a firmware change.

There is a third path for people who want the device but not the work, which is the configuring and using guide in the wiki, and a fourth for people who want to help, since the author has a limited number of machines to test the device in and asks for donations of money or motherboards to increase compatibility.

The funding routes are PayPal and Ko-fi, and the repository carries a funding configuration file at the root, which is the GitHub convention for pointing at them.

The credit list is the design history

The open source credits section is the most informative part of the README, because it says where each part of the emulation came from.

The base is the Raspberry Pi Pico C and C++ SDK, and the audio output uses the I2S audio library from the Pico extras project, while the asynchronous serial transport comes from another project, PicoCart64, which is a cartridge reader for the same hardware family.

The Ultrasound emulation itself is adapted from DOSBox-X, which is a long standing DOS emulator. The OPL and AdLib emulation comes from a Doom port for the RP2040, which in turn is based on the emu8950 project, so the FM synthesis core is a well known piece of work rather than something written for this board. The MPU-401 emulation is adapted from the HardMPU project and from DOSBox-X.

The Tandy three voice and the CMS emulations are both based on code contributed by Aaron Giles and adapted from DREAMM, which is the same lineage that MAME uses.

USB support uses TinyUSB with the XInput support library, with USB mass storage improvements from two named contributors, and FAT drive support comes from FatFS.

So the emulation quality of PicoGUS is a direct inheritance. When a card behaves oddly, the first question is usually which of those upstream implementations it came from and whether the difference is a Pico limitation or an upstream one.

Two licences for two kinds of work

The licensing is split, and the split follows the two kinds of contribution in the repository.

The hardware portions, the hw directory, are licensed under CERN OHL version 2, which the README describes as permissive. That is the licence used for open hardware designs, and it matters here because the board design is something other people are expected to build and, in the version 2.0 case, manufacture.

The software portions, the sw and pgusinit directories, are licensed as a collection under the GNU GPL version 2. And some individual files are individually dual licensed under BSD or MIT licences, with the details in the file headers.

That mixed arrangement is common in firmware projects that carry both a board design and an embedded program, and it has two practical consequences. If you build your own card, the CERN OHL terms apply to the design and you should read them before modifying it, particularly because the OHL has its own rules about how a derivative design is distributed. If you take the firmware and want to distribute it, the GPL terms apply to the collection as a whole, and the per file headers tell you which files carry the more permissive alternative.

The project as a whole is listed as GPL 2.0 in the repository metadata, which matches the software side but not the hardware side, and the distinction is worth keeping straight.

The repository layout and the state of the work

The top level of the repository shows that this is a hardware and firmware project rather than a pure code project.

There is the hw directory with the main hardware, and then hardware subdirectories for the shared parts and for two specific revisions, a chipdown directory and a common directory, plus a directory for an ISA adapter for the 386 machine variant. There is the sw directory for the firmware, the pgusinit directory for the initialisation code that runs on the emulated PC, and a common directory for code shared between them.

The pgusinit part deserves a note, because it explains an architectural constraint. The initialisation program runs on the host PC rather than on the Pico, and it is what patches the emulated card into the machine's configuration, so that DOS and its drivers see a real Ultrasound. That is the standard technique for ISA sound cards of that era, and it means the Pico alone is not sufficient: something has to run at boot to set the card up.

On maintenance, the release tags are v4.1.1 from 2026-05-17, v4.1.1-beta.1 from 2026-04-20 and v4.1.1-beta.0 from 2026-04-18, and the last push was on 2026-10-02. The beta tags immediately before the final one show the shape of the release process, with a beta published while the compatibility work continues and a stable release following a couple of months later.

The status claim remains perpetual beta, and the wiki compatibility list is the place where the real answer lives for any given piece of software.

Editorial conclusion

PicoGUS suits a retro computing enthusiast who wants to run DOS games and demoscene productions on real hardware with a period-correct Ultrasound card, because the Gravis Ultrasound is the part most DOS software expects and the project concentrates on it, and because the hardware design is open enough to build yourself. It is the wrong choice if you want a general purpose sound card for a modern system, and it is the wrong choice if you need certainty, since the project states plainly that emulation is imprecise and that some things will likely never be perfect. Verify first which of the emulated devices your target software needs and check the compatibility list in the wiki, decide between an assembled card and the documented reset issue in the DIY revision, and read the licensing split before you modify the board design or redistribute the firmware.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. polpo/picogus on GitHub
4. README
5. Releases