Back at home, I had an hour today to begin some testing. I've only covered the basic ground so far, to confirm that I'm getting what everyone else is getting, but more should follow in the coming days.

PicoGUS version: 0.3.0
System: Pentium-MMX 233Mhz system with MSDOS 7.1 (i.e. the Win98SE version).

Programs tested:
(Using "/d 12" for games)

DEMOS:

Second Reality by Future Crew
Status: Perfect*
Notes: This may be an improvement over what's currently reported in the Compatibility List, pending agreement from others. I was really pleased to hear it run so well, as this demo is a must-have for many.

GAMES:

Doom 1, v1.666
Status: Perfect
Notes: I played quickly through all levels of E1, and did not encounter any issues, all musics superficially seemed correct.

Star Control 2
Status: Perfect
Notes: Played it for 15 minutes only, through several scenarios and music tracks, and did not encounter any issues.

Doom 2, v1.666
Status: Partial
Notes: Music plays, mostly or partly correctly, but the occasional instrument patch seems noticeably mis-assigned, with the beats at the very start of Level 1 providing a handy example. Sound plays, but may be less stable than Doom 1. More detailed testing needed.

--

Also tried out the live firmware flashing feature with the Adlib and MPU-401 packages, which worked perfectly as expected.

I had a quick test of the Adlib mode using the game Eye Of The Beholder 2. I didn't know what to expect from this form of OPL2 emulation, but actually it sounds quite good!

-

*In this post, I use the term "Perfect" to mean "it sounded correct to me", and not as a mark of technically-measured, atomic-scale duplication! 😉

@Shreddoc did you also try digital sound for Doom? Or just music?

Another separate note I wanted to highlight, for people who don't already have/familiar with GUS.

The Gravis software package v4.11 (mentioned in the Github build guide) can be installed via it's included INSTALL.EXE, but only by selecting it's second menu option, "Restore files" (or similar). Then simply enter the wildcard *.*, and the files will be installed, bypassing the installer's IRQ/DMA checks, which would otherwise cause the install to not proceed.

appiah4 wrote on 2023-01-24, 09:13:

@Shreddoc did you also try digital sound for Doom? Or just music?

Both. Music + digital sound both seemed fine.

polpo wrote on 2023-01-22, 14:55:

One thing to note is that Mod Master XT doesn't use DMA, so changing the DMA interval will have no affect on how it sounds. I've done very little testing of it, so I'm not sure what would be causing it to not be perfect – typically programs that use port-based IO only work the best. Mod Master XT is very heavily optimized, so this is just a guess, perhaps the different timing in how the PicoGUS responds to bus events compared to a real GUS could be tripping it up. I think any differences you hear in how playback performs from run to run is down to pure chance.

In Mod Master XT, I use volume ramping really often. (Probably more than other players)

FreddyV wrote on 2023-01-24, 09:30:

polpo wrote on 2023-01-22, 14:55:

One thing to note is that Mod Master XT doesn't use DMA, so changing the DMA interval will have no affect on how it sounds. I've done very little testing of it, so I'm not sure what would be causing it to not be perfect – typically programs that use port-based IO only work the best. Mod Master XT is very heavily optimized, so this is just a guess, perhaps the different timing in how the PicoGUS responds to bus events compared to a real GUS could be tripping it up. I think any differences you hear in how playback performs from run to run is down to pure chance.

In Mod Master XT, I use volume ramping really often. (Probably more than other players)

My issue with it was actually just a dying left channel on the I2S module (and in the end, even that just turned out to be a soldering issue in the pre-built module itself).

After swapping it, the missing notes were there, of course... I only didn't notice it sooner, because I had both speakers next to each other and only realized much later (after testing other players and setting the balance) that one wasn't even playing anything. This successfully suppressed all notes /effects that were played exclusively (or almost exclusively) on the left channel and made it sound a little off to me. It only seems to have manifested itself sometimes between earlier testing and then, which isn't too much of a surprise, when one pin is more glued on than soldered 😁 At least, an easy fix and the module is reusable.

So, as for me, everything is totally fine in Mod Master XT and the PicoGUS!

Thank you very much for the in-depth testing reports @krivulak and @Shreddoc! I really appreciate you taking the time to put the firmware through its paces, even if it means dealing with hard lockups. The corrupted CMOS is concerning to me – I haven't seen that happen but I do 99% of my testing on a motherboard that due to corrosion around the battery, can't keep its own CMOS settings for more than a minute being powered off... 😅

