keenerb wrote on 2024-01-16, 17:37:

What does the process of switching modes look like? I see references to "when X firmware is loaded" in the wiki and on the git page.

Is switching modes, say from GUS to MPU ,as simple as running a command and then launching an app?

i set up some batch files to make it quicker, but all you have to do is pgusinit /f pg-mpu.uf2 (swap in the fw of choice)

Pickle wrote on 2024-01-16, 17:58:

keenerb wrote on 2024-01-16, 17:37:

What does the process of switching modes look like? I see references to "when X firmware is loaded" in the wiki and on the git page.

Is switching modes, say from GUS to MPU ,as simple as running a command and then launching an app?

i set up some batch files to make it quicker, but all you have to do is pgusinit /f pg-mpu.uf2 (swap in the fw of choice)

Have you made any progress with your v2 card? Are you still missing audio in some games?

vutt wrote on 2024-01-16, 17:18:

Just out of curiosity I went and tested my v2 board midi capabilities first time.
No issues whatsoever with Monkey I and SQ3 on my K6-II@280MHZ SS7 MB with SIS530 chipset. L1 and L2 caches enabled. However SIS530 might be unique because I also do not have any issues running speed sensitive games like Tyrian. I'm running it even on 112MHZ bus speed in order to boost integrated SIS graphics memory bandwidth...

However my testes were done on MT32-Pi

Thank you for also confirming that things are working for you, it helps give me ideas on where I should test next.

What is interesting is everything else seems to be working fine, even GUS has been working for me with no issues. My issue here applies to both a real MT32 as well as an MT32pi. I have a Motu midi timepiece that helps me monitor midi activity. It shows me that after the MT32 driver initializes there is a small flash of data, then the data stream stops and the computer freezes. Testing with other MT32 games seems to also fail. But so far all general midi drivers are working fine and sound great.

Delphius wrote on 2024-01-16, 15:41:

polpo wrote on 2024-01-16, 06:48:

Delphius wrote on 2024-01-16, 02:39:

I ran into a new problem tonight with MPU emulation. Went to play around with some MT32 games like SQ3, QFG1, and Monkey Island and found that the midi did not work for them. For the Sierra games the computer locks on the game start up. I see one small blip of input to my MT32 at the very beginning before it locks up. Monkey Island sometimes plays some music, but the patches are off and things play garbled. What is interesting is that the MT32 is getting the *** PicoGus *** display message when picogus initializes so it is capable of sending midi to the MT32. However, when I select a General Midi driver with the Sierra games and Warcraft II the midi works perfectly with my Sound Canvas. It only seems to be MT32 drivers having issues.

I have tried a few different things, like the delay sysex option as well as different IRQ's and memory options. Nothing seems to fix MT32. I will see if I can do some more debug and logging.

That's a new one to me – what system (mobo chipset & CPU) are you using? I did notice this thead saying some Sierra games don't work in MT-32 mode on fast systems, maybe that's the issue you have? Tonight I tried SQ3 and QFG1 with MT-32 on several systems of varying speeds (Pentium 120 w/ 430FX, K6-2 533 w/ VIA MVP3, PII 450 w/ 440BX) and didn't have any issues, so I'm not entirely sure of that.

I've found that Monkey Island doesn't fully reset the MT-32 and it'll give you pretty bad sound unless you power cycle the MT-32 if anything else has played MIDI before.

The current system is an AG430HX with 233mmx & 64MB. I am also very surprised about this and I am trying to think back to if I ever had MT32 working with PicoGus or not before. It seems this would have been one of the first things I would have checked. I turned the system cache off to see if that would help but it still gave the same problem. I will try to do a little more testing today as well as try putting my Orpheus in to see if it acts the same with MT32 games.

I swapped in the Orpheus and it works fine with MPU and MT32 drivers. I wanted to make sure there wasn't some other conflict in the system that was preventing this from working correctly with MPU in general. I will keep trying some things out with the PicoGUS. Is it possible this is related to noisy reset?

HandOfFate wrote on 2024-01-16, 18:34:

Have you made any progress with your v2 card? Are you still missing audio in some games?

