Rawit wrote on 2026-03-26, 08:04:

The Wavetable Pi is also noisy in my experience. Had those "computer thinking" noises. Tried some fixes from the GIT repository but no cigar.

I assembled my own WavetablePi boards in a similar manner to this, just that I additionally moved the caps to the other side as well, leaving only resistors whose height is negligible on the side of wavetable connector, eliminating any possibility of conflict with components on sound cards.

The resulted board would be much thicker that will occupy the adjacent slot, but it's not an issue for ISA sound cards plugged into dISAppointment.

I'm not sure about the possible causes of the noises regarding WavetablePi... perhaps my ears are not sharp enough to be aware of any. It's possible this different way of assembling the board might have resulted in a different, less noisy atmosphere.

NeoG_ wrote on 2026-03-27, 00:30:

Makes me glad I paid the extra for a WP32 😬

WP32 is amazing good in terms of output clarity, yes.

Linoleum wrote on 2026-03-26, 23:49:

Especially when you have an i2c oled screen installed I found...

Removing that was the first thing I tried. But then I noticed that the noise was different using the SF2 mode vs the MT-32 mode so it was coming from the Pi.

Rawit wrote on 2026-03-26, 08:04:

The Wavetable Pi is also noisy in my experience. Had those "computer thinking" noises. Tried some fixes from the GIT repository but no cigar.

Could moving the wavetable card away using a flat cable help?

Nitram78 wrote on 2026-03-27, 10:11:

Rawit wrote on 2026-03-26, 08:04:

The Wavetable Pi is also noisy in my experience. Had those "computer thinking" noises. Tried some fixes from the GIT repository but no cigar.

Could moving the wavetable card away using a flat cable help?

I doubt it, this sounds like an issue with filtering and shielding on the audio channels. Someone like @dreamblaster @LABS or @keropi would probably explain better.

The way I ended up taming the noise was by doing two things:
A) bumping up the gain in the config file, and
B) lowering the MIDI output level in the card’s mixer.
With that combo, the noise floor is no worse than what you’d get from a typical Sound Blaster.

Flywheel wrote on 2025-09-12, 15:56:

Has anyone tried or have had success simultaneously using a USB mouse and CD-ROM emulation through a powered USB hub? I have tried with a couple of modern USB hubs but do not currently have a 1.1 hub to test with. I have been able to use the mouse functionality through one of my two modern hubs but neither would detect the USB sticks as a CD-ROM. Both work just fine when plugged in directly to the Picogus.

I've tried that with different USB hubs, too. But the USB mouse and a USB flash drive for the CD-ROM function don't work at the same time. In single use you can switch them around any time. But when both are plugged in, neither of them works anymore.

I didn't have much issue with simultaneous mouse and USB flash drive on a hub myself, but Delphius's fixes should help that for those who are having problems. It'll be out in a new firmware very soon, in addition to Sound Blaster 16 and OPL3 support.

While we're on the topic of the WavetablePI, I've noticed mine has a bit of a sag - anyone else propped theirs up at all?

polpo wrote on Yesterday, 15:39:

I didn't have much issue with simultaneous mouse and USB flash drive on a hub myself, but Delphius's fixes should help that for those who are having problems. It'll be out in a new firmware very soon, in addition to Sound Blaster 16 and OPL3 support.

Will the SB16 DSP follow the hardware closely including the faulty SB Pro stereo issue or was that fixed in the SB16 DSP that was used as a base for the new firmware?

DJNW wrote on Yesterday, 18:10:

While we're on the topic of the WavetablePI, I've noticed mine has a bit of a sag - anyone else propped theirs up at all?

I folded up some card stock into a square tube and stuck it between the wavetable board and the PicoGUS PCB using some low strength double sided tape to keep it straight

NeoG_ wrote on Yesterday, 21:52:

polpo wrote on Yesterday, 15:39:

I didn't have much issue with simultaneous mouse and USB flash drive on a hub myself, but Delphius's fixes should help that for those who are having problems. It'll be out in a new firmware very soon, in addition to Sound Blaster 16 and OPL3 support.

Will the SB16 DSP follow the hardware closely including the faulty SB Pro stereo issue or was that fixed in the SB16 DSP that was used as a base for the new firmware?

SB Pro stereo works fine, unlike on a real SB16. The emulation not a 1:1 emulation of a specific DSP in that it's not running the actual 8051 code - think more DOSBox-like. You'll be able to set the DSP version using pgusinit, and that could possibly change different behavior, but right now all that does is change whether the "speaker on" command is honored or not, because the SB16 ignores that command and some titles don't bother with that command. The main target is to have an "SB16" that "just works" no matter if you use it as an SB 1.5, 2.0, Pro 2.0, or SB16. So that means an MPU with no hanging note bug, supporting SB Pro stereo, etc.

what about the high dma, does it have to be shared and the game has to support assigning the same dma?

Pickle wrote on Yesterday, 22:51:

what about the high dma, does it have to be shared and the game has to support assigning the same dma?

It works just like a ViBRA 16XV card - there is no high DMA. 99% of the time you can just set the high DMA to be the same as the low DMA - it's not "shared" per se, it just tells the game to use the 8-bit DMA for 16-bit sound. Some games like Duke3D need some coaxing to use a low DMA for 16-bit sound, but it's possible.

polpo wrote on Yesterday, 22:39:

