Geriatric Danmaku wrote on 2026-09-05, 21:34:

Not yet getting Gameport support in Windows 95. It could be a Windows 95 corruption issue. After following alot of general advice, and not making enough progress...

The auto detection will probably not work, try manually adding a standard gameport using the add hardware wizard (usually filed under Microsoft in the driver list)

MONEY! We got this! It was all about setting the Windows gameport to port 201h. No Windows reinstall needed.

Now looking at the Windows games which work with current Sound Blaster emulation. Not all of them are working. But some of them are. More to come.

NeoG_ wrote on 2026-09-05, 22:40:

Geriatric Danmaku wrote on 2026-09-05, 21:34:

Not yet getting Gameport support in Windows 95. It could be a Windows 95 corruption issue. After following alot of general advice, and not making enough progress...

The auto detection will probably not work, try manually adding a standard gameport using the add hardware wizard (usually filed under Microsoft in the driver list)

Geriatric Danmaku wrote on 2026-09-05, 14:54:

What are some good games to try out CMS Sound?

Silpheed, Space Quest 3, King's Quest 4

There is a very good retroclone of pacman that has CMS sound..

Budokan: The Martial Spirit

Geriatric Danmaku wrote on 2026-09-07, 05:58:

Now looking at the Windows games which work with current Sound Blaster emulation. Not all of them are working. But some of them are. More to come.

Since you inherited an existing SB16 configuration onto the PicoGUS, there is one specific thing that needs to be changed - The PicoGUS is an 8-bit card and is not capable of using high DMAs. Your existing SB16 was more than likely configured to use a separate low and high DMA as is normal for SB16 except for specific scenarios.

The hardware resources would need to be adjusted so that the low and high DMA are the same. Some DOS games won't let you use these settings and only give you the option for the High DMA being 5, 6 or 7 (for example Duke 3D), those need to be dealt with on a case by case basis by manually editing the game's config file.

No worries on this one NeoG... Found that discussion a few months ago, and made the adjustment.

It may have been too much to ask for all Windows 95 games to work with SB Emulation. Here's my results so far:
Balls of Steel and similar pinball: YES
Get Medival: YES
NASCAR Racing 1999: NO
Starcraft: NO
Diablo: NO

There was some talk a few months ago about covering Windows with.... Windows Sound System emulation. That sounds pretty awesome. What's the latest news there?

PicoGUS SB output is SUPER CLEAN. It's going to be hard to go back to the supplemental noise of the real SB 16.

PicoGUS Joystick emulation is not working while the real GUS is installed.

Has anybody tried out a real era soundcard WITH PicoGUS installed, and had the Joystick emulation work? Which card?

NeoG_ wrote on 2026-09-10, 02:17:

Geriatric Danmaku wrote on 2026-09-07, 05:58:

Now looking at the Windows games which work with current Sound Blaster emulation. Not all of them are working. But some of them are. More to come.

Since you inherited an existing SB16 configuration onto the PicoGUS, there is one specific thing that needs to be changed - The PicoGUS is an 8-bit card and is not capable of using high DMAs. Your existing SB16 was more than likely configured to use a separate low and high DMA as is normal for SB16 except for specific scenarios.

The hardware resources would need to be adjusted so that the low and high DMA are the same. Some DOS games won't let you use these settings and only give you the option for the High DMA being 5, 6 or 7 (for example Duke 3D), those need to be dealt with on a case by case basis by manually editing the game's config file.

Geriatric Danmaku wrote on 2026-09-11, 01:21:

NASCAR Racing 1999: NO
Starcraft: NO
Diablo: NO

I'm surprised by these because they are windows games and windows should abstract the sound device for pretty much all software, I assume they were all working with the original SB16 card?

Geriatric Danmaku wrote on 2026-09-11, 01:21:

PicoGUS Joystick emulation is not working while the real GUS is installed.

Has anybody tried out a real era soundcard WITH PicoGUS installed, and had the Joystick emulation work? Which card?

I have an SB16 and PicoGUS (I want the hardware OPL still, PicoGUS OPL3 is probably 95% there. Plus I use the 15pin joystick port). I have to remove the JYEN jumper on the SB16 card for the PicoGUS joystick emulation to work. See if your GUS card has a similar jumper. Otherwise the GUS and the PicoGUS will conflict on port 201.

NeoG_ wrote on 2026-09-11, 01:41:

Geriatric Danmaku wrote on 2026-09-11, 01:21:

NASCAR Racing 1999: NO
Starcraft: NO
Diablo: NO