The common theme I'm seeing is that streaming audio over DMA (basically, sound effects in games) is in a "barely working" state. It's really tough to manage, as access to the external PSRAM that is used for sample memory has high latency and access to it has to be multiplexed, so if a read is in progress, writes have to wait and vice versa. Even with the sample cache I have, this can result in bottlenecks that mean samples can't be fetched fast enough to render all of the channels being played in real time, resulting in crackly or stuttering audio. The hanging is probably due to race conditions where IRQs could fail to fire or reads from the DMA status register don't reflect the actual reality of what's going on.

My next effort will be to better handle streaming audio by detecting when it's happening and storing those samples in a buffer in the RP2040's internal SRAM instead of taking the time to store it in PSRAM, since those samples will only be played once. Streaming audio on the GUS is a bit of a hack – two channels, one for left and right, are set to play a looping sample, and an IRQ is raised at a certain point of the loop, triggering code on the computer to DMA in the next bit of audio to be played. This is what makes me wish I had enough IRQ and DMA lines to emulate a Sound Blaster and GUS simultaneously - most games can be configured to use a SB for sound effects and GUS for music.

I don't know how relevant this comparison (slash, vague observation) is. But the MiSTer FPGA project came to the realisation early on that their mainboard's DDR3 did not have the timing/latency and other speciality characteristics needed for their retro simulation work. Accordingly, the MiSTer now requires a bespoke SDRAM expansion board in order to run much of it's content, despite having plenty of a theoretically faster, more modern RAM type already onboard.

Haven't seen anyone mention testing Quake yet, it might be interesting. Some notes:
- uses premixing and streams an interleaved buffer (left/right mixed) to the GUS using DMA
- separate voices panned for left and right, with data pointers offset by one sample, with their sampling rate set to half of the master rate (so they skip every second sample in the buffer and only play samples for their respective channel)
- all routines are custom written rather than relying on ultramid functionality/GUS SDK
- does not rely on IRQs; polls the DMA register to know when to upload more samples
- master sampling rate can be specified using the command line option "-sspeed" otherwise it defaults to the sub-optimal value of 19293Hz

Fleshing out my game testing of the 0.3.0 firmware with a wider range of games. General findings support the current conclusions. As there isn't much new information to contribute (re: games on this firmware), I won't test further games for it at present, but perhaps the specifics of the ones tested so far may be of niche interest to some readers. I have used the categorisations "Working", or "Freezes", or "Doesn't load". Note I have not seen the earlier mentioned CMOS corruption at all, on my system here - not to discount it, but there's also a possibility that it was system or build specific.

GAMES TESTED

Blackthorne
Status: Freezes
Notes: Runs. Music seems fine. Digital sound works initially, but leads to hard system freeze within minutes or seconds.

Dark Sun : The Shattered Lands
Status: Doesn't load
Notes: Sound setup and detection via SOUND.BAT works. But main game EXE aborts loading with "MIDI Detect Fail" error.

Descent
Status: Doesn't load
Notes: Setup crash.

Doom 1 v1.666, and Doom 2 v1.666
Status: Working
Notes: I've spent about an hour testing across these two games, in total. During that entire time, I had 1 sound loop freeze, in Doom 2. No actual crashes. What I will refer to as "DMA sound fizz" is present, ranging from barely noticeable in One Voice mode (chosen in the game's SETUP.EXE), to somewhat noticeable in multi Voice mode.

One Must Fall 2097
Status: Working
Notes: No issues heard. Perhaps somebody else can confirm, as the game was running over-fast due to my system's speed.

Pinball Fantasies
Status: Working
Notes: No issues heard.

Raptor : Call of the Shadows (v1.1)
Status: Working
Notes: ..but with a lot of DMA sound fizz on the digital sound. Music good.

Rebel Assault (CDROM/ISO)
Status: Working
Notes: Slight DMA sound fizz.

System Shock (original/floppy version)
Status: Doesn't load
Notes: Hard freezes when running SHOCKGUS.BAT, due to LOADPATS.EXE.

Tyrian, v2.1
Status: Freezes
Notes: Runs, with music and sound. DMA sound fizz present. Ran demo mode ok for 15 minutes, then hard system freeze.

Wacky Wheels
Status: Freezes
Notes: Runs. Music seems good. Hard system freeze as soon as digital sound starts.

DEMOS TESTED

Despair by Iguana *may add to the Compatibility List*
Status: Working
Notes: No issues heard.

Dope by Complex
Status: Working
Notes: No issues heard, when using "PGUSINIT /a 8" as noted in the Compatibility List.

Stars by Nooon
Status: Working
Notes: No issues heard.

jmarsh wrote on 2023-01-25, 00:04:

Haven't seen anyone mention testing Quake yet, it might be interesting. Some notes: - uses premixing and streams an interleaved […]
Show full quote

