Emulate Any ISA Card With A Raspberry Pi And An FPGA

A 386 motherboard with a custom ISA card plugged in

One of the reasons the IBM PC platform became the dominant standard for desktop PCs back in the mid-1980s was its open hardware design, based around what would later be called the ISA bus. Any manufacturer could design plug-in cards or even entire computers that were hardware and software compatible with the IBM PC. Although ISA has been obsolete for most purposes since the late 1990s, some ISA cards such as high-quality sound cards have become so popular among retrocomputing enthusiasts that they now fetch hundreds of dollars on eBay.

So what can you do if your favorite ISA card is not easily available? One option is to head over to [eigenco]’s GitHub page and check out his FrankenPiFPGA project. It contains a design for a simple ISA plug-in card that hooks up to a Cyclone IV FPGA and a Raspberry Pi. The FPGA connects to the ISA bus and implements its bus architecture, while the Pi communicates with the FPGA through its GPIO ports and emulates any card you want in software. [eigenco]’s current repository contains code for several sound cards as well as a hard drive and a serial mouse. The Pi’s multi-core architecture allows it to run several of these tasks at once while still keeping up the reasonably high data rate required by the ISA bus.

In the videos embedded below you can see [eigenco] demonstrating the system on a 386 motherboard that only has a VGA card to hook up a monitor. By emulating a hard drive and sound card on the Pi he is able to run a variety of classic DOS games with full sound effects and music. The sound cards currently supported include AdLib, 8-bit SoundBlaster, Gravis Ultrasound and Roland MT-32, but any card that’s documented well enough could be emulated.

This approach could also come in handy to replace other unobtanium hardware, like rare CD-ROM interfaces. Of course, you could take the concept to its logical extreme and simply implement an entire PC in an FPGA.

 