I'm surprised by these because they are windows games and windows should abstract the sound device for pretty much all software, I assume they were all working with the original SB16 card?

IIRC Windows drivers for Creative SB are not 100% compatible with third party implementations. It's entirely possible for something different from official Creative SB implementation to break certain driver functionalities.

I think standard wave output of lower sample rates and bit widths should be very likely to work regardless of HW implementation, but there's a high chance that FM and/or MIDI will not work requiring hardware-specific initialization routines that official Creative SB drivers cannot handle.

I wonder if some Windows Games only ask for 8-bit playback support? Balls of Steel, the other Wildfire pinball games, and Get Medival, do sound like they could be limited to 8 bit quality. Maybe games which ask for real 16 bit support from a Sound Blaster have to have the 16 bit High DMA?

DOS GUS Demo Support on PicoGUS is awesome. Sound quality is just a touch better than the real GUS. And very few mistakes.

DOS Game support? Great for the Native GUS support games. You know the ones. Epic / Extreme Pinball, OMF2097, Jazz Jackrabbit, etc...

For others it's been best to go with the SB + MIDI support over GUS.

NASCAR Racing 1999 DOS version is awesome with PicoGUS. Sounds fine in SB mode, and the controller support is huge!

DOS SB Demo support is hit & miss. Some miss by alot.

And.. I don't mind when PicoGUS is just a bit off with the FM implementation. I used SBOS. Seriously! I know what REALLY mangled FM implementation sounds like! PicoGUS FM is just fine.

LSS10999 wrote on 2026-09-11, 03:27:

NeoG_ wrote on 2026-09-11, 01:41:

Geriatric Danmaku wrote on 2026-09-11, 01:21:

NASCAR Racing 1999: NO
Starcraft: NO
Diablo: NO

I'm surprised by these because they are windows games and windows should abstract the sound device for pretty much all software, I assume they were all working with the original SB16 card?

IIRC Windows drivers for Creative SB are not 100% compatible with third party implementations. It's entirely possible for something different from official Creative SB implementation to break certain driver functionalities.

I think standard wave output of lower sample rates and bit widths should be very likely to work regardless of HW implementation, but there's a high chance that FM and/or MIDI will not work requiring hardware-specific initialization routines that official Creative SB drivers cannot handle.

Geriatric Danmaku wrote on 2026-09-15, 02:51:

I wonder if some Windows Games only ask for 8-bit playback support? Balls of Steel, the other Wildfire pinball games, and Get M […]
Show full quote

I wonder if some Windows Games only ask for 8-bit playback support? Balls of Steel, the other Wildfire pinball games, and Get Medival, do sound like they could be limited to 8 bit quality. Maybe games which ask for real 16 bit support from a Sound Blaster have to have the 16 bit High DMA?

DOS GUS Demo Support on PicoGUS is awesome. Sound quality is just a touch better than the real GUS. And very few mistakes.

DOS Game support? Great for the Native GUS support games. You know the ones. Epic / Extreme Pinball, OMF2097, Jazz Jackrabbit, etc...

For others it's been best to go with the SB + MIDI support over GUS.

NASCAR Racing 1999 DOS version is awesome with PicoGUS. Sounds fine in SB mode, and the controller support is huge!

DOS SB Demo support is hit & miss. Some miss by alot.

And.. I don't mind when PicoGUS is just a bit off with the FM implementation. I used SBOS. Seriously! I know what REALLY mangled FM implementation sounds like! PicoGUS FM is just fine.

Normally official Creative drivers should work fine for at least Wave playback, particularly 8-bit (basic Sound Blaster compatibility). Anything further may be a hit or miss for non-Creative cards, be it PicoGUS' SB emulation, or other vendors like ESS, Yamaha.

On the other hand, you need to initialize the card properly before booting to Windows. For PicoGUS this means actually configuring the card via PGUSINIT at least once, while for other PnP sound cards, initializing them with UNISOUND would suffice. After proper initialization, you may be able to use non-PnP Sound Blaster compatible drivers.

I haven't really tested PicoGUS' SB mode with Windows as I have actual SB-compatible cards for that. I'm using PicoGUS exclusively for GUS mode purposes and it seems to work okay at least with Win3.x, including MIDI (patchsets).

Geriatric Danmaku wrote on 2026-09-15, 02:51:

NASCAR Racing 1999 DOS version is awesome with PicoGUS. Sounds fine in SB mode, and the controller support is huge!

