It was more that the lack of direct DMA made me hold off the v3 update. My ULTRASND variable is ULTRASND=220,1,1,5,5 so pretty standard. 2.2.0 only works if I explicitly specify the value with the command line options.

Edit: is maybe the step from 2.1.0 to 3.2.0 too big and do I need some sort of hard reset of the PicoGUS?

@Polpo FastDoom also supports SB direct DAC mode

NeoG_ wrote on 2025-08-08, 06:41:

copymaker wrote on 2025-08-05, 09:35:

Since PicoGUS emulates SB2.0, it’s probably free from the single-cycle DMA clicking bug. Does anyone know for sure?

Day of the Tentcale is notorious for single cycle DMA clicking on SB16s, I couldn't detect any pops or clicks using the PicoGUS, other than the typical hashiness of 8-bit low res samples.

Really appreciate you checking on that.

digistorm wrote on 2025-08-10, 17:01:

It was more that the lack of direct DMA made me hold off the v3 update. My ULTRASND variable is ULTRASND=220,1,1,5,5 so pretty standard. 2.2.0 only works if I explicitly specify the value with the command line options.

Edit: is maybe the step from 2.1.0 to 3.2.0 too big and do I need some sort of hard reset of the PicoGUS?

Up until now when you updated the firmware the ports would revert to their defatult which is 240 for GUS mode, it will complain about the ULTRASND variable unless you run /gusport 220 /save again. Since the IRQ and DMA are hardware jumpers it doesn't check for those.

I must have misremembered that it would always follow the ULTRASND variable if present. It has been a while since I swapped it between systems (my other DOS PC had the PicoGUS at 240).
But I was confused, because 2.1.0 defaults to 220, 2.2.0 defaults to 240 appearently, and 3.2.0 defaults to 220 again.

@Polpo
I retested firmware 2.1.0, 2.2.0 and 3.2.0 and on the current system it is in (Athlon 600 on AMD Irongate chipset) because I really messed up last time.
I got these results:

2.1.0
Scream Tracker 3 works
Impulse Tracker works with command IT s3
Crystal Dream works

2.2.0
Scream Tracker 3 works
Impulse Tracker works with command IT s3
Crystal Dream does not work (could not find output device) so this regresses possibly as early as 2.2.0

3.2.0
Scream Tracker 3 autodetects PicoGUS as Sound Blaster but on start of playback it hangs at the first row (with no sound). After this, the PicoGUS is no longer detected by PGUSINIT so something definitely goes wrong here. Reboot fixes it.
Impulse Tracker with command IT s3 works.
Crystal Dream does not work, same as 2.2.0.

Fast Doom in Direct DMA mode works on all firmwares (so this was a big red herring, sorry about that).

Hi guys need some advice, i have a picogus, PC 286, usb mode, only one cue/bin (megarace) in pendrive, load cdrom driver cdmke.sys OK, assign unit ok, if I run pgusinit.exe even say megarace.cue is loaded

But if i do cdlist or cdload i get a timeout

I tried different cue/bin and ISO images and pendrives, 512mb, 1GB, 4 and 8GB, multiple brands, all FAT32, same problem.

Im out of ideas! thanks for any help

digistorm wrote on 2025-08-15, 10:12:

But I was confused, because 2.1.0 defaults to 220, 2.2.0 defaults to 240 appearently, and 3.2.0 defaults to 220 again.

3.2.0 now keeps your defined ports during upgrade, so it retained the existing 220 setting if you upgraded directly from 2.1.0 to 3.2.0

digistorm wrote on 2025-08-15, 10:12:

Crystal Dream does not work (could not find output device) so this regresses possibly as early as 2.2.0

Crystal Dream is speed sensitive, it will show that error if the system is too fast and SB is selected. There may be a quirk in earlier firmware that allows it to work on faster systems but the later behaviour matches what you get on SB compatible hardware of the time. In my opinion the real solution is to slow down the system.

digistorm wrote on 2025-08-15, 10:12:

Scream Tracker 3 autodetects PicoGUS as Sound Blaster but on start of playback it hangs at the first row (with no sound). After this, the PicoGUS is no longer detected by PGUSINIT so something definitely goes wrong here. Reboot fixes it.

The autodetection routines can sometimes lead to incorrect settings used for the sound card. Try run it with hardcoded switches for the card address and type EG "ST3 -S1 -A220 -I5 -C1" (replace the Port (A), IRQ (I) and DMA (C) with your settings). I was able to use ScreamTracker 3 in both SB and GUS mode without issues.

NeoG_ wrote on Yesterday, 01:51:

3.2.0 now keeps your defined ports during upgrade, so it retained the existing 220 setting if you upgraded directly from 2.1.0 to 3.2.0

Okay, I didn't know that. Development is going quite fast at the moment so I have missed that.

NeoG_ wrote on Yesterday, 01:51:

Crystal Dream is speed sensitive, it will show that error if the system is too fast and SB is selected. There may be a quirk in earlier firmware that allows it to work on faster systems but the later behaviour matches what you get on SB compatible hardware of the time. In my opinion the real solution is to slow down the system.

Aha! So that is why I had a batch file in that directory to disable the L1 cache. 🤣 I did that right now and indeed it works.

NeoG_ wrote on Yesterday, 01:51:

The autodetection routines can sometimes lead to incorrect settings used for the sound card. Try run it with hardcoded switches for the card address and type EG "ST3 -S1 -A220 -I5 -C1" (replace the Port (A), IRQ (I) and DMA (C) with your settings). I was able to use ScreamTracker 3 in both SB and GUS mode without issues.

Autodetection works as expected, it detects the correct values without parameters. But with or without, it crashes as soon as I press F5 to start playback. I tried with or without L1 cache enables, with and without EMS. Previous generation firmware did work, as I described.
GUS works fine with ST3 though.

digistorm wrote on Yesterday, 08:07:

Autodetection works as expected, it detects the correct values without parameters. But with or without, it crashes as soon as I press F5 to start playback. I tried with or without L1 cache enables, with and without EMS. Previous generation firmware did work, as I described.
GUS works fine with ST3 though.

I was able to replicate this, it appears to be a regression from 3.1.0 -> 3.2.0 with the SB DSP rewrite

My system doesn't freeze so I can exit the program, but the PicoGUS locks up as soon as any audio is sent to the card and needs to be reset, which is the same as you observed