LSS10999 wrote on 2025-06-21, 13:59:

Been thinking of the RP2350B which has 48 GPIOs compared to RP2040/RP2350A which has 30. […]
Show full quote

Been thinking of the RP2350B which has 48 GPIOs compared to RP2040/RP2350A which has 30.

Will this enable the possible use of additional IRQ/DMA lines in the future? Should be useful for:
- Intelligent mode MPU401 with other modes.
- High DMA (16-bit) for proper SB16 support.

For accessing high IRQ/DMA lines the card will have to be made 16-bit, though.

It already does intelligent MIDI mode on the MPU401. I'm not sure if it's based around the Hard/SoftMPU standard that doesn't support recording. But early MT-32 games that need intelligent mode work, I run a MP32 McCake on the MIDI daughterboard connector of my PicoGUS and Wing Commander plays music without a fuss.

The GUS itself is already a 16-bit card. I haven't received where the traces go, but you need to set two jumpers for the DMA channel. It's very possible both DMA 1 and DMA 3 route to the same GPIO pins of the RP2040. So you'd need to use additional GPIO for support both the low and high DMA channels of a SB16. Or if you have enough GPIO, get rid of all the jumpers all together and make it fully software configurable.

SScorpio wrote on 2025-06-21, 15:00:

It already does intelligent MIDI mode on the MPU401. I'm not sure if it's based around the Hard/SoftMPU standard that doesn't support recording. But early MT-32 games that need intelligent mode work, I run a MP32 McCake on the MIDI daughterboard connector of my PicoGUS and Wing Commander plays music without a fuss.

The GUS itself is already a 16-bit card. I haven't received where the traces go, but you need to set two jumpers for the DMA channel. It's very possible both DMA 1 and DMA 3 route to the same GPIO pins of the RP2040. So you'd need to use additional GPIO for support both the low and high DMA channels of a SB16. Or if you have enough GPIO, get rid of all the jumpers all together and make it fully software configurable.

I've already read the schematic. Currently the card only uses one IRQ line and one DMA channel at a time. Was thinking about the possibility of additional IRQ/DMA lines, but sadly all the GPIOs have been assigned.

Man, this card just keeps getting better and better. it's like a Swiss army knife. Very interested in checking out the CD emulation, will be especially handy for older machines that might have all drive bays used up with other peripherals, or machines with just one drive bay, or of course, machines with broken non working or partially working disc drives. One of mine in particular works... But the disc needs to be a pressed disc in excellent condition... Cdrs or a couple scratches here and there throw it off, so this will be a wonderful alternative.

polpo wrote on 2025-06-19, 15:21:

PicoGUS firmware v3.0.0 [edit: v3.0.1] is now released! This adds Panasonic CD-ROM emulation to PicoGUS. Put some ISOs or BIN/CUE files on a USB stick, plug it into your PicoGUS, and you've got a virtual CD-ROM drive that works in DOS and Windows 9x and supports CD audio.

https://github.com/polpo/picogus/releases/tag/v3.0.1

Thank you and everyone who's contributed to this incredible project.

Would it be possible to have the ISO selecting also support taking the filename as the argument? I can see the desire to have a menu that will mount the image and then launch games automatically. And being able to modify what's on the USB drive without changing indexes this would require reconfiguring everything would be ideal.

SScorpio wrote on 2025-06-21, 17:31:

Thank you and everyone who's contributed to this incredible project.

Would it be possible to have the ISO selecting also support taking the filename as the argument? I can see the desire to have a menu that will mount the image and then launch games automatically. And being able to modify what's on the USB drive without changing indexes this would require reconfiguring everything would be ideal.

This is a good idea and adding it should be pretty easy. I hadn’t thought of that use case until elsewhere I saw an absolutely heroic batch file that parsed the output of the /cdlist command to get the index of the specified file name.

I have some fixed bugs (/cdload showing timeout despite success, or timing out and failing after the 10th or so load) and I’ll add that feature in as well. Look for it in the next release!

polpo wrote on 2025-06-21, 18:02:

This is a good idea and adding it should be pretty easy. I hadn’t thought of that use case until elsewhere I saw an absolutely heroic batch file that parsed the output of the /cdlist command to get the index of the specified file name.

This is how I use my machine, I have most of the games added to Lauchbox DOS edition and scripts handle setting the PicoGUS, CPU and MT32Pi to the correct modes to run the game. I (mistakenly) assumed that selection by filename was going to happen eventually and it was just not a priority.

polpo wrote on 2025-06-21, 18:02:

I have some fixed bugs (/cdload showing timeout despite success, or timing out and failing after the 10th or so load) and I’ll add that feature in as well. Look for it in the next release!

FWIW I also experienced a timeout getting the CD list until the PicoGUS was re-initalized after running warcraft 1 a couple of times (which worked perfectly btw). It's a good test because it does streaming animation from the CD, soundblaster audio and FM music all at the same time.

