So the GUS Music works, in general. All I want is to listen to (and record) the music tracks using GUS patches. Gonna buy it then while it's available. Could you record a short video of it or something?

Valet2 wrote on 2026-03-04, 07:56:

So the GUS Music works, in general. All I want is to listen to (and record) the music tracks using GUS patches. Gonna buy it then while it's available. Could you record a short video of it or something?

Here is a short video of the intro with FX disabled so it plays the MIDI music (with GUS driver swap)

https://www.youtube.com/watch?v=q9dD-Ba3TiM

I have a beta testing firmware available with a few changes that might interest some of you. It adds better support for HID gamepads and joysticks with hot plugging support and a few other bug fixes and features for joysticks. It should support most HID gamepads now but I only have a few to test and some of them still have trouble. I also fixed some issues with the CD-ROM audio buffer and reading so it should be a little more stable. Then I also added support for YMFM OPL3 so the OPL emulation should be much better.

https://github.com/RetroLoom/picogus/releases/tag/v3.3.0beta

Feel free to report back here with any issues. Remember this is a testing beta release so don't expect everything to be perfect. But I will try and fix the issues the come up.

Delphius wrote on 2026-03-09, 23:31:

I also fixed some issues with the CD-ROM audio buffer and reading so it should be a little more stable. Then I also added support for YMFM OPL3 so the OPL emulation should be much better.

Very interesting - Last I heard, OPL3 was too heavy for the RP2040, although I believe that was using Nuked OPL3. Is YMFM significantly less intensive?

Lack of OPL3 is what was preventing Ian from releasing SB16/WSS support as well

NeoG_ wrote on Yesterday, 00:13:

Delphius wrote on 2026-03-09, 23:31:

I also fixed some issues with the CD-ROM audio buffer and reading so it should be a little more stable. Then I also added support for YMFM OPL3 so the OPL emulation should be much better.

Very interesting - Last I heard, OPL3 was too heavy for the RP2040, although I believe that was using Nuked OPL3. Is YMFM significantly less intensive?

Lack of OPL3 is what was preventing Ian from releasing SB16/WSS support as well

Yes I found out that YMFM is very efficient, not a lot more CPU hungry than the emu8950 actually. I was also able to improve the sound of the emu8950 by turning off some performance flags. I have kept emu8950 available with some build flags in case it is needed for higher performance later. But YMFM sounds much better and when in OPL2 mode it actually automatically scales down and uses half of the operators. So I think it is a fair replacement for the emu8950 either way. It is not designed to be sample accurate like Nuked OPL3 but it was designed to be efficient and high quality.

I have started an SB16 implementation and checked out the branches that have been started. I have detection working fine but there is an issue with audio playback. It will play fine for a few seconds then it speeds up and sounds choppy. But I will keep giving it a try.

Sorry for not getting it; why is there a fork of the firmware now? Does polpo no longer do firmware updates himself?

appiah4 wrote on Yesterday, 05:56:

Sorry for not getting it; why is there a fork of the firmware now? Does polpo no longer do firmware updates himself?

The firmware is open source, a fork happens whenever someone feels like forking it. I assume Delphius just wanted to start messing around with the firmware. Ian may decide to pull in some of the changes in an upcoming firmware. Situation normal for OSS really.

Yes, I’m busy with finishing PicoIDE but do want to merge these changes in when done. BTW Delphius did a fork when he improved other things like pgusinit and adding volume control a while back. Perfectly normal open source development!

I’m excited that things are now fast enough for YMFM even when emulating OPL3. I tested it a long time ago but there wasn’t enough CPU time for it. But when I made SB emulation “bufferless” and used my own I2S code it freed up a *lot* of CPU time that was burned waiting for the audio buffer to empty.

appiah4 wrote on Yesterday, 05:56:

Sorry for not getting it; why is there a fork of the firmware now?

This is how github development works. You fork original, do stuff to it and when you are happy submit pull request
here is branch with RetroLoom commits https://github.com/RetroLoom/picogus/commits/ … _CDROM_OPL_DEV/
on cursory glance all solid changes

Yes these are some features I was wanting to try implementing, primarily getting better joystick support. I knew polpo was busy so I thought I would just take some initiative and release a beta firmware so it could all be tested and ready before pulling it into the main project. Originally I was just going to add the HID joystick support, but adding hot plugging support revealed issues with the CD ROM buffer that was easily interrupted by the changes in the USB. So I went through and fixed those up problems up which most likely improved the CD ROM experience in general. Since I was on the subject of CD ROM fixes I decided to check the github issues page and look for anything else that was causing troubles. I couldn't fix all of them, but some of the minor issues with CD ROM image loading has been fixed as well. The OPL changes was more of a random curiosity to see if I could improve the quality at all. After improving the sound of emu8950 emulation I had wondered if there was room to push it a little further. I wasn't expecting YMFM OPL3 to work, but I had wondered if I could at least get YMFM OPL2 working fine which is known to be an improvement over emu8950. It seemed to handle YMFM OPL2 so I gave the full OPL3 a try which was fine and still even seems to have plenty of headroom now.

