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:
It doesn’t look like anybody ever chose that assignment, though. Maybe someone here could enroll
TLDR: A professor will give your Masters thesis an A+ if he can get to play The Settlers with Gravis Ultrasound music
Re: Professor wants GUS in FPGA
Posted: Wed Jul 21, 2021 6:33 am
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.
Re: Professor wants GUS in FPGA
Posted: Wed Jul 21, 2021 9:13 am
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.
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.
Re: Professor wants GUS in FPGA
Posted: Wed Jul 21, 2021 7:27 pm
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.
Re: Professor wants GUS in FPGA
Posted: Wed Jul 21, 2021 8:17 pm
by xolod79
yes GUS would be very nice to get on ao486
Re: Professor wants GUS in FPGA
Posted: Wed Jul 21, 2021 9:13 pm
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 ?
Re: Professor wants GUS in FPGA
Posted: Wed Jul 21, 2021 9:53 pm
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.
Re: Professor wants GUS in FPGA
Posted: Wed Jul 21, 2021 11:38 pm
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.
Re: Professor wants GUS in FPGA
Posted: Thu Jul 22, 2021 9:24 am
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.
Re: Professor wants GUS in FPGA
Posted: Thu Jul 22, 2021 1:52 pm
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.
Re: Professor wants GUS in FPGA
Posted: Thu Jul 29, 2021 9:04 pm
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.
Re: Professor wants GUS in FPGA
Posted: Thu Jul 29, 2021 9:38 pm
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
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.
Re: Professor wants GUS in FPGA
Posted: Fri Jun 09, 2023 2:57 pm
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.
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.
A lot of hope - that’s a very skilled individual. Great find!
Re: Professor wants GUS in FPGA
Posted: Sun Jun 30, 2024 10:49 am
by pgimeno
Well, nukeykt gets the A+
I wish it was that easy to port it to the MiSTer, but there are two issues that an implementor would have to deal with. One is the FPGA occupation; the other is the sharing of the RAM with the rest of the core, and by that I mean bus arbitration, not space. So, as much as I wish we had it, I doubt we'll ever see it.
Yes I've used MegaEm to play some MIDIs, but for me, what really did the GUS stand out was a different piece of software: CapaMOD, a module player by Flap, a member of scene group Capacala. It only supported GUS, and it was the most accurate and best sounding module player for PC for a long while, until Cubic Player was mature enough and fixed certain bugs. Also, Cubic Player required a decent CPU in order to apply proper filtering; without it, CapaMOD sounded better. So, I'd be delighted to be able to use CapaMOD again to play modules.
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.