Professor wants GUS in FPGA

ToothbrushThreepwood
Posts: 88
Joined: Sun May 24, 2020 8:39 pm
Has thanked: 30 times
Been thanked: 32 times

Professor wants GUS in FPGA

Unread post by ToothbrushThreepwood »

I stumbled across this potential master thesis project proposed by a professor at a University in Hungary. I don’t know if it is at all feasible in the fpga/SoC of the DE-10 Nano, but I thought people here might like it, since GUS support on the ao486 gets requested from time to time:

https://www-mit-bme-hu.translate.goog/e ... ax,nv,elem

It doesn’t look like anybody ever chose that assignment, though. Maybe someone here could enroll :D

TLDR: A professor will give your Masters thesis an A+ if he can get to play The Settlers with Gravis Ultrasound music :lol:

throAU
Posts: 181
Joined: Fri Sep 11, 2020 1:06 am
Has thanked: 229 times
Been thanked: 27 times

Re: Professor wants GUS in FPGA

Unread post by throAU »

Layman non-FPGA developer guess:

The GUS doesn't do anything that complicated vs. what we already have IMHO. It just mixes samples at up to 44khz based on channel count with some basic effects, and audio playback isn't that bandwidth intensive with the buses we have today.

Whether there's room inside something like ao486 I have no idea. How to implement, I have no idea, but the raw throughput required is (I estimate) far less than something like the VDP1/VDP2 that srg320 appears to have mostly completed for the Saturn core.

I'm interested - I used to have a GUS and they're the premier sound card for the 90s demo scene. Basically much later than that (i.e., after the GUS was relevant), Windows abstracted the hardware away (things started using direct sound) so that hardware didn't matter so much. It's one of the last cards that really needs a specific hardware implementation imho - because lots of stuff drives it directly rather than through Windows.


edit:
Not to trivialise the work or suggest I expect it - I have no idea how to develop for FPGA.

Just that I believe there are already cores that demand much more complexity than the GF1 chip already available on the MiSTer.
ToothbrushThreepwood
Posts: 88
Joined: Sun May 24, 2020 8:39 pm
Has thanked: 30 times
Been thanked: 32 times

Re: Professor wants GUS in FPGA

Unread post by ToothbrushThreepwood »

Yes, the legal obstacles are probably equal to the technical ones. The wavetables in the chip ROM seem to be copyrighted, and still held by someone today, similar to the AMIGA kickstarts and Cloanto. Not that it’s stopping anyone from downloading them from the net.

Some guy already reversed the PCB schematics of the board and recreated a GUS PnP using currently available components (and shared the files):
https://www.vogons.org/viewtopic.php?f=62&t=42431
On the last few pages they discuss the feasibility of integrating it all in FPGA, but the guy mentions the large amount of I/O of the GUS as a challenge to FPGA implementation. He does state that he’s not an FPGA guy, so take it with a grain of salt.
ToothbrushThreepwood
Posts: 88
Joined: Sun May 24, 2020 8:39 pm
Has thanked: 30 times
Been thanked: 32 times

Re: Professor wants GUS in FPGA

Unread post by ToothbrushThreepwood »

There’s even a russian store selling DIY GUS boards similar in design:
https://chipkin.ru/product/konstruktor-gusar/
softtest9
Posts: 158
Joined: Thu May 28, 2020 7:13 pm
Has thanked: 3 times
Been thanked: 21 times

Re: Professor wants GUS in FPGA

Unread post by softtest9 »

There are no legal obstacles to making a core. If a firmware or ROM is required, then you simply tell users the correct filename and hash and let them figure out how to acquire it.
Bas
Top Contributor
Posts: 495
Joined: Fri Jan 22, 2021 4:36 pm
Has thanked: 58 times
Been thanked: 219 times

Re: Professor wants GUS in FPGA

Unread post by Bas »

Wavetables on GUS were uploaded to the card if I recall correctly, not ROM's. I seem to remember plugging in additional DRAM chips in mine to reach 1MB of sound RAM. The default patches could be replaced by converting a SoundFont with a more liberal license.

Getting a GUS in AO486 would be awesome. Much like a well-supported SCSI controller to replace IDE, but I'm not holding my breath.
xolod79
Core Developer
Posts: 38
Joined: Wed May 27, 2020 8:13 pm
Has thanked: 6 times
Been thanked: 34 times