There are likely little issues and bugs so it would be nice to get them worked out before pulling them into the main repo.

Thanks for the explanation. I know how Github works but for these but with this kind of solo enthusiast projects it is often the case when a developer loses interest or no longer has time and the thing goes unmaintained for a long while, so someone forks it and starts to continue developing it and becomes the new main branch etc. I was afraid for a moment that this was the case here. I've been out of touch with the retrocomputing hobby for about a year, sorry.

I no longer have the time to stay on the cutting edge and follow the project as closely as I used to, and most of the HID/CD-ROM related updates are irrelevant for my two 1.x cards so I will probably wait for a release on the official branch 😀

Delphius wrote on Yesterday, 14:55:

Yes these are some features I was wanting to try implementing, primarily getting better joystick support. I knew polpo was busy so I thought I would just take some initiative and release a beta firmware so it could all be tested and ready before pulling it into the main project. Originally I was just going to add the HID joystick support, but adding hot plugging support revealed issues with the CD ROM buffer that was easily interrupted by the changes in the USB. So I went through and fixed those up problems up which most likely improved the CD ROM experience in general. Since I was on the subject of CD ROM fixes I decided to check the github issues page and look for anything else that was causing troubles. I couldn't fix all of them, but some of the minor issues with CD ROM image loading has been fixed as well. The OPL changes was more of a random curiosity to see if I could improve the quality at all. After improving the sound of emu8950 emulation I had wondered if there was room to push it a little further. I wasn't expecting YMFM OPL3 to work, but I had wondered if I could at least get YMFM OPL2 working fine which is known to be an improvement over emu8950. It seemed to handle YMFM OPL2 so I gave the full OPL3 a try which was fine and still even seems to have plenty of headroom now.

There are likely little issues and bugs so it would be nice to get them worked out before pulling them into the main repo.

Hi, thank for your work

Maybe i understand bad, but with your firmware i dont need to turn off/on PC every time i swap USB pendrives?

thanks

theelf wrote on Today, 06:26:

Hi, thank for your work

Maybe i understand bad, but with your firmware i dont need to turn off/on PC every time i swap USB pendrives?

thanks

You already don't need to restart when you swap pen drives, the official firmware will hot swap USB pen drives with the system on. The change was to hot swap USB joysticks.

NeoG_ wrote on Today, 08:29:

theelf wrote on Today, 06:26:

Hi, thank for your work

Maybe i understand bad, but with your firmware i dont need to turn off/on PC every time i swap USB pendrives?

thanks

You already don't need to restart when you swap pen drives, the official firmware will hot swap USB pen drives with the system on. The change was to hot swap USB joysticks.

Hi! i have official latest firmware, and every time i change USB did not work until power off/on, if i change usb while PC on, cdlist always give the list of files that was on usb pendrive when power on. Even a reset did not work

theelf wrote on Today, 16:02:

Hi! i have official latest firmware, and every time i change USB did not work until power off/on, if i change usb while PC on, cdlist always give the list of files that was on usb pendrive when power on. Even a reset did not work

I can confirm on my computer with latest official PicoGUS firmware I can:

• Turn on the computer with or without a USB drive inserted
• Insert a USB drive and get an updated cd list while the computer is on
• Mount and use any new images put on the USB drive when inserted without powering off or resetting

If your cd list is freezing, there is likely an issue with one of the cd images, or the name of one of the cd images in the list. Maybe you can export the cdlist to a text file and show Delphius to see if there is a firmware bug related to it. It could be issues with non-english character sets for example.

NeoG_ wrote on 14 minutes ago:

I can confirm on my computer with latest official PicoGUS firmware I can: […]
Show full quote

theelf wrote on Today, 16:02:

Hi! i have official latest firmware, and every time i change USB did not work until power off/on, if i change usb while PC on, cdlist always give the list of files that was on usb pendrive when power on. Even a reset did not work

I can confirm on my computer with latest official PicoGUS firmware I can:

• Turn on the computer with or without a USB drive inserted
• Insert a USB drive and get an updated cd list while the computer is on
• Mount and use any new images put on the USB drive when inserted without powering off or resetting

If your cd list is freezing, there is likely an issue with one of the cd images, or the name of one of the cd images in the list. Maybe you can export the cdlist to a text file and show Delphius to see if there is a firmware bug related to it. It could be issues with non-english character sets for example.

Hi, thanks reply, here Picogus v3.2.1 firmware

Impossible must be name problem, because i use 001.iso, 002.iso, 003.cue/iso, etc i dont like to use names

This is what happen to me

[*]Turn on the computer with or without a USB drive inserted
[*]Insert a USB drive and get an updated cd list while the computer is on
[*]Mount and use any new images put on the USB drive when inserted without powering off or resetting
[*]Unplug USB
[*]Insert new USB
[*]cdlist show same list of FIRST usb until power off/on

Same happen if i use the picogus in my 286 or 486 PC

But i will reflash picogus and test again, knowing need to work. I just believe was normal behavior thats why never care much of this