VOGONS


First post, by polpo

User metadata
Rank Newbie
Rank
Newbie

Hi all, I've been experimenting with a hardware/software project to create an ISA card that can emulate a Gravis Ultrasound using a Raspberry Pi 3 (or similar/faster, such as the Pi Zero 2 W and Pi 4). Since I've gotten to a pretty good point and people on Twitter liked it, I thought I'd post here. I'm calling it PiGUS. The project is open source – I used RPiISA (https://github.com/eigenco/RPiISA) as a starting point for the hardware and am using DOSBox's GUS emulation code on the Pi. Code and hardware design are on GitHub: https://github.com/polpo/pigus

Also of note: as is, this is a fairly general-purpose ISA to Raspberry Pi adapter! My first proof of concept with this hardware was AdLib emulation, and code for that is in the GitHub repo.

Hardware
The hardware is a pretty basic 8-bit ISA card that brings address, data, port IO, IRQ, and DMA signals to the Pi's GPIO connector. I am using TI TXS0108E auto direction sensing level shifters for the bus interface to translate between 3.3V and 5V and that seems to be working well. Real translating bus transceivers would be ideal, but I am basically out of GPIOs in the current design for an input/output direction signal. The lack of GPIOs is also the reason for only using an 8-bit ISA card – there aren't enough GPIOs for the lines necessary for 16-bit DMA, etc.

Here's the board. I originally designed it so the Pi could plug right into it but got the orientation of the connector wrong. With this design the Pi is connected via a ribbon cable. Inspired by the GUS, there is a pin header with all ISA lines present, which helps with connecting a logic analyzer or adding any bodges (which I've been lucky to not need so far).

pigus.jpg
Filename
pigus.jpg
File size
503.76 KiB
Views
3532 views
File license
CC-BY-4.0

And here it is plugged into an ISA slot on a Pentium 133MMX board. The wires connected to the ISA pin header are going to my logic analyzer.

IMG_2076.jpg
Filename
IMG_2076.jpg
File size
1.92 MiB
Views
3532 views
File license
CC-BY-4.0

Software
The software on the Raspberry Pi is running bare metal, using the Circle bare-metal environment (Circle is also used by MT-32pi, Pi1541, and other projects). Different cores on the Pi are responsible for IO handling and GUS emulation and sound output. Port IO reads/writes are handled by the IO routines and passed over to the GUS emulator. I am using the GUS emulation code from DOSBox, but I have also looked at PCem and MAME's GUS emulation. Currently all bus handling is done with polling in its own thread – IRQs on the Pi are not fast enough to meet ISA bus timing. There is fast IRQ (FIQ) on the Pi that is fast enough, but it can only be used on one GPIO pin.

Let's see and hear this thing running!!
Check out this Twitter thread with videos of various module files being played through the PiGUS, highlighting current strengths and deficiencies: https://twitter.com/ianpolpo/status/1535715886190866432

Status
Currently working:
- Port IO implemented. This limits what programs can actually play audio. I've been using CapaMOD as it can be forced to use system timers instead of the GUS's and also be forced to use port IO for sample uploading.
- Sound output over the Pi's analog headphone jack using PWM
- Resampling for channel counts >14 voices

Still to be implemented:
- Better resampling
- IRQs (timers, etc.)
- DMA (sample upload)
- I2S sound output (this will bring higher quality audio and also enable sound output on Pis without analog sound like the Zero 2 W and CM4)

Future
I'm envisioning a final version of the board with the following features:

Definite:
- Red PCB (this is a must!!)
- Direct attachment GPIO header for Pi 3, Pi Zero 2 W, Pi 4
- Low-profile connectors for Pi CM4
- I2S pins routed and placed for the commonly available generic PCM5102-based module (https://github.com/dwhinham/mt32-pi/wiki/GY-P … 5102-DAC-module)

Probable:
- Address decoding in hardware, perhaps using a PAL. This will free up a lot of GPIO pins!
- Proper directional bus transceivers for better bus signal integrity
- General purpose FIQ pin with OR of all bus signals we need to react quickly to (IOR, IOW, TC) in case polling is problematic

My time to work on this is relatively limited given that I have a family and a full-time day job as a software engineer, but I've made pretty steady progress on things so far. If anyone is wanting to help out and contribute to this project, I'd greatly appreciate it. It's my intention that this is an open project!

Reply 1 of 117, by darry

User metadata
Rank l33t++
Rank
l33t++

This is a really nice idea and implementation .

I hope it might eventually blossom into a general purpose ISA to Pi adapter software defined multi sound card implementation, but even having "only" (does not seem like the right word here) full, accurate GUS support will still be fantastic .

Reply 2 of 117, by Tiido

User metadata
Rank l33t
Rank
l33t

You'll definitely want to do the address decode part in hardware, you can even use pair of 74x688 chips if you don't want to use a PAL/GAL. All the pins you free up will be able to support many of the missing but essential things for proper compatibilty ~

T-04YBSC, a new YMF71x based sound card & Official VOGONS thread about it
Newly made 4MB 60ns 30pin SIMMs ~
mida sa loed ? nagunii aru ei saa 😜

Reply 3 of 117, by the3dfxdude

User metadata
Rank Member
Rank
Member

Dr Scott M. Baker has done a more complete ISA-to-PI card for emulating a floppy drive, here: https://www.smbaker.com/raspberry-pi-virtual- … -xtat-computers

It includes some useful things like power and reset signaling. I definitely would like to see a complete ISA-to-PI reference design utilizing as much as we can on the ISA bus for quick emulation prototyping.

Reply 4 of 117, by Shreddoc

User metadata
Rank Oldbie
Rank
Oldbie

Really enthused to see this project.

I love how it orchestrates various existing open works together, along with this author's own not-inconsiderable work, to reach a goal (arguably) greater than the sum of it's parts. These are the best projects.

I will be following it closely. And suspect, that if I am ever to own a "hardware" GUS, then it will be in this form.

Reply 5 of 117, by aitotat

User metadata
Rank Member
Rank
Member

Good luck with the project!

Since you are going to do hardware address decoding, I suggest an option to also decode ports used by SB16 and (intelligent mode) MPU401 as well (+one extra OPL) . That way the software could later evolve for one perfect single card sound solution.

Reply 7 of 117, by rasz_pl

User metadata
Rank Oldbie
Rank
Oldbie

so raw pi IO in bare metal mode is fast enough to handle ISA bus transactions? 😮
I assumed you would need pico RP2040 with PIO to respond fast enough. Add ~$2 8MB SPI PSRAM APS6404L and you could do any sound card emulation on pico

If you can handle ISA then one could do IDE (Gotek like Optical Driver Emulator - Is it possible?) reusing your code

Reply 9 of 117, by polpo

User metadata
Rank Newbie
Rank
Newbie
rasz_pl wrote on 2022-06-12, 11:16:

so raw pi IO in bare metal mode is fast enough to handle ISA bus transactions? 😮
I assumed you would need pico RP2040 with PIO to respond fast enough. Add ~$2 8MB SPI PSRAM APS6404L and you could do any sound card emulation on pico

Yes, it's fast enough, amazingly. It took some discussion on Twitter with of Claude Schwarz of the PiStorm 68K emulator project to make me believe it was possible! And that runs on Linux, not even bare metal.

The RP2040 is really attractive. The PIO is great and you can actually buy a Pi Pico without relying on stock notification bots or buying from a scalper. I dismissed it as an option due to the RAM and was worried that PSRAM wouldn't be fast enough but maybe it actually is. I also was worried about taking up GPIO pins for SPI for the PSRAM, but if I do hardware address decoding that is probably fine. I should get one and experiment, but my main focus for right now is getting accurate GUS emulation on a Pi 3.

Reply 11 of 117, by shock__

User metadata
Rank Oldbie
Rank
Oldbie

As the main ARGUS guy ... this is a project I've been looking for <3
Finally a hardware based GUS compatible solution without legacy parts.

Looking forward for this project to reach a final stage and much success along the way.

Current Project: new GUS PnP compatible soundcard

[Z?]

Reply 13 of 117, by root42

User metadata
Rank l33t
Rank
l33t

I was following you on Mastodon and Twitter, and am really eager to see the next stages, including the CM4 support! I am also interested in how far people will push the Pico -- My guess would be that it would be pretty good at least for OPL2 emulation. Didn't even know you could attach more RAM to it!

YouTube and Bonus
80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, SnarkBarker & GUSar Lite, PC MIDI Card+X2+SC55+MT32, OSSC

Reply 14 of 117, by Lennart

User metadata
Rank Member
Rank
Member
root42 wrote on 2022-06-13, 11:13:

I was following you on Mastodon and Twitter, and am really eager to see the next stages, including the CM4 support! I am also interested in how far people will push the Pico -- My guess would be that it would be pretty good at least for OPL2 emulation. Didn't even know you could attach more RAM to it!

In that case you'll probably be interested in RP2040 Doom, which is a port of Chocolate Doom that does OPL2 emulation on the Pico (oh, and it is also running the rest of the game of course 😜). You can find a rather detailed article from the author of the port here: https://kilograham.github.io/rp2040-doom/

On topic: nice project, eager to see how it progresses!

Reply 16 of 117, by root42

User metadata
Rank l33t
Rank
l33t
Lennart wrote on 2022-06-13, 14:11:
root42 wrote on 2022-06-13, 11:13:

I was following you on Mastodon and Twitter, and am really eager to see the next stages, including the CM4 support! I am also interested in how far people will push the Pico -- My guess would be that it would be pretty good at least for OPL2 emulation. Didn't even know you could attach more RAM to it!

In that case you'll probably be interested in RP2040 Doom, which is a port of Chocolate Doom that does OPL2 emulation on the Pico (oh, and it is also running the rest of the game of course 😜). You can find a rather detailed article from the author of the port here: https://kilograham.github.io/rp2040-doom/

On topic: nice project, eager to see how it progresses!

Extremely interesting link! I like it! This is not only "oh, Doom on YET another platform", but it is Doom being ported in a meaningful way, and having the OPL2 emulation!

YouTube and Bonus
80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, SnarkBarker & GUSar Lite, PC MIDI Card+X2+SC55+MT32, OSSC

Reply 17 of 117, by rasz_pl

User metadata
Rank Oldbie
Rank
Oldbie
root42 wrote on 2022-06-14, 07:42:

Extremely interesting link! I like it! This is not only "oh, Doom on YET another platform", but it is Doom being ported in a meaningful way, and having the OPL2 emulation!

not only 'having the OPL2 emulation', as already existing emulators ran at 0.3 to 1x of realtime utilizing 100% of overclocked pico CPU, but rewriting one based on how real hardware operates https://kilograham.github.io/rp2040-doom/sound.html:

Around that time, I read some more about the OPL2 internals, and realized that the real chip produced its output using simple integer math with no multiplies via canny use of logarithms and lookup tables.

we use just 5%-20% of one overclocked core, which is really great, and about a 30x speed improvement from where it all started

its not full OPL2, and will need some modding to support all games

Unused OPL2 features were removed. This included the percussion support as mentioned above, along with timer features which the Doom code doesn’t use either

Reply 18 of 117, by Plasma

User metadata
Rank Member
Rank
Member
shock__ wrote on 2022-06-12, 19:02:

As the main ARGUS guy ... this is a project I've been looking for <3
Finally a hardware based GUS compatible solution without legacy parts.

Looking forward for this project to reach a final stage and much success along the way.

Unless I am missing something this is not hardware based. All the emulation is in software.

I agree this is a cool project but why not use an FPGA?

Reply 19 of 117, by polpo

User metadata
Rank Newbie
Rank
Newbie

I'd love to use an FPGA, and such a solution would be far better suited to emulating a GUS, but I don't know any Verilog beyond "make the LED blink." Simple as that!