SB Pro stereo works fine, unlike on a real SB16. The emulation not a 1:1 emulation of a specific DSP in that it's not running the actual 8051 code - think more DOSBox-like. You'll be able to set the DSP version using pgusinit, and that could possibly change different behavior, but right now all that does is change whether the "speaker on" command is honored or not, because the SB16 ignores that command and some titles don't bother with that command. The main target is to have an "SB16" that "just works" no matter if you use it as an SB 1.5, 2.0, Pro 2.0, or SB16. So that means an MPU with no hanging note bug, supporting SB Pro stereo, etc.

Left field question, I have been thinking about putting an RS232 dry contact relay board to control various stuff inside one of my boxes (like a 15khz scanline emulator). One of the limitations I have is that sound blaster is not good on IRQ2/9 (many games don't allow the IRQ) and MPU401 intelligent mode requires IRQ 2/9. SoftMPU can't translate the IRQ either. Do you think the PicoGUS card would mind having the IRQ jumpers externally controlled so I can change the IRQ assignment on the fly while the system is operating but idle?

NeoG_ wrote on Yesterday, 23:23:

Left field question, I have been thinking about putting an RS232 dry contact relay board to control various stuff inside one of my boxes (like a 15khz scanline emulator). One of the limitations I have is that sound blaster is not good on IRQ2/9 (many games don't allow the IRQ) and MPU401 intelligent mode requires IRQ 2/9. SoftMPU can't translate the IRQ either. Do you think the PicoGUS card would mind having the IRQ jumpers externally controlled so I can change the IRQ assignment on the fly while the system is operating but idle?

I generally wouldn't recommend this because the IRQ jumper carries the actual IRQ signal. Depending on how far out you extend it you may run into issues. Or maybe it'll be fine, who knows. Changing it on the fly shouldn't be a problem.

One thing you should try is CTS SwapIRQ: it's a TSR that redirects one IRQ to another. It's worked on every single game that requires IRQ 2/9 with MPU-401 intelligent mode that I've tested. The only downside is that it is very annoying nagware. I've thought that it's likely due for a modern rewrite as it can't be too hard to implement. There's a Vogons thread about it here: SwapIRQ

polpo wrote on Yesterday, 23:52:

I generally wouldn't recommend this because the IRQ jumper carries the actual IRQ signal. Depending on how far out you extend it you may run into issues. Or maybe it'll be fine, who knows. Changing it on the fly shouldn't be a problem.

One thing you should try is CTS SwapIRQ: it's a TSR that redirects one IRQ to another. It's worked on every single game that requires IRQ 2/9 with MPU-401 intelligent mode that I've tested. The only downside is that it is very annoying nagware. I've thought that it's likely due for a modern rewrite as it can't be too hard to implement. There's a Vogons thread about it here: SwapIRQ

I came across CTS SwapIRQ while looking at my options, but I don't think I could handle the nagware aspect as a perment solution. If the registered version could still be purchased that would be a much easier option.

I'd probably end up sticking a 5v relay (e.g. Pansonic TQ2SA-5V high frequency relay) to the back of the PCB just above the jumper block to switch between two IRQ states and extend the 5V control back to the RS232 controller. Hopefully with only a couple of centimetres of additional travel the signal integrity should be good enough. I'm also going to try the same thing with the motherboard's FSB jumpers.

NeoG_ wrote on Today, 00:34:

I'm also going to try the same thing with the motherboard's FSB jumpers.

I've made a simple, manual switching harness for SS7 motherboard FSB and multiplier jumpers in the past. No issues were encountered, and those jumpers did not care about wire length. The goal was merely so I could set those externally while the machine was powered off, however - nothing on the fly.

These days I tend to connect a Throttle Blaster to my main S(S)7 system, as a bit of a godmode speed dial. They work well as a semi-permanent installation on a particular machine. Just one of many options.

Shreddoc wrote on Today, 01:36:

NeoG_ wrote on Today, 00:34:

I'm also going to try the same thing with the motherboard's FSB jumpers.

I've made a simple, manual switching harness for SS7 motherboard FSB and multiplier jumpers in the past. No issues were encountered, and those jumpers did not care about wire length. The goal was merely so I could set those externally while the machine was powered off, however - nothing on the fly.

These days I tend to connect a Throttle Blaster to my main S(S)7 system, as a bit of a godmode speed dial. They work well as a semi-permanent installation on a particular machine. Just one of many options.

Did you make a youtube video about it? I remember seeing a video of someone making an FSB switchblock a while ago and thought they did demonstrate it switching with the system on

NeoG_ wrote on Today, 08:56:

Shreddoc wrote on Today, 01:36:

NeoG_ wrote on Today, 00:34:

I'm also going to try the same thing with the motherboard's FSB jumpers.

I've made a simple, manual switching harness for SS7 motherboard FSB and multiplier jumpers in the past. No issues were encountered, and those jumpers did not care about wire length. The goal was merely so I could set those externally while the machine was powered off, however - nothing on the fly.

These days I tend to connect a Throttle Blaster to my main S(S)7 system, as a bit of a godmode speed dial. They work well as a semi-permanent installation on a particular machine. Just one of many options.

Did you make a youtube video about it? I remember seeing a video of someone making an FSB switchblock a while ago and thought they did demonstrate it switching with the system on

No Youtube video, though I might have posted about it on Vogons before. I'm sure other people have done similar endeavours, probably more sophisticated than mine, which was merely a couple of DPDT switches in a drive bay panel configured to allow 4 combinations of FSB/Multiplier. I never thought about testing it live before.