Haven't seen anyone mention testing Quake yet, it might be interesting. Some notes:
- uses premixing and streams an interleaved buffer (left/right mixed) to the GUS using DMA
- separate voices panned for left and right, with data pointers offset by one sample, with their sampling rate set to half of the master rate (so they skip every second sample in the buffer and only play samples for their respective channel)
- all routines are custom written rather than relying on ultramid functionality/GUS SDK
- does not rely on IRQs; polls the DMA register to know when to upload more samples
- master sampling rate can be specified using the command line option "-sspeed" otherwise it defaults to the sub-optimal value of 19293Hz

Fascinating, thanks for pointing this out! I've just found snd_gus.c from the Quake source and will be giving it a close look. I gave Quake 1.06 a quick test (with pgusinit /d 12) and while it runs stable when playing for ~5 minutes, the sound is echoey, almost like the data pointer offset you described is off by several samples instead of one. There's also repeating noise, probably due to garbage data in the sample data.

This is certainly an interesting project. I might just want to build one of these when the budget is a little less constrained.

Since that's not feasible yet, I'm wondering if any of you have done any testing to compare the output of this design to a classic old GUS. It could be interesting to see, for instance, whether the output currently matches what would come out of the genuine card. A good starting point for such a comparison could be my old GUS_TEST.EXE. Running this should use the GUS synthesiser to put out a fairly perfect 150 Hz sine wave, and there are other options to vary the number of active channels, etc.

It was made to compare InterWave and GF1, so should competently detect the card type and adapt accordingly. Of course, there are bugs, so tread carefully, and if you plug speakers in at all, please keep the volume low. It assumes at least a few hundred bytes of on-board RAM, but doesn't bother to detect whether that's actually present before uploading the samples (PIO only, so DMA bugs should not cause a problem).

Hopefully that proves somewhat useful.

I have a GUS Classic and have done a lot of comparisons with it and my PicoGUS on my logic analyzer from an ISA bus behavior and timing perspective. I haven’t done any direct audio comparisons aside from a completely unscientific “sounds right to me” basis. It’d be interesting to run GUSTEST. One area where I know PicoGUS needs improvement audio-wise to bring it more in line with a real GUS is preventing clipping when mixing a lot of loud samples. One comment in the DOSBox-X GUS code posits that the DAC on the GUS might have a few more bits of headroom to prevent clipping, which would be interesting and pretty trivial to try with the DAC I use. That’s one area I haven’t focused on yet .

I'll be releasing a new firmware soon that really improves DMA, streaming audio over DMA in particular. A lot of things that did not run reliably before now run much better, and don't even need the /d option for pgusinit any more. Not needing this option means sample uploading during game startup is a lot faster as it doesn't have to artificially slow down DMA.

Games:
Doom 1.9: good (previously needed /d 12 option)
Doom II 1.9: good (previously needed /d 12 option)
Quake: good (previously needed /d 12 option, was very echoey and glitchy before)
Duke 3D: good (previously needed /d 12 option, had lots of glitches and would crash before)
Tyrian 2000: good after playing for 20 minutes or so
Descent: Music + SFX play fine, but the game crashes after a while
Hocus Pocus: plays music, but crashes after SFX plays
Doom 1.2: plays music, but crashes after SFX plays

The last two are my new nemesis – they both DMA in sound effects "just in time" each time as they're played. Doom moved away from this method and moved to software mixing because of bugs, so even on a real GUS it wasn't the most reliable thing.

Demoscene stuff:
Inside: plays fine with DMA, previously played silence or garbage
Babylon: plays fine with a couple small pops, previously played garbage or samples uploaded from previously ran programs

Things are still by no means perfect but this is a marked improvement all around.

Truly congratulations for the work done and a heartfelt thanks for what you are doing for the community

Such awesome work! Excellent results!
Really wish i had the time to jump in - as soon as i have project time available I'll be in on this!

Nervously waiting for new firmware...

PicoGUS firmware v0.4.0 is now released: https://github.com/polpo/picogus/releases/tag/v0.4.0

This includes the GUS DMA fixes I mentioned in my last post:

• Refactored DMA transfer completion handler: this results in much higher compatibility with titles that use streaming DMA. Overriding the DMA transfer interval is not necessary in most circumstances now.
  • Fixes games: Quake, Doom (and Doom engine games), Duke3D, Descent, Hocus Pocus (partially); Demo: Inside
• Fixed bug where DMA control register was not properly reset between transfers. Fixes garbage samples when uploading mixed 16 & 8 bit samples.
  • Fixes music players/trackers: Open Cubic Player (with gusFastUpload=on), Fast Tracker 2