Re: Professor wants GUS in FPGA

Unread post by xolod79 »

yes GUS would be very nice to get on ao486
MiSTer_Kirk
Posts: 210
Joined: Thu Feb 04, 2021 11:42 pm
Has thanked: 18 times
Been thanked: 46 times

Re: Professor wants GUS in FPGA

Unread post by MiSTer_Kirk »

Why not go the way of the MT32-Pi ?
Call it the GUS-Pi. Infact, why not have many different soundcards to select from, on the Pi ?
ToothbrushThreepwood
Posts: 88
Joined: Sun May 24, 2020 8:39 pm
Has thanked: 30 times
Been thanked: 32 times

Re: Professor wants GUS in FPGA

Unread post by ToothbrushThreepwood »

Bas wrote: Wed Jul 21, 2021 7:27 pm Wavetables on GUS were uploaded to the card if I recall correctly, not ROM's. I seem to remember plugging in additional DRAM chips in mine to reach 1MB of sound RAM. The default patches could be replaced by converting a SoundFont with a more liberal license.
You’re right, it looks like only the AMD InterWave successor cards stored samples in ROM (and/or RAM), while the original GUS’es only used onboard RAM. I never owned either though.

We’re already kind of spoiled on the sound side with OPL and MT32 support, but I’d love to have either a GUS or an Ensoniq card as well for the demo scene music and for the (arguably few) games that really stood out with those cards compared to SoundBlaster/MIDI.
It’s probably a bit greedy though. I mean, if anyone in the 1990ies owned a SB and an MT-32 they would probably be pretty darn satisfied with their sound hardware.
throAU
Posts: 181
Joined: Fri Sep 11, 2020 1:06 am
Has thanked: 229 times
Been thanked: 27 times

Re: Professor wants GUS in FPGA

Unread post by throAU »

Bas wrote: Wed Jul 21, 2021 7:27 pm Wavetables on GUS were uploaded to the card if I recall correctly, not ROM's. I seem to remember plugging in additional DRAM chips in mine to reach 1MB of sound RAM. The default patches could be replaced by converting a SoundFont with a more liberal license.

Getting a GUS in AO486 would be awesome. Much like a well-supported SCSI controller to replace IDE, but I'm not holding my breath.
Yup, the GUS wavetable memory was RAM. And there were plenty of alternative patch sets (or the game could use their own) to get better sounds as the standard original model only had 256 Kb of onboard memory expandable to 1 Mb (so some patch sets were released to take advantage of expanded cards).

So, even if the original patch set is not distributable, you could get a "mostly period correct in terms of third party enhancement" patch set by getting one of those from somewhere.

But... most of the cool stuff on GUS wasn't using the standard patch set (or general midi) anyway. That was provided for midi playback, which wasn't the card's strong point.

Can't stress that enough - the GUS is very niche, and only during a very niche time period. Let's say between 1992 and 1996. As soon as Windows 95 and CPUs of Pentium MMX or faster speed started popping up, CPU based software mixing got "cheap" and the GUS trump card was no longer relevant. Great for Demoscene, great for some games that supported it properly, but 90% of the time when running in midi or Soundblaster compatibility mode it kinda sucked. I say that as someone who loved my GUS at the time. The Midi/MT-32 compatibility was quite bad. An MT-32 sounds much, much better.

Why? requirement for large TSRs taking up DOS conventional memory, questionable matching of GUS patch set sounds to general midi or MT-32 patches, etc.

I'm sure there's content on YouTube, but compare a GUS running midi or MT32 emulation via MegaEm to a real MT-32 that the music was written for and its really pretty crap.

But... when software supported it properly it was amazing due to doing hardware mixing and taking that burden off the CPU.


So on one side... building a GUS core would be neat as the original hardware wasn't common, had niche use, etc. But on the flip side... its a very small niche.
Bas
Top Contributor
Posts: 495
Joined: Fri Jan 22, 2021 4:36 pm
Has thanked: 58 times
Been thanked: 219 times

Re: Professor wants GUS in FPGA

Unread post by Bas »