Am I mistaken or is there not actually a DOS version of NSCAR Racing 1999? Are you referring to the 1994 version?

NeoG_ wrote on 2026-09-15, 04:55:

Geriatric Danmaku wrote on 2026-09-15, 02:51:

NASCAR Racing 1999 DOS version is awesome with PicoGUS. Sounds fine in SB mode, and the controller support is huge!

Am I mistaken or is there not actually a DOS version of NSCAR Racing 1999? Are you referring to the 1994 version?

NASCAR 1 (1994), NASCAR 2 (1996), NASCAR Grand National (1997), NASCAR Truck Series (1998), NASCAR Racing 1999, all have DOS support. The 1999 version DOS executable needs 24MB RAM. Blasting way beyond "640K Barrier". There's even a DOS beta of 3DFX support for 1996, and official included release DOS 3DFX support for 1999.

Both SB and GUS work with PicoGUS. SB support is just a bit better.

LSS10999 wrote on 2026-09-15, 03:10:

Normally official Creative drivers should work fine for at least Wave playback, particularly 8-bit (basic Sound Blaster compatib […]
Show full quote

Geriatric Danmaku wrote on 2026-09-15, 02:51:

I wonder if some Windows Games only ask for 8-bit playback support? Balls of Steel, the other Wildfire pinball games, and Get M […]
Show full quote

I wonder if some Windows Games only ask for 8-bit playback support? Balls of Steel, the other Wildfire pinball games, and Get Medival, do sound like they could be limited to 8 bit quality. Maybe games which ask for real 16 bit support from a Sound Blaster have to have the 16 bit High DMA?

DOS GUS Demo Support on PicoGUS is awesome. Sound quality is just a touch better than the real GUS. And very few mistakes.

DOS Game support? Great for the Native GUS support games. You know the ones. Epic / Extreme Pinball, OMF2097, Jazz Jackrabbit, etc...

For others it's been best to go with the SB + MIDI support over GUS.

NASCAR Racing 1999 DOS version is awesome with PicoGUS. Sounds fine in SB mode, and the controller support is huge!

DOS SB Demo support is hit & miss. Some miss by alot.

And.. I don't mind when PicoGUS is just a bit off with the FM implementation. I used SBOS. Seriously! I know what REALLY mangled FM implementation sounds like! PicoGUS FM is just fine.

Normally official Creative drivers should work fine for at least Wave playback, particularly 8-bit (basic Sound Blaster compatibility). Anything further may be a hit or miss for non-Creative cards, be it PicoGUS' SB emulation, or other vendors like ESS, Yamaha.

On the other hand, you need to initialize the card properly before booting to Windows. For PicoGUS this means actually configuring the card via PGUSINIT at least once, while for other PnP sound cards, initializing them with UNISOUND would suffice. After proper initialization, you may be able to use non-PnP Sound Blaster compatible drivers.

I haven't really tested PicoGUS' SB mode with Windows as I have actual SB-compatible cards for that. I'm using PicoGUS exclusively for GUS mode purposes and it seems to work okay at least with Win3.x, including MIDI (patchsets).

No worries, I know all about using PGUSINIT.

So far, if any of my real Sound Cards are installed along with PICOGUS, I lose the Gameport - USB Gamepad feature. Once there's recon out there about a real sound card, to pair with PicoGUS, which does not take over PicoGUS gameport, I will be ready to give it try.

I am experiencing an issue with the PGUSINIT /cdload command. It usually works fine, but it randomly gets stuck—especially if I make multiple changes in a short period of time. When this happens, the CD-ROM drive appears empty. After waiting a while, if I run the command again, it works fine and load the image

Any ideas on what might be causing this bug?

Environment & Testing:
• Hardware: Tested on a 286, a 486, and a Pentium PC (the issue occurs on all of them).
• Firmware: Using the latest firmware version 4.1.1.

Thank you for your help!

theelf wrote on Today, 19:14:

I am experiencing an issue with the PGUSINIT /cdload command. It usually works fine, but it randomly gets stuck—especially if I […]
Show full quote

I am experiencing an issue with the PGUSINIT /cdload command. It usually works fine, but it randomly gets stuck—especially if I make multiple changes in a short period of time. When this happens, the CD-ROM drive appears empty. After waiting a while, if I run the command again, it works fine and load the image

Any ideas on what might be causing this bug?

Environment & Testing:
• Hardware: Tested on a 286, a 486, and a Pentium PC (the issue occurs on all of them).
• Firmware: Using the latest firmware version 4.1.1.

Thank you for your help!

If you can write down a set of disc images and timing that produces the issue, I can make a batch file to simulate the changes and see if it happens on my card as well

NeoG_ wrote on 58 minutes ago:

theelf wrote on Today, 19:14:

I am experiencing an issue with the PGUSINIT /cdload command. It usually works fine, but it randomly gets stuck—especially if I […]
Show full quote

I am experiencing an issue with the PGUSINIT /cdload command. It usually works fine, but it randomly gets stuck—especially if I make multiple changes in a short period of time. When this happens, the CD-ROM drive appears empty. After waiting a while, if I run the command again, it works fine and load the image

Any ideas on what might be causing this bug?

Environment & Testing:
• Hardware: Tested on a 286, a 486, and a Pentium PC (the issue occurs on all of them).
• Firmware: Using the latest firmware version 4.1.1.

Thank you for your help!

If you can write down a set of disc images and timing that produces the issue, I can make a batch file to simulate the changes and see if it happens on my card as well

Hi, thanks of course all my ISO have same name 0X - XXXXXX for example "01 - megarace.iso" i have somne cue/bin too, but all my test are with ISO files. Normally i wait 10-20 second for every change, but some times is just random, i have a image loaded for example "52 - VGM Files" for maybe 30minutes, and i just load "53 - NeoGeo VGM files" and i get the error empty drive, and i can just load whatever file that the error will remain, maybe 10-20 seconds later if i tried again, it work

Most of my test are in the 286, the 486/pentium PCs i need to build just for test

thanks

theelf wrote on 48 minutes ago:

Hi, thanks of course all my ISO have same name 0X - XXXXXX for example "01 - megarace.iso" i have somne cue/bin too, but all my test are with ISO files. Normally i wait 10-20 second for every change, but some times is just random, i have a image loaded for example "52 - VGM Files" for maybe 30minutes, and i just load "53 - NeoGeo VGM files" and i get the error empty drive, and i can just load whatever file that the error will remain, maybe 10-20 seconds later if i tried again, it work

Most of my test are in the 286, the 486/pentium PCs i need to build just for test

thanks

If you load 52 - VGM files and then load 53 - NeoGeo VGM files does it consistently have an issue or does it work most of the time? They key to fixing these kinds of issues is to find a way to reproduce the issue consistently, it's a needle in a haystack while it's only randomly triggered

NeoG_ wrote on 29 minutes ago:

theelf wrote on 48 minutes ago:

Hi, thanks of course all my ISO have same name 0X - XXXXXX for example "01 - megarace.iso" i have somne cue/bin too, but all my test are with ISO files. Normally i wait 10-20 second for every change, but some times is just random, i have a image loaded for example "52 - VGM Files" for maybe 30minutes, and i just load "53 - NeoGeo VGM files" and i get the error empty drive, and i can just load whatever file that the error will remain, maybe 10-20 seconds later if i tried again, it work

Most of my test are in the 286, the 486/pentium PCs i need to build just for test

thanks

If you load 52 - VGM files and then load 53 - NeoGeo VGM files does it consistently have an issue or does it work most of the time? They key to fixing these kinds of issues is to find a way to reproduce the issue consistently, it's a needle in a haystack while it's only randomly triggered

Hi NeoG_,
It is not about those two specific files, but I can give you a sequence that triggers the bug around 90% of the time. The problem is when I make multiple changes in a row.
For example, if I do this:

1. Load 02 - Indiana Jones.iso -> D: -> DIR -> Works good, I see Indy files.
2. Load 33 - Igor ukakanoia.iso -> D: -> DIR -> Works good, I see Igor files.
3. Load 44 - Megarace.iso -> D: -> DIR -> Sometimes shows Megarace, but sometimes still shows Igor files.
4. Load 12 - Day of the Tentacle.iso -> Here it almost always fails. I see the old Megarace files or I get the empty drive error.

It is very rare that the picogus survives 3 or 4 changes like this. This sequence triggers the bug 90% of the times. And sometimes, it fails on the very first change.

It feels like the firmware cache or unmount sequence or whhatever sorry i can help, gets confused after a few swaps

beside this, normally work fine if i dont swap disc much, my ISO files range from small size 50mb to 2GB the biggest, work fine all, but normally for test i use ISO images that are regular size, max 640mb

oh i add, the problem happen whatever i use different USB drives, pendrive, HDD... is not a media problem i think

90% is a lot better than random, i'll check it out later today with those ISO images