i have not, anything based on the doom engine does not produce sound. No luck switching it into other systems. Suspicion is on the card since i can just drop in the v1 and it works.

vutt wrote on 2024-01-16, 17:18:

However my testes were done on MT32-Pi

Brave posting a link to your testes on the internet (-:

Just kidding. Just a funny typo.

Delphius wrote on 2024-01-16, 18:52:

Delphius wrote on 2024-01-16, 15:41:

polpo wrote on 2024-01-16, 06:48:

That's a new one to me – what system (mobo chipset & CPU) are you using? I did notice this thead saying some Sierra games don't work in MT-32 mode on fast systems, maybe that's the issue you have? Tonight I tried SQ3 and QFG1 with MT-32 on several systems of varying speeds (Pentium 120 w/ 430FX, K6-2 533 w/ VIA MVP3, PII 450 w/ 440BX) and didn't have any issues, so I'm not entirely sure of that.

I've found that Monkey Island doesn't fully reset the MT-32 and it'll give you pretty bad sound unless you power cycle the MT-32 if anything else has played MIDI before.

The current system is an AG430HX with 233mmx & 64MB. I am also very surprised about this and I am trying to think back to if I ever had MT32 working with PicoGus or not before. It seems this would have been one of the first things I would have checked. I turned the system cache off to see if that would help but it still gave the same problem. I will try to do a little more testing today as well as try putting my Orpheus in to see if it acts the same with MT32 games.

I swapped in the Orpheus and it works fine with MPU and MT32 drivers. I wanted to make sure there wasn't some other conflict in the system that was preventing this from working correctly with MPU in general. I will keep trying some things out with the PicoGUS. Is it possible this is related to noisy reset?

Ok I decided to pull my SB16 CT2290 out and give it a try and everything with MT32 seems to be working fine now. So it seems it was conflict which I guess should have been more obvious. It is interesting how address / irq prioritize though because the Orpheus had no issues becoming the primary at 330h.

On a side note, I noticed when logging midi data with Midi-OX that the Orpheus is constantly sending out timecode. I am wondering if the PicoGUS can do the same? I know this has been very useful when I am doing midi captures.

Delphius wrote on 2024-01-16, 19:25:

Ok I decided to pull my SB16 CT2290 out and give it a try and everything with MT32 seems to be working fine now. So it seems it was conflict which I guess should have been more obvious. It is interesting how address / irq prioritize though because the Orpheus had no issues becoming the primary at 330h.

On a side note, I noticed when logging midi data with Midi-OX that the Orpheus is constantly sending out timecode. I am wondering if the PicoGUS can do the same? I know this has been very useful when I am doing midi captures.

Interesting and I'm glad you figured out the issue! I never thought to ask if you had any other sound cards in the system. It looks like closing JP10 on the CT2290 can disable the MPU port and JP11 can move it to port 300h.

As for how addresses or IRQs prioritize, they don't really. Whatever device can answer first or drive the ISA data lines more strongly might "win" but the more likely scenario is garbage on the bus. Since the PicoGUS does address decoding in software and is slightly slower than hardware, and is only a 3.3v device and can't drive as hard as a vintage 5V card, it will lose every time another card decodes the same address or drives the same IRQ line. There are some circumstances such as cards that are used as "write only" devices where the PicoGUS can coexist, but intelligent mode MPU-401 is definitely not one of those.

I'm not familiar with this timecode... I'll have to read up on it. I also have an Orpheus and can try capturing what it outputs.

polpo wrote on 2024-01-16, 20:23:

Interesting and I'm glad you figured out the issue! I never thought to ask if you had any other sound cards in the system. It looks like closing JP10 on the CT2290 can disable the MPU port and JP11 can move it to port 300h.

Thanks for the tips with the jumpers. This card is a weird almost but not quite PnP card with the IRQ and DMA and I forgot to look for any jumpers to change something like this. I also thought it was following SET BLASTER variables when initializing through unisound so I wasn't expecting a conflict. I will try some things out.

polpo wrote on 2024-01-16, 20:23:

As for how addresses or IRQs prioritize, they don't really. Whatever device can answer first or drive the ISA data lines more strongly might "win" but the more likely scenario is garbage on the bus. Since the PicoGUS does address decoding in software and is slightly slower than hardware, and is only a 3.3v device and can't drive as hard as a vintage 5V card, it will lose every time another card decodes the same address or drives the same IRQ line. There are some circumstances such as cards that are used as "write only" devices where the PicoGUS can coexist, but intelligent mode MPU-401 is definitely not one of those.

This makes sense and also makes me curious. Is there a main limit as to why the PicoGUS is a 3.3v device and isn't driving at 5v?

polpo wrote on 2024-01-16, 20:23:

I'm not familiar with this timecode... I'll have to read up on it. I also have an Orpheus and can try capturing what it outputs.

Delphius wrote on 2024-01-16, 21:48:

polpo wrote on 2024-01-16, 20:23:

As for how addresses or IRQs prioritize, they don't really. Whatever device can answer first or drive the ISA data lines more strongly might "win" but the more likely scenario is garbage on the bus. Since the PicoGUS does address decoding in software and is slightly slower than hardware, and is only a 3.3v device and can't drive as hard as a vintage 5V card, it will lose every time another card decodes the same address or drives the same IRQ line. There are some circumstances such as cards that are used as "write only" devices where the PicoGUS can coexist, but intelligent mode MPU-401 is definitely not one of those.

This makes sense and also makes me curious. Is there a main limit as to why the PicoGUS is a 3.3v device and isn't driving at 5v?

The RP2040 has 3.3v IO, and I didn't want to add an extra bus transceiver chip to convert up from 3.3V to 5V. If there are no conflicts (and to be quite honest, no card should be relied on to work if there are conflicts), 3.3V signalling works just fine.

I'm thinking of adding some extra checks to pgusinit to determine if base address and IRQ/DMA (if applicable) don't have conflicts. It should be relatively straightforward and help point to the cause of a lot of the issues I've seen reported in this thread. It should be pretty simple to disable decoding on the PicoGUS and probe if there is an MPU/GUS/OPL/CMS already on the ports and report back to the user.

polpo wrote on 2024-01-17, 04:19:

Delphius wrote on 2024-01-16, 21:48:

polpo wrote on 2024-01-16, 20:23:

As for how addresses or IRQs prioritize, they don't really. Whatever device can answer first or drive the ISA data lines more strongly might "win" but the more likely scenario is garbage on the bus. Since the PicoGUS does address decoding in software and is slightly slower than hardware, and is only a 3.3v device and can't drive as hard as a vintage 5V card, it will lose every time another card decodes the same address or drives the same IRQ line. There are some circumstances such as cards that are used as "write only" devices where the PicoGUS can coexist, but intelligent mode MPU-401 is definitely not one of those.

This makes sense and also makes me curious. Is there a main limit as to why the PicoGUS is a 3.3v device and isn't driving at 5v?

The RP2040 has 3.3v IO, and I didn't want to add an extra bus transceiver chip to convert up from 3.3V to 5V. If there are no conflicts (and to be quite honest, no card should be relied on to work if there are conflicts), 3.3V signalling works just fine.

I'm thinking of adding some extra checks to pgusinit to determine if base address and IRQ/DMA (if applicable) don't have conflicts. It should be relatively straightforward and help point to the cause of a lot of the issues I've seen reported in this thread. It should be pretty simple to disable decoding on the PicoGUS and probe if there is an MPU/GUS/OPL/CMS already on the ports and report back to the user.

That all makes perfect sense, thanks for the info. I like the idea of the conflict checks as well.

My SB16 CT2290 is now set to MPU 300h and is playing nice with the PicoGUS. I hadn't used that card in a long time and for some reason I always thought it was more PnP than it is. I now have the option for onboard SB Pro 2.0, SB16 CT2290 w/ wavetable & PC speaker, and PicoGUS. All seem to be playing nice with each other.

A few side notes -
GUS support seems to work well in Jazz Jackrabbit, Doom, and Relentless but does not work with Warcraft II for some reason. This is with all other cards removed and disabled and in different combo's of IRQ and DMA's. Warcraft II setup initializes GUS fine and acts like it is playing the sound but I do not hear anything. I am pretty certain at one point it has worked though, so I am not sure why it is acting up.

I have tried a few things to get joystick support working with a OTG USB cable, both active and passive. I have tried removing and disabling any other joystick ports to make sure there are no conflicts, but nothing seems to register. I think my gamepads would be supported, but I have no idea if the RP2040 is even registering it or not. Maybe there is a way to give some feedback, or a utility that can fetch the names of connected devices so that it can be verified it is working on RP2040 side of things?

I will need to try again, but Tandy support seems to be buggy for me. Sound generates, but does not seem to register pitch changes so it just sounds monotone. Specifically PQ1 didn't work for me.

On some comparison notes, I am very impressed with the CMS emulation in comparison to my Serdaco CMSLPT. A lot of the differences I hear is more in the balance of the EQ curve, and in particular the low pass cutoff up and around 12 - 16k. Real Adlib and CMS seem to be rounded off on the top a bit more, and those extra high frequencies around 16k on the emulation seems like a lot of noise. Filtration options might be nice, but I am not sure how easy that would be to do via software or hardware.

Delphius wrote on 2024-01-17, 17:03:

[...] A few side notes - GUS support seems to work well in Jazz Jackrabbit, Doom, and Relentless but does not work with Warcraft […]
Show full quote

polpo wrote on 2024-01-17, 04:19:

Delphius wrote on 2024-01-16, 21:48:

This makes sense and also makes me curious. Is there a main limit as to why the PicoGUS is a 3.3v device and isn't driving at 5v?

The RP2040 has 3.3v IO, and I didn't want to add an extra bus transceiver chip to convert up from 3.3V to 5V. If there are no conflicts (and to be quite honest, no card should be relied on to work if there are conflicts), 3.3V signalling works just fine.

I'm thinking of adding some extra checks to pgusinit to determine if base address and IRQ/DMA (if applicable) don't have conflicts. It should be relatively straightforward and help point to the cause of a lot of the issues I've seen reported in this thread. It should be pretty simple to disable decoding on the PicoGUS and probe if there is an MPU/GUS/OPL/CMS already on the ports and report back to the user.

[...]
A few side notes -
GUS support seems to work well in Jazz Jackrabbit, Doom, and Relentless but does not work with Warcraft II for some reason. This is with all other cards removed and disabled and in different combo's of IRQ and DMA's. Warcraft II setup initializes GUS fine and acts like it is playing the sound but I do not hear anything. I am pretty certain at one point it has worked though, so I am not sure why it is acting up.
[...]

At times when Warcraft 2 is having that issue, could you check if Doom's sound is still working? Because it sounds similar to the issue that Pickle and I have with Doom where the flashing LED suggests sound is being played but the output is silent (* in most cases, sometimes I temporarily have sound in Doom)

Is this on your Pentium 233MHz that you mentioned before with the i430HX chipset?

HandOfFate wrote on 2024-01-17, 23:03:

Delphius wrote on 2024-01-17, 17:03:

[...] A few side notes - GUS support seems to work well in Jazz Jackrabbit, Doom, and Relentless but does not work with Warcraft […]
Show full quote

polpo wrote on 2024-01-17, 04:19:

The RP2040 has 3.3v IO, and I didn't want to add an extra bus transceiver chip to convert up from 3.3V to 5V. If there are no conflicts (and to be quite honest, no card should be relied on to work if there are conflicts), 3.3V signalling works just fine.

I'm thinking of adding some extra checks to pgusinit to determine if base address and IRQ/DMA (if applicable) don't have conflicts. It should be relatively straightforward and help point to the cause of a lot of the issues I've seen reported in this thread. It should be pretty simple to disable decoding on the PicoGUS and probe if there is an MPU/GUS/OPL/CMS already on the ports and report back to the user.

[...]
A few side notes -
GUS support seems to work well in Jazz Jackrabbit, Doom, and Relentless but does not work with Warcraft II for some reason. This is with all other cards removed and disabled and in different combo's of IRQ and DMA's. Warcraft II setup initializes GUS fine and acts like it is playing the sound but I do not hear anything. I am pretty certain at one point it has worked though, so I am not sure why it is acting up.
[...]

At times when Warcraft 2 is having that issue, could you check if Doom's sound is still working? Because it sounds similar to the issue that Pickle and I have with Doom where the flashing LED suggests sound is being played but the output is silent (* in most cases, sometimes I temporarily have sound in Doom)

Is this on your Pentium 233MHz that you mentioned before with the i430HX chipset?

When Warcraft 2 is having troubles, Doom seems to work fine although it seems to randomly lock up after a bit of time. I will try to do some more tests this evening to see if that is consistent or not.

Yes this is on my 233MMX and AG430HX. If I have some time I will try to test some other systems as well.

HandOfFate wrote on 2024-01-17, 23:03:

Delphius wrote on 2024-01-17, 17:03:

[...] A few side notes - GUS support seems to work well in Jazz Jackrabbit, Doom, and Relentless but does not work with Warcraft […]
Show full quote

polpo wrote on 2024-01-17, 04:19:

The RP2040 has 3.3v IO, and I didn't want to add an extra bus transceiver chip to convert up from 3.3V to 5V. If there are no conflicts (and to be quite honest, no card should be relied on to work if there are conflicts), 3.3V signalling works just fine.

I'm thinking of adding some extra checks to pgusinit to determine if base address and IRQ/DMA (if applicable) don't have conflicts. It should be relatively straightforward and help point to the cause of a lot of the issues I've seen reported in this thread. It should be pretty simple to disable decoding on the PicoGUS and probe if there is an MPU/GUS/OPL/CMS already on the ports and report back to the user.

[...]
A few side notes -
GUS support seems to work well in Jazz Jackrabbit, Doom, and Relentless but does not work with Warcraft II for some reason. This is with all other cards removed and disabled and in different combo's of IRQ and DMA's. Warcraft II setup initializes GUS fine and acts like it is playing the sound but I do not hear anything. I am pretty certain at one point it has worked though, so I am not sure why it is acting up.
[...]

At times when Warcraft 2 is having that issue, could you check if Doom's sound is still working? Because it sounds similar to the issue that Pickle and I have with Doom where the flashing LED suggests sound is being played but the output is silent (* in most cases, sometimes I temporarily have sound in Doom)

Is this on your Pentium 233MHz that you mentioned before with the i430HX chipset?

I just verified this. Jazz Jackrabbit has great GUS and is stable, Doom works with both GUS sound and music but freezes within the first minute of gameplay, and Warcraft II autodetects and initializes GUS and goes through all the motions as if it was working correctly but no sound card be heard from it. I might try playing around with some of the settings in pgusinit and see if anything improves.

Decided to test v2 PicoGUS joystick part.
I have Xbox Elite Wireless Controller Series 2 - Core Edition

Everything seems to working as intended except with one use case.
With GUS digital FX enabled on doom engine games (doom 1&2, heretic, hexen) and Raptor I'm getting slow joystick drift. It's very well visible on Raptor main hangar screen - cursor is slowly moving across screen. https://youtu.be/ucRI0906izg
No issues with other soundcard modes (mpu and adlib) or with GUS music only enabled.
It appears to be with doom engines only since Decent 1&2, OMF are working just fine.

I also tested it on old generic xinput compatible pad - same results.

Gus was initialized with default values.

EDIT: Nevermind it looks it is my main DOS PC issue - AMD K6-2 on SS7 MB (SIS 530)
I tested same use case on my other "industry standard" P3 Asus P3B-F box and could not reproduce issue above

vutt wrote on 2024-01-18, 19:27:

Decided to test v2 PicoGUS joystick part. I have Xbox Elite Wireless Controller Series 2 - Core Edition […]
Show full quote

Decided to test v2 PicoGUS joystick part.
I have Xbox Elite Wireless Controller Series 2 - Core Edition

Everything seems to working as intended except with one use case.
With GUS digital FX enabled on doom engine games (doom 1&2, heretic, hexen) and Raptor I'm getting slow joystick drift. It's very well visible on Raptor main hangar screen - cursor is slowly moving across screen. https://youtu.be/ucRI0906izg
No issues with other soundcard modes (mpu and adlib) or with GUS music only enabled.
It appears to be with doom engines only since Decent 1&2, OMF are working just fine.

I also tested it on old generic xinput compatible pad - same results.

Gus was initialized with default values.

EDIT: Nevermind it looks it is my main DOS PC issue - AMD K6-2 on SS7 MB (SIS 530)
I tested same use case on my other "industry standard" P3 Asus P3B-F box and could not reproduce issue above

I have some systems where there is the exact joystick drift you describe when the PicoGUS is in GUS mode. On those systems the exact same thing happens on a real GUS (but perhaps not as pronounced)!

That does speak for the accuracy of the emulation 😁

polpo wrote on 2024-01-18, 21:46:

vutt wrote on 2024-01-18, 19:27:

Decided to test v2 PicoGUS joystick part.
With GUS digital FX enabled on doom engine games (doom 1&2, heretic, hexen) and Raptor I'm getting slow joystick drift. It's very well visible on Raptor main hangar screen - cursor is slowly moving across screen. https://youtu.be/ucRI0906izg

I have some systems where there is the exact joystick drift you describe when the PicoGUS is in GUS mode. On those systems the exact same thing happens on a real GUS (but perhaps not as pronounced)!

So it's all good then. Good emulation.

This made me wonder can we request Single-Cycle DMA clicking "feature" for true purists here for SB emulation 😉

I have been scrolling around aliexpress looking at different spdif / I2S converters options for various projects I have been playing around with. Thought I might share some interesting modules and chips that might be useful for PicoGUS.

This I2S sample converter, the SRC4192I might be useful to have for digital integrations. Maybe inline to the main DAC or something to help with those pesky multi sample rates? It seems to support a very broad range of input formats. Even 20-bit which seems quite rare to me.
https://www.aliexpress.us/item/32568055192472 … 7Cquery_from%3A
https://www.aliexpress.us/item/32568059552544 … 7Cquery_from%3A

Also the AK4113
https://www.aliexpress.us/item/32568043459636 … m%3A#nav-review
What stands out to me with this module is the ability to mix four different spdif signals into one I2S. I have been looking for ways to combine CD-ROM spdif conversion into the mix of all this, but I also wonder if it could be useful in combining several other sound sources like classic sound card would.

Delphius wrote on 2024-01-22, 17:25:

I have been scrolling around aliexpress looking at different spdif / I2S converters options for various projects I have been pla […]
Show full quote

I have been scrolling around aliexpress looking at different spdif / I2S converters options for various projects I have been playing around with. Thought I might share some interesting modules and chips that might be useful for PicoGUS.

This I2S sample converter, the SRC4192I might be useful to have for digital integrations. Maybe inline to the main DAC or something to help with those pesky multi sample rates? It seems to support a very broad range of input formats. Even 20-bit which seems quite rare to me.
https://www.aliexpress.us/item/32568055192472 … 7Cquery_from%3A
https://www.aliexpress.us/item/32568059552544 … 7Cquery_from%3A

Also the AK4113
https://www.aliexpress.us/item/32568043459636 … m%3A#nav-review
What stands out to me with this module is the ability to mix four different spdif signals into one I2S. I have been looking for ways to combine CD-ROM spdif conversion into the mix of all this, but I also wonder if it could be useful in combining several other sound sources like classic sound card would.

These are some interesting chips but for example the SRC4192I costs more than all of the other chips on the PicoGUS put together. I can imagine some kind of future "PicoGUS Gold" at a higher price point with SPDIF output, an audio codec with mixer, multiple RP2040 chips to perform each function, etc... (rasz_pl mentioned this idea a little while ago).

This project is open source – I welcome anyone who wants to make a "PicoGUS Gold" but for the moment I'd prefer to put my time into improving the firmware on the current board. There's a lot of stuff I want to do, in rough priority order:
- Improve compatibility (this is always at the top of list)
- SB 2.0 support
- Increase the repertoire of supported HID joysticks
- Conflict checking in pgusinit
- NE2000 support on Pico W
- Support multiple PicoGUS cards in the same system
- Tandy DAC support
- Optimize OPL3 support enough to run, opening up SBPro/SB16/WSS compatibility