I combined a GUS with an SB at some point, which was barely doable due to assumptions about IRQ and DMA overlapping and developers not catering for my weird config. I did love my GUS as a MIDI card, but only as a creator. Also dabbled a lot with trackers, for which it also was a great card.
throAU
Posts: 181
Joined: Fri Sep 11, 2020 1:06 am
Has thanked: 229 times
Been thanked: 27 times

Re: Professor wants GUS in FPGA

Unread post by throAU »

Yeah it was great for trackers. At least those that didn’t also include opl3 tracks alongside samples (impulse tracker did I think?). Because the Gus didn’t have fm synth.
johey
Posts: 7
Joined: Tue Jul 27, 2021 1:08 pm

Re: Professor wants GUS in FPGA

Unread post by johey »

MiSTer_Kirk wrote: Wed Jul 21, 2021 9:13 pm Why not go the way of the MT32-Pi ?
Call it the GUS-Pi. Infact, why not have many different soundcards to select from, on the Pi ?
MIDI data has very low bandwidth requirements compared to audio. Just saying. I have no idea if it would be a problem.
mahen
Posts: 185
Joined: Sun May 24, 2020 8:25 pm
Has thanked: 19 times
Been thanked: 6 times

Re: Professor wants GUS in FPGA

Unread post by mahen »

Yep, we're pretty spoiled already :) But that would definitely be cool for the demoscene and to get proper (not downsampled) mixing in some games -- Paula still sounds better than the SB in quite a few scenarios.

Anyway, each time something is achieved I feel extremely lucky considering how niche all this is. Grateful and a bit ashamed as I have the feeling FPGA devs are working almost as slaves ;)
SerErris
Posts: 17
Joined: Sun May 31, 2020 10:28 pm
Been thanked: 1 time

Re: Professor wants GUS in FPGA

Unread post by SerErris »

johey wrote: Thu Jul 29, 2021 9:04 pm
MiSTer_Kirk wrote: Wed Jul 21, 2021 9:13 pm Why not go the way of the MT32-Pi ?
Call it the GUS-Pi. Infact, why not have many different soundcards to select from, on the Pi ?
MIDI data has very low bandwidth requirements compared to audio. Just saying. I have no idea if it would be a problem.
The GUS has no midi input , so no game or any other native software would ever work. The GUS CPU has been exposed directly to the programmer and the programmer had to develop its own driver to talk to it.

I am pretty sure that developer tools existed and most likely you can find information on it in the demo scene, actually it is just a wave player with certain parameters. So someone would need to rebuild the architecture but not the real GF1 chip,

I am currently looking into that matter just for my self eduction.
User avatar
thisisamigaspeaking
Posts: 231
Joined: Mon May 23, 2022 12:28 am
Has thanked: 74 times
Been thanked: 21 times

Re: Professor wants GUS in FPGA

Unread post by thisisamigaspeaking »

Not directly MiSTer-related but maybe someone will find it interesting:

I'd like to have this in MiSTer for sure, whether it is worth anyone's time to make I don't know.

throAU
Posts: 181
Joined: Fri Sep 11, 2020 1:06 am
Has thanked: 229 times
Been thanked: 27 times

Re: Professor wants GUS in FPGA

Unread post by throAU »

SerErris wrote: Fri Jan 21, 2022 2:42 pm
johey wrote: Thu Jul 29, 2021 9:04 pm
MiSTer_Kirk wrote: Wed Jul 21, 2021 9:13 pm

Why not go the way of the MT32-Pi ?
Call it the GUS-Pi. Infact, why not have many different soundcards to select from, on the Pi ?

MIDI data has very low bandwidth requirements compared to audio. Just saying. I have no idea if it would be a problem.

The GUS has no midi input , so no game or any other native software would ever work. The GUS CPU has been exposed directly to the programmer and the programmer had to develop its own driver to talk to it.

I am pretty sure that developer tools existed and most likely you can find information on it in the demo scene, actually it is just a wave player with certain parameters. So someone would need to rebuild the architecture but not the real GF1 chip,

I am currently looking into that matter just for my self eduction.

The Gus midi support and mt32 support was via a provided TSR called MegaEm.

But yeah as I mentioned above it was crap at that. All the stuff you’d actually want to use a GUS for wasn’t using general midi, it was full digital samples.

If you want a card for general midi, use one of the Roland setups instead. They sound SOOOOO much better doing that.

Post Reply