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.