picmaster wrote on 2025-10-20, 18:22:

Found one interesting issue - there are .ISO files where root catalog is read but you can't access neither files nor directories […]
Show full quote

Found one interesting issue - there are .ISO files where root catalog is read but you can't access neither files nor directories there. And what's very noticeable is the letter's case - filenames have mixed case, not uppercase-only. These are the ISOs:

https://cdimage.debian.org/mirror/cdimage/arc … usinesscard.iso
https://cdimage.debian.org/mirror/cdimage/arc … 386-netinst.iso
(The installation disks also behave the same, but they need jigdo-lite for downloading and I suppose no-one will care)

...

My setup: PicoGUS HW v2.0, firmware v3.7.1, DOS 6.22

Just to be very clear - this is not a heart-breaking issue for me. Just noticed and reported it, in the name of the common good.

I suppose the question is whether they are incompatible with the PicoGUS emulation or with DOS 6.22, the images were made in 2008 and may use features beyond DOS 6.22's capabilities (EG not including 8dot3 backwards compatibility). Did you try a physical drive to see if the images work correctly?

NeoG_ wrote on 2025-10-20, 21:15:

I suppose the question is whether they are incompatible with the PicoGUS emulation or with DOS 6.22, the images were made in 2008 and may use features beyond DOS 6.22's capabilities (EG not including 8dot3 backwards compatibility)

Well, I'm also not excluding cdmke.sys and mscdex.exe from having some related limitations as well. It's a fact that PicGUS is flexible and allows some new unexpected ways to experiment with our retro-systems, and that's when we find these strange behaviors, where the PicoGUS is hardly to be held responsible for these issues.

NeoG_ wrote on 2025-10-20, 21:15:

Did you try a physical drive to see if the images work correctly?

I don't have a Panasonic MKE drive in order to properly reproduce the test case. And also, believe it or not, in my junk pile I don't have a working multi I/O controller to test with IDE cdrom. Damn...

Btw, I tested the same ISO on several virt-manager VMs (debian 12, winxp, win10) and it behaves properly. So maybe the issue is either somewhere in mke driver, mscdex or maybe even the ISO could be generated with improper filename compliance level (e.g. other than Level 1). Maybe I can try same test with DOS 7.1.

Btw, I forgot to say - overall the cdrom emulation is pretty neat, most of the things I tried worked quite well, and PicoGUS is a treasure for some cool experiments!

picmaster wrote on 2025-10-21, 20:25:

I don't have a Panasonic MKE drive in order to properly reproduce the test case. And also, believe it or not, in my junk pile I don't have a working multi I/O controller to test with IDE cdrom. Damn...

I burned the businesscard iso to a physical disc and tried to read it in my 98SE machine using an IDE drive. The disc reads correctly in windows, but in MS-DOS mode (DOS 7) none of the files can be accessed in the same way you experienced.

Just to follow up on my issue with cracking/popping GUS/SB playback... received a new PicoGUS today and it's the same issue... shall I just assume it's not compatible with VIA Apollo Pro 133 chipset?

wargrip wrote on 2025-10-22, 14:24:

Just to follow up on my issue with cracking/popping GUS/SB playback... received a new PicoGUS today and it's the same issue... shall I just assume it's not compatible with VIA Apollo Pro 133 chipset?

Plot twist: works fine in XT-Player in GUS mode but Open Cubic Player sounds horrible (volume too low and has the pops/crackles). Maybe I've just been testing it with the wrong thing? Should OCP work with PicoGUS and XM files?

Also Rise of the Triad sounds terrible.

wargrip wrote on 2025-10-22, 15:26:

wargrip wrote on 2025-10-22, 14:24:

Just to follow up on my issue with cracking/popping GUS/SB playback... received a new PicoGUS today and it's the same issue... shall I just assume it's not compatible with VIA Apollo Pro 133 chipset?

Plot twist: works fine in XT-Player in GUS mode but Open Cubic Player sounds horrible (volume too low and has the pops/crackles). Maybe I've just been testing it with the wrong thing? Should OCP work with PicoGUS and XM files?

Also Rise of the Triad sounds terrible.

So it seems the faulty DAC theory is off the table

Part of the issue is likely going to be that you are using it on an extremely fast system (relative to the time of the GUS/SB), all sorts of speed sensitivity issues are going to come up. Does your motherboard allow you to adjust the AT/ISA bus speed? It should be at or under 8Mhz to be safe.

Also did you assign the IRQ and DMA used by the card in the BIOS settings? To make sure they are assigned to the ISA bus and not double-assigned to another device by PnP/ACPI

NeoG_ wrote on 2025-10-23, 01:20:

So it seems the faulty DAC theory is off the table […]
Show full quote

wargrip wrote on 2025-10-22, 15:26:

wargrip wrote on 2025-10-22, 14:24:

Just to follow up on my issue with cracking/popping GUS/SB playback... received a new PicoGUS today and it's the same issue... shall I just assume it's not compatible with VIA Apollo Pro 133 chipset?

