polpo wrote on 2025-05-18, 06:19:

Here is a look into the next feature I am working on - CD-ROM emulation. It emulates a Panasonic CD interface (cdmke.sys is the driver for DOS and it also works in Windows) and the speed is just over a 2x CD-ROM drive. The CD-ROM emulation currently runs in Sound Blaster mode with CD audio, SB DSP, and FM synth all mixed together. The game MechWarrior 2 has been my main test bed because of the intro FMV, which stresses data transfer and SB audio, and then in-game it has redbook CD audio with SB sound effects.
Here's a video on my Bluesky profile: https://bsky.app/profile/polpo.org/post/3lpge6jccm222

Again like most things I couldn't have done it alone: yyzkevin wrote the underlying MKE CD-rom interface emulation, and wbcbz7 got rppicomidi's mass storage speed improvements for tinyusb working well enough for me to use.

I just saw this over on github and got really excited!

Picked up a PicoGUS 2.0 a few weeks back for use in my DOS 6.22 rig, and LOVE it.

This feature will be huge IMHO. CD-ROM emulation in DOS is something so many people want. Sure, you can do it, but I've always opted for a real drive, it's just easier. Now, having that external storage option for your image emulation? It's a game changer built into an already awesome card....wicked cool!

Huge thanks to all involved!

I just want to provide an update for anyone who may also have this issue and for the creator to know about possible conflict.

My picogus is paired with a SPEA Media-FX (Ensoniq soundscape s-2000). I have disabled SB emulation on the Ensoniq card so the only thing that it does is Joystick support, Wavetable synth, and port 534 wave/sound support for games that specifically support it.

IN DOS:

When I run the picogus in SB mode, there are absolutely no issues with games like Doom and Tie Fighter.

When I run the Picogus in GUS mode, after a while games will freeze and the system locks up. Funny thing, the MPU-401 keeps running though despite the system locking up.

Also when I have the Pigogus in GUS mode, the joystick port on the Soundscape goes wonky and drifts. As soon as I put the PicoGUS in SB mode, it stops this behaviour.

The Soundscape Midi port is set to 320. I'm wondering if there is some kind of DMA or port conflict going on somewhere (possibly joystick?), but the Soundscape uses DMA 0 and the PICO Gus uses DMA 1, and the freezing happened even when I disabled the joystick port in Sndscape.ini. Seems like they're not jiving with each other somehow though. Something in the GUS mode is causing a conflict which leads to the freezing. It usually runs the game for 10 minutes before freezing. Strangely no issues at all when in SB mode.