This might be sort of an edge case feature, but I had the thought today if the CD-ROM emulation could be adapted to using a USB external CD-ROM? Using images is definitely ideal for most situations, but it might be nice to have the ability to access a physical CD and stream the audio as an option as well.

Or the ability to use the new USBode reviewed by Phils Computer Lab would be good aswell.

Delphius wrote on 2025-06-22, 16:53:

This might be sort of an edge case feature, but I had the thought today if the CD-ROM emulation could be adapted to using a USB external CD-ROM? Using images is definitely ideal for most situations, but it might be nice to have the ability to access a physical CD and stream the audio as an option as well.

swisstoni wrote on 2025-06-22, 17:16:

Or the ability to use the new USBode reviewed by Phils Computer Lab would be good aswell.

Delphius wrote on 2025-06-22, 16:53:

This might be sort of an edge case feature, but I had the thought today if the CD-ROM emulation could be adapted to using a USB external CD-ROM? Using images is definitely ideal for most situations, but it might be nice to have the ability to access a physical CD and stream the audio as an option as well.

I've thought about it and it's totally possible. For example, there's an ODE for the 3DO based on the Pico that can use a USB mass storage optical drive. The CD audio won't be able to be mixed into the PicoGUS, though, since the USB device will be the one playing the disc, unless the PicoGUS does some kind of real time rip-and-play. The USBODE is neat and it'd be nice to have have it as an external interface for swapping discs.

Firmware v3.1.0 is released: https://github.com/polpo/picogus/releases/tag/v3.1.0

Many fixes/improvements to CD image handling:

• Add ability to load image by name
• Fix memory leak when changing images (file handle not freed, causing crash after switching images several times)
• Less memory usage all over
• Longer max file length limit (127 chars)
• Better errors when USB not present
• Fix polling of CD status register when listing images
• Many weird edge cases with image loading state fixed

I am curious if there is a guide or script provided for compiling and building a proper uf2 file for picogus? I think I have the main uf2 compiling properly, but it does not seem to be the entire package. Seems I am missing something with the multi firmware support or something. I would like to try my hand at contributing, but feeling a bit stuck just getting a stock firmware compiled.

polpo wrote on 2025-06-22, 18:15:

Firmware v3.1.0 is released: https://github.com/polpo/picogus/releases/tag/v3.1.0 […]
Show full quote

Firmware v3.1.0 is released: https://github.com/polpo/picogus/releases/tag/v3.1.0

Many fixes/improvements to CD image handling:

• Add ability to load image by name
• Fix memory leak when changing images (file handle not freed, causing crash after switching images several times)
• Less memory usage all over
• Longer max file length limit (127 chars)
• Better errors when USB not present
• Fix polling of CD status register when listing images
• Many weird edge cases with image loading state fixed

This is great to see this moving a long so fast! So far in my tests, everything is working pretty great. Although sometimes the CD-ROM audio volume is very loud and is clipping my mixer. But overall this has been super handy and I am looking forward to incorporating it into all of my systems. It is also great to see it working in Windows 95!

Delphius wrote on 2025-06-22, 19:28:

I am curious if there is a guide or script provided for compiling and building a proper uf2 file for picogus? I think I have the main uf2 compiling properly, but it does not seem to be the entire package. Seems I am missing something with the multi firmware support or something. I would like to try my hand at contributing, but feeling a bit stuck just getting a stock firmware compiled.

If you have a build completing you're basically already there. Sorry there's no guide, but once you know what to set it's pretty straightforward. The type of build is controlled by the PROJECT_TYPE CMake variable. To build just a single mode, you can set it to GUS (the default), SB, USB, MPU, PSG, ADLIB, NE2K, or for the full mega multifirmware build set it to MULTIFW . Almost always when I'm developing I use one of the standalone mode builds because the MULTIFW build takes longer to compile and a lot longer to upload to the Pico. I also have a special program target so I can do make program to build and immediately push my code to the Pico that is connected via a Pico debug probe.

If you're curious how the releases are built, it's all done with GitHub actions and controlled by .github/workflows/build.yml. You can see how it calls cmake -DPROJECT_TYPE=MULTIFW to configure a multifw build.

Updated to v3.1.0

- No longer recieving a timeout message changing CD images on slower USB drive
- CD image switching and cd image list remained stable over 100 image change operations
- Potential bug: /cdlist fails after specifying an incorrect image name using /cdloadname, works again after successfully loading an image or mode change/reset
- Potential bug: Still getting garbled/sped up speech in King's Quest 6 CD Edition which is not present using IDE CD-ROM drive

Since the edit function is disabled please forgive the double post

- Potential bug: Experiencing delayed MPU401 response only in sb mode when starting 'The Castle of Dr. Brain' (Sierra, 1991). In mpu, gus and usb mode it works perfectly. In sb mode no midi notes are output until half way through the Sierra introduction.

polpo wrote on 2025-06-23, 02:39:

Delphius wrote on 2025-06-22, 19:28:

I am curious if there is a guide or script provided for compiling and building a proper uf2 file for picogus? I think I have the main uf2 compiling properly, but it does not seem to be the entire package. Seems I am missing something with the multi firmware support or something. I would like to try my hand at contributing, but feeling a bit stuck just getting a stock firmware compiled.

If you have a build completing you're basically already there. Sorry there's no guide, but once you know what to set it's pretty straightforward. The type of build is controlled by the PROJECT_TYPE CMake variable. To build just a single mode, you can set it to GUS (the default), SB, USB, MPU, PSG, ADLIB, NE2K, or for the full mega multifirmware build set it to MULTIFW . Almost always when I'm developing I use one of the standalone mode builds because the MULTIFW build takes longer to compile and a lot longer to upload to the Pico. I also have a special program target so I can do make program to build and immediately push my code to the Pico that is connected via a Pico debug probe.

If you're curious how the releases are built, it's all done with GitHub actions and controlled by .github/workflows/build.yml. You can see how it calls cmake -DPROJECT_TYPE=MULTIFW to configure a multifw build.

Ok great! I think the project type flag is mostly what I was missing. I am getting a few errors still but I think I can work the rest of it out once I find a moment. Thanks!

NeoG_ wrote on 2025-06-23, 06:07:

Updated to v3.1.0 […]
Show full quote

Updated to v3.1.0

- No longer recieving a timeout message changing CD images on slower USB drive
- CD image switching and cd image list remained stable over 100 image change operations
- Potential bug: /cdlist fails after specifying an incorrect image name using /cdloadname, works again after successfully loading an image or mode change/reset
- Potential bug: Still getting garbled/sped up speech in King's Quest 6 CD Edition which is not present using IDE CD-ROM drive

NeoG_ wrote on 2025-06-23, 10:39:

Since the edit function is disabled please forgive the double post

- Potential bug: Experiencing delayed MPU401 response only in sb mode when starting 'The Castle of Dr. Brain' (Sierra, 1991). In mpu, gus and usb mode it works perfectly. In sb mode no midi notes are output until half way through the Sierra introduction.

Thanks for the reports!
I'll look into the issue with /cdlist after a failed /cdloadname.
I tried reproducing the issue with KQ6 (I couldn't get speech to work at all) but it looks like there are several different editions out there (Original Rerelease, Sierra Originals). Which one are you using?
The delayed MPU-401 is something I've run into before and I should be able to fix it quickly (basically, it's not outputting MIDI messages fast enough, which can cause a big delay if there's a lot of SYSEX messages on game start).

polpo wrote on 2025-06-23, 22:25:

I tried reproducing the issue with KQ6 (I couldn't get speech to work at all) but it looks like there are several different editions out there (Original Rerelease, Sierra Originals). Which one are you using?

It's the 1995 MPC release (I believe the original CD). For speech in KQ6 it's typical Sierra jank;

1) Audio driver init will fail unless you have a 386 or 486 class machine (mine is a K6-2+ downrated to 486/90 speed using setmul)
2) AUDBLAST.DRV can be patched to work on faster machines, but can crash randomly on cards other than original SB/SBPRO
3) Using the Thunderboard (equivalent of "SB clone") setting in the setup program can fix #2, but doesn't have a speed patch

Happy to provide a CD image and game folder including a patched AUDBLAST.DRV for testing purposes. I went through several annoyances to get it to work in the first place so can give you the shortcut method. The most consistently working setup is a 486 or slowed system with Thunderboard selected.

Thanks for the new firmware update which flashed fine. My system has an ESS1688 integrated on the motherboard ive changed the port and IRQ in software so it doesnt clash with the Picogus. All modes work except standalone Soundblaster mode the game will load then black screen as soon the game starts and my system locks up. However if I use MPU mode I can change the sound to Soundblaster and it works fine. Its not really an issue I can use MPU mode but I was wondering if anyone else had the same issue. I should also note I previously had the very old firmware where the card had to be flashed everytime you changed modes. Also when mounting isos if you have a physical cd drive in your system what drive letter would the iso be?

swisstoni wrote on Yesterday, 17:27:

Thanks for the new firmware update which flashed fine. My system has an ESS1688 integrated on the motherboard ive changed the port and IRQ in software so it doesnt clash with the Picogus.

I have an ES1869 with a PicoGUS and can run it is SB mode next to the ESS card without lockups - You mentioned the port and IRQ but what about the DMA? Can you list what resources each card is set to use?

Was it working with the older firmware, which game is it? I can test it on my system as well

swisstoni wrote on Yesterday, 17:27:

Also when mounting isos if you have a physical cd drive in your system what drive letter would the iso be?

Drive letters for CD-ROM drives in DOS are controlled by MSCDEX, you supply it multiple /D:<devicename> parameters and they are assigned letters in that order starting with the first free letter. You can also override the drive letter for each drive using /L:<letter> /D:<devicename>