Plot twist: works fine in XT-Player in GUS mode but Open Cubic Player sounds horrible (volume too low and has the pops/crackles). Maybe I've just been testing it with the wrong thing? Should OCP work with PicoGUS and XM files?

Also Rise of the Triad sounds terrible.

So it seems the faulty DAC theory is off the table

Part of the issue is likely going to be that you are using it on an extremely fast system (relative to the time of the GUS/SB), all sorts of speed sensitivity issues are going to come up. Does your motherboard allow you to adjust the AT/ISA bus speed? It should be at or under 8Mhz to be safe.

Also did you assign the IRQ and DMA used by the card in the BIOS settings? To make sure they are assigned to the ISA bus and not double-assigned to another device by PnP/ACPI

Just thought I would give a quick update - OCP uses the software based mixer by default which causes the issues I experienced when using that player - now that I use the GusMixer it has gone away.

The issues I have with Rise of the Triad remain but I am thinking now that it's Gus support maybe isn't great. I really need to try a few other Gus games that are officially supported.

I also think you are right that my P3 is just a bit too fast, generally speaking - there isn't a nice way to slow it down so might go down to a slower pc at some point.

Thanks to everyone for their help!

wargrip wrote on 2025-10-24, 23:03:

The issues I have with Rise of the Triad remain but I am thinking now that it's Gus support maybe isn't great. I really need to try a few other Gus games that are officially supported.

For me, Rise of the Triad produces clean sound but it completely locks up the system after 1 minute so.. maybe that's true. It works perfectly in SB mode but you lose stereo F/X on the PicoGUS.

wargrip wrote on 2025-10-22, 15:26:

Plot twist: works fine in XT-Player in GUS mode but Open Cubic Player sounds horrible (volume too low and has the pops/crackles). Maybe I've just been testing it with the wrong thing? Should OCP work with PicoGUS and XM files?