CPU: Pentium 3 1000mhz 100fsb (socket 370 cpu on a slotkit in a Slot 1 mobo)
Mobo: ASUS P2B rev 1.10 (Intel 440bx chipset)
RAM: 512MB PC133 (2-2-2 100mhz fsb)
GPU: Voodoo 3 3000 AGP
Storage: IDE to SD card adaptor (Disabled in BIOS when I'm in DOS), 8gb IDE HDD partitioned into (x2 2gb Fat16 partitions for DOS)
OS: Dos 6.22 on IDE HDD. Win 98 SE on SD card
Optical: Generic IDE optical drive (DVD ROM)
PSU: EVGA 450watt

(My autoexec.bat has the ultrasound set as such:)
SET ULTRASND=240,1,1,5,5
SET ULTRADIR=C:\ULTRASND

Hi, i am having an issue in a 486 motherboard, picogus orange light is always on when the pc turns on and software says picogus not detected. Any ideas what means?

polpo wrote on 2025-05-18, 06:19:

Here is a look into the next feature I am working on - CD-ROM emulation. It emulates a Panasonic CD interface (cdmke.sys is the driver for DOS and it also works in Windows) and the speed is just over a 2x CD-ROM drive. The CD-ROM emulation currently runs in Sound Blaster mode with CD audio, SB DSP, and FM synth all mixed together. The game MechWarrior 2 has been my main test bed because of the intro FMV, which stresses data transfer and SB audio, and then in-game it has redbook CD audio with SB sound effects.
Here's a video on my Bluesky profile: https://bsky.app/profile/polpo.org/post/3lpge6jccm222

Again like most things I couldn't have done it alone: yyzkevin wrote the underlying MKE CD-rom interface emulation, and wbcbz7 got rppicomidi's mass storage speed improvements for tinyusb working well enough for me to use.

I really hope this is a 1.x/2.x common feature because it would be really nice to have 😀

Omarkoman wrote on 2025-05-19, 23:44:

Hi, i am having an issue in a 486 motherboard, picogus orange light is always on when the pc turns on and software says picogus not detected. Any ideas what means?

Did you try updating the firmware using the USB port?

Go here: https://github.com/polpo/picogus/releases/tag/v2.2.0 and download the 2.2.0 zip file.

Take the card out of your 486, turn on your modern PC and log into windows. With the PICOGUS in hand, Hold down the black button on the bottom of the PICOGUS while plugging the micro-usb into your PC. When the directory appears, copy/drag over "picogus.uf2" and this will update the firmware. The card will turn itself off. Give it a good 1-2 minutes (to be safe) then unplug the USB.

Re-insert PICOGUS into 486 ISA slot, turn on old PC.

If your motherboard has PCI slots Make sure you go into your bios and assign IRQs and DMA's to ISA (ie; IRQ 5 and DMA 1).

You may have to assign the specific slot the GUS is in to IRQ 5 in the bios. Make sure the pins on the card are also set to IRQ 5.

Hello, who has tried to use PicoGUS with Tandy sound in an 8088 XT-ish machine? The 8088 machine in question has a TACT80101F peripheral controller.

The PicoGUS is detected by the pgusinit utility and I use /tandy /tandyport c0 to run Tandy sound at the native 0C0H port. I can't get sound. This should work right? The TACT80101F lacks the 2nd DMA controller of later machines that should sit at 0C0H, however it does use 0C0H to toggle CPU speed. Any write to 0C0H toggles the CPU speed between high and low. Shouldn't PicoGUS tandy sound work regardless as it also receives the writes?

Motherboard in question is a Hyundai Super-16TM.

The PicoGUS is known working in my Pentium-90 machine. In that machine I can use TNDY.COM to re-direct 0C0H to 2C0h, and my test software is Space Quest 1 and Space Quest 2 AGI with the -t flag enabled to force Tandy sound. This worked perfectly in the Pentium, but in the 8088 I get silence from the same Space Quest binaries.

I tested tandy mode with my olivetti m24, 8mhz 8086.
I noticed that you have to run pgusinit twice, first set the card to tandy mode, and then run pgusinit again with parameter to set the port to c0.

Thanks! I finally noticed that pgusinit was not reporting the correct port for 0c0:

Running in Tandy 3-voice mode on port 0

I finally noticed this in the changelog for 2.2.0:

Fixes issue with setting port numbers less than 0x100 or ending in 00. This fixes common port settings like 0c0 for Tandy or 0x300 for NE2000

Looks like polpo already fixed this! After a FW upgrade, it's working now. I have no way to verify if my MB is now rapidly switching between high and low speed due to 0c0h conflict with the chipset.

Is there any information on how to improve PicoGUS' MIDI playback in Windows 3.1? While sound playback works fine there, MIDI playback using default patches feels a bit too quiet with some notes cutting off halfway for some reasons.

I'm using the driver package from here. It contains Windows 3.x drivers also.

At first there were some caveats that need to be paid attention to, which is mentioned in this guide, like having to manually copying the driver files to the SYSTEM folder before installing the driver from "Drivers -> Add -> Unlisted or updated driver" (or it'll complain about the driver being "missing").

As I never owned an actual GUS I'm not sure how to set up the IRQ/DMA as PicoGUS uses only one IRQ and DMA but the configuration has two. It seems setting both GF1 and MIDI IRQs to the one I set the jumpers to (same for the two DMA channels also) will make the driver work as expected.

The "MIXER.EXE" says the MIDI volume was originally set to 90% while WAVE volume is 100%. Setting MIDI volume to 100% only slightly improved volume of some quieter instruments but the overall volume of MIDI playback is still too quiet compared to Wave/PCM playback. Again, as I never owned an actual GUS I don't know how MIDI playback was like on real GUS hardware with Windows 3.1.

I think I figured out why my PC kept freezing when using the GUS. I noticed the behavior even in SB mode, and I noticed when this occured the doom save file was corrupted. I decided to test my storage. I have dos installed on an old 8gb HDD from 1999 that sat in a closet for many years. I tried running DOS on my SD to ide card and it didn't freeze. I've since ordered a new SD to ide adaptor with a 4gb 80mb/s SD card. Hopefully this solved it. I love the picoGUS, the sound quality is so good.

Full CDROM emulation is very welcome feature.

polpo, so with both potential new features requiring more oomph - SBPro/OPL3 and 2x CDROM emu - I'm wondering if you are still considering Pi Pico 2 version?

Low cost CD-ROM emulation for DOS with audio support is certainly an exciting prospect. I have just been burning discs so far to retain the CD audio soundtrack in DOS games. Also the fact that it uses a USB drive instead of taking up space on the internal drive is a huge bonus.

Interesting that you are using Mechwarrior 2 as a test bench, the intro video does seem quite sensitive to drive stability. It stutters if I have my creative CD drive in turbo mode due to speed changes but runs smoothly in slow mode.

Updated my v1.1 card FW from 2.0.0 to 2.2.0 last night, everything went perfect and it works flawlessly.

Now I'm considering building a second one, with a Pico W because I want easy wireless networking in my daily Cx5x86 PC 😀

EDIT: My 2nd PicoGUS v1.2 actually works fine. The problem was the board environment (ASUS P8B75-M) that I'm using for testing dISAppointment.

Tested this on another AIMB-865 board of mine and the card works fine after initializing it in GUS mode. GUSDRAM tests pass there as well.

LATE EDIT 2: Found a program called GUSTEST which has its source code included. Looks like I've found the likely reason behind the issues after reading it -- The GUS actually has a few registers placed at least 0x100 away from base address, including DRAM I/O which is at offset 0x107 (that would be 0x347 if base address is 0x240). So with dISAppointment, need to forward a bit more than usual MIDI stuffs (e.g. 0x330-0x333) for 0x300-0x37F range while avoiding other stuffs such as LPT which usually resides in 0x378.

A question, as I'm struggling to figure out what might be wrong with my 2nd PicoGUS v1.2 assembly.

For some reasons, that card works without any issue in SB mode, but when in GUS mode, it could not detect any valid RAM.
- GUSDRAM reports all banks BAD. ULTRAMID would refuse to load citing no memory available, and if I try launching ULTRAMID a second time, the system would freeze or, if JEMM loaded, keep generating exception messages.

I inspected the soldering with a magnifier but could not find anything problematic. I suspected the PSRAM chip may be faulty so I replaced it with another one, but no difference.

I wonder what might be causing the issue, as from the schematic it's just some GPIOs used by Pico for SPI connecting to the PSRAM... I'm using v2.2.0 firmware, and I don't have a spare Pico at the moment...

UPDATE: Got myself another Pico and no avail. Same issue. The card still can only work in SB mode. GUS is no-go. When running pgusinit without any argument it simply says the card is not responding to GUS commands on port 240. I wonder if something's wrong with that particular PCB, as my first build worked correctly in GUS mode.

appiah4 wrote on 2025-05-20, 10:38:

I really hope this is a 1.x/2.x common feature because it would be really nice to have 😀

Yes, on the 1.x boards you'll need a micro USB B to USB A OTG adapter, just like for joystick/mouse support. On the v1.1 you'll either need an adapter that injects power or connect a couple pins, or on the v1.2 board, connect the USBPWR jumper.

vutt wrote on 2025-05-28, 20:07:

Full CDROM emulation is very welcome feature.

polpo, so with both potential new features requiring more oomph - SBPro/OPL3 and 2x CDROM emu - I'm wondering if you are still considering Pi Pico 2 version?

Yes, eventually, but I am wanting to get as much as possible out of the RP2040 for now. CDROM+OPL2+SB is really pushing the limit. I have a branch on the PicoGUS GitHub that works on the RP2350, but there's another hardware project I'd like to complete before designing a new PicoGUS based on it.

LSS10999 wrote on 2025-06-04, 02:34:

A question, as I'm struggling to figure out what might be wrong with my 2nd PicoGUS v1.2 assembly. […]
Show full quote

A question, as I'm struggling to figure out what might be wrong with my 2nd PicoGUS v1.2 assembly.

For some reasons, that card works without any issue in SB mode, but when in GUS mode, it could not detect any valid RAM.
- GUSDRAM reports all banks BAD. ULTRAMID would refuse to load citing no memory available, and if I try launching ULTRAMID a second time, the system would freeze or, if JEMM loaded, keep generating exception messages.

I inspected the soldering with a magnifier but could not find anything problematic. I suspected the PSRAM chip may be faulty so I replaced it with another one, but no difference.

I wonder what might be causing the issue, as from the schematic it's just some GPIOs used by Pico for SPI connecting to the PSRAM... I'm using v2.2.0 firmware, and I don't have a spare Pico at the moment...

UPDATE: Got myself another Pico and no avail. Same issue. The card still can only work in SB mode. GUS is no-go. When running pgusinit without any argument it simply says the card is not responding to GUS commands on port 240. I wonder if something's wrong with that particular PCB, as my first build worked correctly in GUS mode.

This is a pretty weird problem, but I have a hunch. I don't think it's PSRAM related, because at startup the PicoGUS tests the PSRAM and will flash the LED if the test fails. If pgusinit says the card is not responding to GUS commands on port 240, but SB mode works, that points to potential soldering issues on the mux for the address bits (specifically bit 6 which is pin 14 of U4, or bit 8, pin 6 of U2). If you change your GUS config to port 220 (pgusinit /gusport 220, set ULTRASND=220,x,x,y,y), does it work? If it starts working at 220, that points to bit 6 being the problem, but still doesn't work, that points to bit 8.

The talk I gave at VCF East this year about the story of the development of PicoGUS, "Making a Hardware Emulator For a Legendary PC Sound Card" is now up on YouTube! Vogons is mentioned, especially an important very helpful comment by @rasz_pl that started me down the path of using the Pico. https://www.youtube.com/watch?v=gTLAhIkmUl0

polpo wrote on 2025-06-14, 20:03:

This is a pretty weird problem, but I have a hunch. I don't think it's PSRAM related, because at startup the PicoGUS tests the PSRAM and will flash the LED if the test fails. If pgusinit says the card is not responding to GUS commands on port 240, but SB mode works, that points to potential soldering issues on the mux for the address bits (specifically bit 6 which is pin 14 of U4, or bit 8, pin 6 of U2). If you change your GUS config to port 220 (pgusinit /gusport 220, set ULTRASND=220,x,x,y,y), does it work? If it starts working at 220, that points to bit 6 being the problem, but still doesn't work, that points to bit 8.

I think PSRAM should be okay, as I do not see the Pico flashing the LED (for test failure).

Setting /gusport 220 makes the card not even detectable by ULTRAMID and GUSDRAM. Tried resoldering U2 and U4 paying attention to the pins you suggested, but still no difference. Guess I'll leave that one in SB mode for now.

I also assembled another one (my 3rd) hopefully for comparison, but unfortunately that one couldn't even work. Some commands would return garbage while others go through. PGUSINIT outputs a bunch of "white stripes" (DFh I think) for firmware version, with MPU401 port being reported as FF12 which certainly shouldn't be. Couldn't find anything out of ordinary when inspecting the soldering of the new one with a magnifier, however. Reflashed the Pico with v2.2.0 firmware and still no difference.

Anyway, I think I'll take a break on these for now, as I'm looking forward to a newer, RP2350-based version that may offer more features.

polpo wrote on 2025-06-14, 20:08:

The talk I gave at VCF East this year about the story of the development of PicoGUS, "Making a Hardware Emulator For a Legendary PC Sound Card" is now up on YouTube! Vogons is mentioned, especially an important very helpful comment by @rasz_pl that started me down the path of using the Pico. https://www.youtube.com/watch?v=gTLAhIkmUl0

Here you briefly discuss possibilities for the next revision of the card, in particular multiple analogue in ports. This would be a very welcome addition. You mentioned that the subsequent PicoGUS revision would need to wait for the next iteration of the Raspberry Pi Pico (RP2350 series, I think). I had also been wondering if you have considered adding a traditional DB15 game port? Thanks.

Also are you planning to make tinkerer friendly version of the next card, for us who like to assemble the puzzle by self instead of buying it assembled?

Kekkula wrote on 2025-06-16, 05:44:

Also are you planning to make tinkerer friendly version of the next card, for us who like to assemble the puzzle by self instead of buying it assembled?

The PicoGUS and all of the revisions I am aware of are open source. Nothing is holding you back from assembling yourself.