A few notes:
I do pretty much all of my development testing on a Pentium 133, but I tested a bit more my Am486DX2-80 this time, and I noticed that Hocus Pocus runs a lot better on it – I can play the game for several minutes, instead of having it lock up on the title screen when the first sound effect is played. I'm curious how it performs for others.

I mentioned that Descent crashes in my previous post, but it also crashes with my real GUS, and on both my Pentium and 486 systems. And it only locks up when one note in one particular song in the soundtrack plays... I kind of wonder if that file is corrupted. I had been testing by loading a saved game, and that level's music caused the crash. Loading a different saved game on a different level runs just fine. I played for about 45 minutes without a problem.

One more thing: Most but not all games will let you configure one card for sound effects and another for music. If you have the DMA and IRQ to spare in your system, using a separate SB-compatible sound card for sound effects instead of the PicoGUS will result in a much better experience! That way the PicoGUS can focus on what it's really good at: GUS wavetable music playback. 😀

Respect @polpo

polpo wrote on 2023-01-30, 04:18:

PicoGUS firmware v0.4.0 is now released: https://github.com/polpo/picogus/releases/tag/v0.4.0 […]
Show full quote

PicoGUS firmware v0.4.0 is now released: https://github.com/polpo/picogus/releases/tag/v0.4.0

This includes the GUS DMA fixes I mentioned in my last post:

• Refactored DMA transfer completion handler: this results in much higher compatibility with titles that use streaming DMA. Overriding the DMA transfer interval is not necessary in most circumstances now.
  • Fixes games: Quake, Doom (and Doom engine games), Duke3D, Descent, Hocus Pocus (partially); Demo: Inside
• Fixed bug where DMA control register was not properly reset between transfers. Fixes garbage samples when uploading mixed 16 & 8 bit samples.
  • Fixes music players/trackers: Open Cubic Player (with gusFastUpload=on), Fast Tracker 2

A few notes:
I do pretty much all of my development testing on a Pentium 133, but I tested a bit more my Am486DX2-80 this time, and I noticed that Hocus Pocus runs a lot better on it – I can play the game for several minutes, instead of having it lock up on the title screen when the first sound effect is played. I'm curious how it performs for others.

I mentioned that Descent crashes in my previous post, but it also crashes with my real GUS, and on both my Pentium and 486 systems. And it only locks up when one note in one particular song in the soundtrack plays... I kind of wonder if that file is corrupted. I had been testing by loading a saved game, and that level's music caused the crash. Loading a different saved game on a different level runs just fine. I played for about 45 minutes without a problem.

One more thing: Most but not all games will let you configure one card for sound effects and another for music. If you have the DMA and IRQ to spare in your system, using a separate SB-compatible sound card for sound effects instead of the PicoGUS will result in a much better experience! That way the PicoGUS can focus on what it's really good at: GUS wavetable music playback. 😀

Awesome thanks a lot. I put 0.4.0 on my card for a quick tryout. Seems great, no unexpected issues. It's a luxury to be able to conveniently flash the card in the machine since 0.3.0, I must say.

Doom 1 seems basically perfect to my ears now, and I thought I saw incremental improvement in a few other games I tried too. Well done for continuing to creatively find ways forward. I wish I could help with the coding but it's beyond my pay grade for now. However if there are any more-menial aspects with which you could use help or contribution, then do let us know.

Would it be possible for the pgusinit program to accommodate more than one physical PicoGUS card in the same machine? Like if the first was flashed as GUS and the second as MPU.

Oh yeah, and I quickly tried out Hocus Pocus, but it seems No Bueno on my Pentium-MMX 233Mhz machine - hard system freeze within seconds of the digital sound beginning to play on the title screen. I'll sub in my K6 system later, to see if that makes a difference, as I have that machine set up for more underclocking flexibility.

On a quick first try: indeed, looks (and sounds) like really good progress again - that's truly awesome!

What I found, quickly starting a few games:
Doom2: first level plays nicely, but after e.g. jumping to e2m2 (>idclev 22), the music and sound effects get distorted (sounds like clipping to me) and stay that way until doom2 is restarted.
FastDoom: starting and jumping levels seems to work pretty well now.
cubic player (2.6-pre): started out playing, but restarting the same (some tiny chiptune) file resulted in a crash. Other starts also often crashed - I'll have to try other versions and verify the settings in the cp.ini , though.

I definitely also need to try a few more configs (e.g. without memory manager, etc.) and maybe another system to see if there's anything relating to that. But that sadly needs to wait for another day.

Descent also seemed to run pretty great over here (i486DX2-66). Which music / level gave you trouble there? I jumped into a few levels via 'gabbagabbahey + famerjoe X', which all seemed ok.