Did you use devpGUS or devwGUS? I guess the latter (using the wavetable engine) should work fine, with limitations of course. The former is needed for streaming formats (and mods w/ software mixing as they are just streams from the sound card's perspective, making it work somewhat like an SB) and uses continuous DMA transfer thus it can be more easily affected by ISA timing issues. I have no experience w/ PicoGUS, only the real thing but I found it more prone to DMA errors than to wavetable problems which only use relatively few port operations and no DMA, even IRQs are optional this way.

I tried out Wolfenstein 3D with the 1993 UltraWolf 1.31 patch today, It's a great showcase for the Ultrasound and PicoGUS. It upgrades the sound engine to use the GUS hardware mixer with 14 channels, accurate stereo panning and distance falloff.

The only caveat is that for the "full fat" experience it also requires an AdLib or Sound Blaster with FM in parallel the GUS which the PicoGUS can't do by itself

I just got a PicoGUS from Serdashop, and I think it may be slightly defective. Everything works, except for when I put it in GUS mode, it gives the error "In GUS mode but no ULTRASND variable set or is malformed!". I'm confident it's not a config issue - I actually have a second PicoGUS that I got over a year ago that works perfectly when I swap it in. I've reflashed the firmware, messed with DMA bios settings, and tried it in a second system; same results.

Everything else works, so it's still a pretty useful card, but still disappointing.

ubiq wrote on 2025-10-31, 20:50:

I just got a PicoGUS from Serdashop, and I think it may be slightly defective. Everything works, except for when I put it in GUS mode, it gives the error "In GUS mode but no ULTRASND variable set or is malformed!". I'm confident it's not a config issue - I actually have a second PicoGUS that I got over a year ago that works perfectly when I swap it in. I've reflashed the firmware, messed with DMA bios settings, and tried it in a second system; same results.

Everything else works, so it's still a pretty useful card, but still disappointing.

That message shows when the pgusinit program can't match the GUS port the card has been told to run on to the environment variable, it should be cleared by running the commands;

pgusinit /mode gus
pgusinit /gusport 240
pgusinit /save

After rebooting it should pull the correct GUS port from flash config. If the message still shows and there's a second card that works with the same flash config and firmware version, it seems that somehow the pgusinit program can't read the active GUS port from the card. It would be a strange failure mode where that is the only thing that doesn't work, but stranger things have happened.

NeoG_ wrote on 2025-10-31, 22:05:

That message shows when the pgusinit program can't match the GUS port the card has been told to run on to the environment variab […]
Show full quote

ubiq wrote on 2025-10-31, 20:50:

I just got a PicoGUS from Serdashop, and I think it may be slightly defective. Everything works, except for when I put it in GUS mode, it gives the error "In GUS mode but no ULTRASND variable set or is malformed!". I'm confident it's not a config issue - I actually have a second PicoGUS that I got over a year ago that works perfectly when I swap it in. I've reflashed the firmware, messed with DMA bios settings, and tried it in a second system; same results.

Everything else works, so it's still a pretty useful card, but still disappointing.

That message shows when the pgusinit program can't match the GUS port the card has been told to run on to the environment variable, it should be cleared by running the commands;

pgusinit /mode gus
pgusinit /gusport 240
pgusinit /save

After rebooting it should pull the correct GUS port from flash config. If the message still shows and there's a second card that works with the same flash config and firmware version, it seems that somehow the pgusinit program can't read the active GUS port from the card. It would be a strange failure mode where that is the only thing that doesn't work, but stranger things have happened.

Aha, I had played around with the /gusport setting but didn't know to use /save with it. At some point I must have saved it with 220 without realizing it.

Now, it is giving the error "Card not responding to GUS commands on port 240" - which is actually the original error I got with the card, and what sent me down the troubleshooting rabbit hole in the first place.

ubiq wrote on 2025-11-01, 00:08:

NeoG_ wrote on 2025-10-31, 22:05:

That message shows when the pgusinit program can't match the GUS port the card has been told to run on to the environment variab […]
Show full quote

ubiq wrote on 2025-10-31, 20:50:

I just got a PicoGUS from Serdashop, and I think it may be slightly defective. Everything works, except for when I put it in GUS mode, it gives the error "In GUS mode but no ULTRASND variable set or is malformed!". I'm confident it's not a config issue - I actually have a second PicoGUS that I got over a year ago that works perfectly when I swap it in. I've reflashed the firmware, messed with DMA bios settings, and tried it in a second system; same results.

Everything else works, so it's still a pretty useful card, but still disappointing.

That message shows when the pgusinit program can't match the GUS port the card has been told to run on to the environment variable, it should be cleared by running the commands;

pgusinit /mode gus
pgusinit /gusport 240
pgusinit /save

After rebooting it should pull the correct GUS port from flash config. If the message still shows and there's a second card that works with the same flash config and firmware version, it seems that somehow the pgusinit program can't read the active GUS port from the card. It would be a strange failure mode where that is the only thing that doesn't work, but stranger things have happened.

Aha, I had played around with the /gusport setting but didn't know to use /save with it. At some point I must have saved it with 220 without realizing it.

Now, it is giving the error "Card not responding to GUS commands on port 240" - which is actually the original error I got with the card, and what sent me down the troubleshooting rabbit hole in the first place.

I also got this error when I put the PicoGUS card alongside an SB16/SCSI-2 card, for some reason the SB16 is blocking port 240 even though none of the resources on the card are set to that address. I don't know how common it is but it seems it's possible for some standard addresses to just not work in some hardware configurations. I moved the gusport and ULTRASND to 210 (and saved to flash of course) and it was OK after that.

NeoG_ wrote on 2025-11-01, 00:59:

ubiq wrote on 2025-11-01, 00:08:

NeoG_ wrote on 2025-10-31, 22:05:

That message shows when the pgusinit program can't match the GUS port the card has been told to run on to the environment variab […]
Show full quote

That message shows when the pgusinit program can't match the GUS port the card has been told to run on to the environment variable, it should be cleared by running the commands;

pgusinit /mode gus
pgusinit /gusport 240
pgusinit /save

After rebooting it should pull the correct GUS port from flash config. If the message still shows and there's a second card that works with the same flash config and firmware version, it seems that somehow the pgusinit program can't read the active GUS port from the card. It would be a strange failure mode where that is the only thing that doesn't work, but stranger things have happened.

Aha, I had played around with the /gusport setting but didn't know to use /save with it. At some point I must have saved it with 220 without realizing it.

Now, it is giving the error "Card not responding to GUS commands on port 240" - which is actually the original error I got with the card, and what sent me down the troubleshooting rabbit hole in the first place.

I also got this error when I put the PicoGUS card alongside an SB16/SCSI-2 card, for some reason the SB16 is blocking port 240 even though none of the resources on the card are set to that address. I don't know how common it is but it seems it's possible for some standard addresses to just not work in some hardware configurations. I moved the gusport and ULTRASND to 210 (and saved to flash of course) and it was OK after that.

Nope - currently testing it in a barebones setup on my bench, no other cards. I tried 210 just for the heck of it and no dice.

@ubiq - Is it possible that your ISA clock exceeds 8.33 MHz? Can you measure it to confirm, as sometimes BIOS settings don't work properly (or at all).

picmaster wrote on 2025-11-01, 02:13:

@ubiq - Is it possible that your ISA clock exceeds 8.33 MHz? Can you measure it to confirm, as sometimes BIOS settings don't work properly (or at all).

Just measured it right from the slot - pretty much bang on.

Figured out the issue with my PicoGUS:

Either I just didn't notice first several times I closely examined the card, or the IC was damaged but still hanging together at first.

Anyway, Serge at Serdaco has been excellent and a replacement card is already on the way.

ubiq wrote on 2025-11-05, 01:58:

Figured out the issue with my PicoGUS

Either I just didn't notice first several times I closely examined the card, or the IC was damaged but still hanging together at first.

Anyway, Serge at Serdaco has been excellent and a replacement card is already on the way.

Good catch, that is disappointing but also a relief