28 thoughts on “Emulate Any ISA Card With A Raspberry Pi And An FPGA

  1. The Schematic on Github connects the ISA bus directly to the FPGA board. The FPGA board looks like the TB276 board. That board does not have level shifters. Is he running the Cyclone IV out of spec?

    And he can’t emulate all ISA cards. In particular he can’t emulate 16 bit cards with his 8 bit card.

  2. Why not simply use a raspberry pi pico (aka.rp2040) and some discrete logic buffers?
    with a dvi-sock for 640×480 video and audio out.
    16bit would require more buffers and maybe impact bus speed as “there is simply not enough pins”

    1. That’s what my PicoGUS project does: https://github.com/polpo/picogus. It was originally created to emulate a Gravis Ultrasound but I also have Adlib and MPU-401 support in the works. It was mentioned in a Hackaday post a while ago about a project inspired by it that emulates an NE2000 card in a PCMCIA card with a Pico: https://hackaday.com/2022/09/25/pi-pico-w-does-pcmcia-gets-this-ibm-pc110-online/

      There are a few tradeoffs with “simply” using an RP2040. PIO does help an awful lot with handling events on the ISA bus but as soon as the M0 ARM cores on the RP2040 get involved things can slow down a lot. Depending on what you’re doing, you may wind up holding IOCHRDY low on the ISA bus low for a long time, effectively halting ISA bus. So you’re limited in what you can emulate.

      The project linked here has the benefit of four 1GHz-plus A53 or A72 cores, hundreds or thousands of megabytes of RAM, plus the FPGA for keeping track of events on the ISA bus. There’s probably a lot more that this arrangement can handle than what a Pico can do. I personally started on the path of using a full RPi, bit-banging the ISA bus, but the continued scarcity of RPis made me pivot over to using the Pi Pico. Fortunately, it’s just powerful enough to emulate my target, the Gravis Ultrasound.

      1. the thing about using the dvi-sock is your runnning the pico at 253 MHz. thats almost twice the normal speed, and the ISA bus is only 4.77 MHz, mostly handled by the PIO.
        If you run you programs from ram, (limiting display output to mcga 320x200x8) you can even overclock it to around 400 MHz. I have never use a GUS, only SB, but 2 cores at 400MHz seems like it should be “enough for everyone”. =)

    2. Probably because a Pico cannot respond sufficiently fast to ISA read requests, the time between the address being valid and the data being read on the bus is to short to enter an ISR, read the address, fetch the data from memory and write it to the databus.

      In an FPGA, the register map and memory map of the device being emulated can be stored in dual-port memory blocks, where it can be retrieved by logic, an order of magnitude faster than the ISA bus requires.

      A Pico may be a reasonably fast microcontroller, but it’s no match for an FPGA for tasks that are suitable for implementation in FPGA logic.

      1. I have another comment upthread awaiting moderation, probably because it has URLs in it, but in short the Pico, especially when overclocked, is fast enough to work on the ISA bus, especially with judicious use of IOCHRDY to extend ISA bus cycle length. A simple address decode + data fetch is fast enough even without IOCHRDY.

      2. An RP2040 is a reasonably fast dual core SoC. If you don’t want to spend time optimizing cycles or using the programmable GPIO accelerators, dedicate one core to bus I/O and the other to peripheral emulation.

        1. The Pico runs at 125MHz. The ISA bus runs at 8MHz, so to respond within half a clock period, the Pico can use at most 6 cycles when running from an independent clock.

          I just realised there is a little more wriggle room if you run the Pico at 128MHz (only slightly over spec), phase-locked to the 8MHz bus clock.

          Using one of the two cores exclusively for the bus might work, I hadn’t considered that; I’m not really used to multi-core microcontrollers.

          1. Does the pico have enough gpios to interface the ISA bus directly? looks like it only has 36, but the 8 Bit ISA bus is 62 pin connector. 24 gpios alone for the 8bit data bus and 16bit address bus. and numerous other pins for bus status etc.

          2. Depending on what you want to do, there can be enough GPIOs to interface directly, but you still need level shifting. If you only need to handle port IO, you only need at bare minimum:

            – 10 address bits
            – 8 data bits
            – IOR and/or IOW
            – AEN to ignore IO during DMA on other ISA cards
            – IOCHRDY if your program is not fast enough to handle IO within 4 clock cycles

            So that’s 22 GPIOs, or 20 if you only need to handle only writing or reading IO instead of both, and your program is simple/fast enough to not need IOCHRDY.

            Adding IRQ needs 1 more pin, DMA 3 more pins (4 if you want to do it by the book), and if you want to handle memory, 2 more for MEMR and MEMW.

      3. the PIO in the RP2040 can handle ISA bus transactions reasonably well, the main issue is the limited number of IO lines on it, some designs use a multiplexer that can also do level shifting to multiplex the address and data lines, with tri state buffers handling control signals.

  3. Oh lordy me. This is why I read hackaday. Every so often something shows up so up your street. It hurts!

    The whole retro computer cyborg (part organic retro computer and synergic modern drop in replacement) is just so much fun.

  4. I’m always fascinated by those projects! 😃

    Let’s just don’t forget the ship of Theseus..
    And some point, nothing of the original (the soul) will remain.

    We replace HDDs with CF cards, floppy drives with Goteks, datasette drives with mp3 players, classic mechanical mice with cheap USB optical mice+adapters, diskettes with USB pen drives..

    If we upgrade or replace too much, the whole project becomes pointless.

    We’re end up working with *something* that pretends to be something else. That’s what emulators do.

    However, even it’s still functionally *the same*, the experience perhaps isn’t. Every little nuance may count.

    If you like to want to experience what the creators/developers of some given games or applications really felt when they were working on a project back in the day, then you need to surround you with the same things they had used. With all its quirks and shortcomings.

    That way, you can try to put yourself into his/her position and maybe come to similar conclusions, understand certain decisions. It’s not objects, of course, but also music, the language, the Zeitgeist of a certain era.

    1. I tried to use a PC1512 the same way I used it back in the day:
      – Filecard, impossible to fine one working.
      – Floppy, we need to buy them one by one and get working ones.
      -XT IDE : Nice, I can have all what I want in a simple way….
      I mean: Or we spend a huge time and effort to reproduce what was boring even back in the day and no more use the machine, or we add modern part in it and have fun during years…
      If we try to show a game loading in a floppy in exhibition, noone even notice it.

  5. I was like neat, might be another channel to subscribe to. Then I looked at dude’s videos, and like the 4th one down is something about him “drinking his daily dose of blood.”

    Hard pass.

    Why are creative people so damn crazy?

    1. I would imagine coding software is more accessible to more people. “coding” for an FPGA is like black magic to most people. Could also be that an FPGA with enough logic blocks to emulate a majority of cards is cost prohibitive.

    2. Q: Why do any of this when DOSbox already emulates a bog standard Soundblaster and all the games already run with sound?
      A: Nerds, the bog standard soundblaster kind of sucked. They think this accomplishment will impress females.

      1. I know you’re trolling, but you have a point. The whole point of using original retro hardware is to be accurate to original hardware, and FPGA is as close as you can get when you can’t get that hardware (a la misterfpga). But if you’re just going to bridge it to a software emulator you might as well just run the whole thing on an emulator. So yeah like that lasidfj lkjadsf guy said the creator probably doesn’t know fpga programming that well so can’t fault em too much.

        1. Code on FPGA require much more effort and even on an FPGA, be 100% accurate is almost impossible.
          Sound Blaster DSM run on a Microcontroller, it is software. So, the FPGA should emulate the Microcontroler and include its software ?
          Also, everything is available with dosbox code, this make the development much more simple.
          Conclusion : Up to you to spend years to emulate everything on FPGA, with no guarantee it will be 100% accurate and with almost nobody here able to check if it actually is.

  6. i think this would have been cooler had it been the other end. like make a board that can mount next to a mini-itx or micro atx using the extra mounting holes you would have used for a full atx, that you can plug isa cards into. then give it a pcie or internal usb interface. then you can run the legacy professional cards with a modern pc.

    with this you might be able to emulate the card, but are at the mercy of the available hardware on the pi. so it might look like a high quality classic sound card, but you dont get the dac or amps or any filtering.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.