polpo wrote on 2024-03-28, 14:11:

Delphius wrote on 2024-03-28, 03:23:

Overall the balance is pretty great actually. It seems to work with in game controls that support it as well which is good. Excited to see what is coming up next for picogus and also the SB firmware. Looks like you might also be trying to get MPU running next to these / with other firmwares as well?

Next is to integrate USB mouse support (emulating serial mouse, but high speed so no lag like on a real serial mouse) that wbcbz7 contributed. Also yyzkevin is working on SBPro stereo DSP support. I don't have the skills to optimize Nuked-OPL3 enough to get OPL3 support, but emulating dual OPL2s is within the realm of possibility. This would allow SBPro 1.0 emulation. I also want to overhaul the USB joystick support to be able to expand the number of USB joysticks supported by PicoGUS. And of course there is the never ending quest to get GUS support working better on more chipsets. Thanks to someone here on Vogons I recently received a board with a problem chipset that I want to dive into.

Very exciting!

I also want to mention that Doom GUS is now working perfectly for me. I was able to get through a couple of levels with no problems, where as before it would freeze within about 30 seconds or so. Not sure if this changed with the last or previous patch.

Thanks to a very helpful member here on Vogons I now have a board with the SiS 85C471 chipset to test. In the demo Crystal Dream II, digistorm reported that the music would stop semi-randomly a few minutes into the demo, and lisabadcat reported that it would freeze completely at the sound card selection screen. I can't reproduce lisabadcat's issue but what digistorm describes happens exactly on the motherboard I have, even on the latest firmware with the more accurate timer. I'll be investigating this issue further.

polpo wrote on 2024-03-31, 04:01:

Thanks to a very helpful member here on Vogons I now have a board with the SiS 85C471 chipset to test. In the demo Crystal Dream II, digistorm reported that the music would stop semi-randomly a few minutes into the demo, and lisabadcat reported that it would freeze completely at the sound card selection screen. I can't reproduce lisabadcat's issue but what digistorm describes happens exactly on the motherboard I have, even on the latest firmware with the more accurate timer. I'll be investigating this issue further.

Very nice of him. Will be interesting to know what exactly the problem was.

First of all, thanks for the last update with SB support! I'm only regretting having the older 1.1 hardware PCB , because I'd really use the mpu capability if I had the wavetable header, is it possible to wire it up somehow adding the pin header? As the midi port is there, the points should be there, isn't it? If anyone can help I'd be really grateful.
Another question would be if it's possible to have the sound blaster sound effects along with the Gus music... Guess not but that would be amazing

marcushg85 wrote on 2024-04-01, 11:10:

First of all, thanks for the last update with SB support! I'm only regretting having the older 1.1 hardware PCB , because I'd really use the mpu capability if I had the wavetable header, is it possible to wire it up somehow adding the pin header? As the midi port is there, the points should be there, isn't it? If anyone can help I'd be really grateful.
Another question would be if it's possible to have the sound blaster sound effects along with the Gus music... Guess not but that would be amazing

Ive also been interested to add this to the 1.1 boards since i have a few and the option on the v2 is pretty useful especially when combined with a mt32pi wavetable board.
Ive been meaning to tone out the connector and see if a proto board with the connector could be bodged onto the pcb.

Hi all! I built a V1.2 board and it's been awesome, I particularly enjoyed playing Prince of Persia with a PS4 controller on an 8088 system (SB/ Adlib firmware).
But I am running into an odd issue, I can't get a single floppy controller to work properly , I tried multiple controllers on MBs ranging from an XT to a p3. The floppy drives pass the seek test on boot, but when it actually tries to read a disk, the activity light comes on but the drive doesn't even try to seek and eventually just errors out. The issue goes away as soon as I remove the picogus board...
All other cards that I could get my hands on work just fine, it's really just the floppy controllers.
I feel like I must be doing something silly, maybe something wrong with my soldering, but the board seems to work just fine apart from this issue. Has anyone experienced this issue?

Check DMA/IRQ Section i think the problem could be there.

notARobot wrote on 2024-04-02, 03:09:

Hi all! I built a V1.2 board and it's been awesome, I particularly enjoyed playing Prince of Persia with a PS4 controller on an […]
Show full quote

Hi all! I built a V1.2 board and it's been awesome, I particularly enjoyed playing Prince of Persia with a PS4 controller on an 8088 system (SB/ Adlib firmware).
But I am running into an odd issue, I can't get a single floppy controller to work properly , I tried multiple controllers on MBs ranging from an XT to a p3. The floppy drives pass the seek test on boot, but when it actually tries to read a disk, the activity light comes on but the drive doesn't even try to seek and eventually just errors out. The issue goes away as soon as I remove the picogus board...
All other cards that I could get my hands on work just fine, it's really just the floppy controllers.
I feel like I must be doing something silly, maybe something wrong with my soldering, but the board seems to work just fine apart from this issue. Has anyone experienced this issue?

Like matze79 suggested, this feels to me like an issue with DMA (I had a system with a bad DMA controller and would behave just like this when trying to use the floppy). The floppy controller uses DMA 2, but those DMA lines aren't brought to the DMA selection jumpers on the PicoGUS. On the v1.x boards they end at the debug header at the bottom of the board. Could you check to see if somehow something is shorted around the pads for the DRQ2 and DACK2 signals on that header? They're the 6th pads in from the left and right on the top row; I've circled them in the attached photo.

polpo wrote on 2024-04-02, 14:18:

notARobot wrote on 2024-04-02, 03:09:

Hi all! I built a V1.2 board and it's been awesome, I particularly enjoyed playing Prince of Persia with a PS4 controller on an […]
Show full quote

Hi all! I built a V1.2 board and it's been awesome, I particularly enjoyed playing Prince of Persia with a PS4 controller on an 8088 system (SB/ Adlib firmware).
But I am running into an odd issue, I can't get a single floppy controller to work properly , I tried multiple controllers on MBs ranging from an XT to a p3. The floppy drives pass the seek test on boot, but when it actually tries to read a disk, the activity light comes on but the drive doesn't even try to seek and eventually just errors out. The issue goes away as soon as I remove the picogus board...
All other cards that I could get my hands on work just fine, it's really just the floppy controllers.
I feel like I must be doing something silly, maybe something wrong with my soldering, but the board seems to work just fine apart from this issue. Has anyone experienced this issue?

Like matze79 suggested, this feels to me like an issue with DMA (I had a system with a bad DMA controller and would behave just like this when trying to use the floppy). The floppy controller uses DMA 2, but those DMA lines aren't brought to the DMA selection jumpers on the PicoGUS. On the v1.x boards they end at the debug header at the bottom of the board. Could you check to see if somehow something is shorted around the pads for the DRQ2 and DACK2 signals on that header? They're the 6th pads in from the left and right on the top row; I've circled them in the attached photo.
DMA2.jpg

Makes sense, thanks a lot for the suggestions, I will have a look later today and let you know what I find. I did try the board without the Pico installed and the floppy controller issue went away, so I don't think it's a flatout short, probably a bad IC...

TLDR: The issue is fixed, it was a solder bridge on U2, I checked for bridges 100x, but I clearly missed one.

So I did check the pins related to DMA 2, there were no shorts as expected, they are not even connected... So just for good measure I cleaned the board again with ipa and checked for bridges with a multimeter, and to my surprise I found one on U2, I believe it was between pin 18 and 17. It was such a tiny bridge that I basically cleared it with an x-acto knife with just a very light poke. I was initially wondering why the floppy controller wasn't working with my picogus, and as always with these things, now I am wondering how the heck was this working so well in the first place. There were plenty of warnings and advises on the build guide on how to detect and avoid bridges with SMD soldering, so I should have known better...

Thank you so much for the help, I really appreciate it! The fixed picogus in now in my IBM 5160 and working flawlessly.

marcushg85 wrote on 2024-04-01, 11:10:

First of all, thanks for the last update with SB support! I'm only regretting having the older 1.1 hardware PCB , because I'd really use the mpu capability if I had the wavetable header, is it possible to wire it up somehow adding the pin header? As the midi port is there, the points should be there, isn't it? If anyone can help I'd be really grateful.

It was mentioned somewhere here (or may be at github) by Polpo:
It is impossible due using ready-made picoPi module. Only naked RP2040 chip allows additional lines to connect wavetable header. So, all of us, users of 1.x versions, dream about upgrade to ver. 2.0 )))

marcushg85 wrote on 2024-04-01, 11:10:

Another question would be if it's possible to have the sound blaster sound effects along with the Gus music... Guess not but that would be amazing

Connect picogus to line-in of natural sound blaster. Or use two of picoguses and mix the signals ))

Oh, really, Is it possible to use two picoguses in one machine?

By the way, SB emulation is a great improvement to picogus. One card makes so many great things without decreasing of performance of main machine... Why I've bought awe64 last week? I don't need it now )))

Thank you, Polpo, it is a great project.

André 2-3 wrote on 2024-04-03, 04:45:

It was mentioned somewhere here (or may be at github) by Polpo:
It is impossible due using ready-made picoPi module. Only naked RP2040 chip allows additional lines to connect wavetable header. So, all of us, users of 1.x versions, dream about upgrade to ver. 2.0 )))

When I looked into Pico for use in C64 cartridges I remember figuring out how to reuse 1 or 2 gpio lines used by default for led and some stupid power stuff.
there it is https://github.com/cknave/c64-pico-ram-interface/issues/1
GPIO29/GPIO25 GPIO24/GPIO23
>GPIO25 will be usable after desoldering R3, same with GPIO24 and R1 R10, GPIO29 removing Q1, GPIO23 will require two small trace cuts next to TP4 pad on the underside.

so you can totally mod 1.x to 2.0

With the wavetable header, the only thing I use extra GPIOs for on the 2.0 board is for software control of the wavetable volume. Volume control with a regular stereo potentiometer is possible, and it's what I do on the ISA adapter for the "Femto" PicoGUS (see attached image). Once you figure out a good volume balance you probably don't need to set it very often. On the WT header you'll need +5V, +12 and -12V (some WT boards just use +5V), and reset (I have a real reset circuit in my design but it's fine to just tie it to +5V). You'll need to mix the output of the wavetable header with the audio output of the DAC on the PicoGUS. You can get the TTL MIDI data from the UART TX connector on the PicoGUS.

Note that there are MIDI to wavetable adapters like Serdaco's CHiLL but they cost more than a PicoGUS 2.0 card. https://www.serdashop.com/CHiLL

Did some testing with my Toshiba T5200 (pimped with Ti486SXL2-40).

What fully works with SB-firmware:
-Prince of Persia
-FastDoom
-Indy500
-Rampart
-Wing Commander
-Wolfenstein 3D
-Crystal Dream 1 (demo)
-Panic by Future Crew (demo)

Not working, and some of these are hard to get working anyway with real SB, speed sensitive and so on:
-Dynablaster, no digitized sound effects
-Gods, some of intro music digitized samples dont fully play
-LHX, dont detect adlib at all, reverts to pc speaker with "adlibsound" option

But this is the best sound card for older systems, GUS and SB on one card, it's all you need.

Now you have Sound Blaster working, would it also be possible to create a firmware for Covox / LPT DAC emulation? It would make this Swiss army knife even more Swiss army knifey 😉 There should also already be emulation code available in DOSBox etc.

digistorm wrote on 2024-04-08, 09:11:

Now you have Sound Blaster working, would it also be possible to create a firmware for Covox / LPT DAC emulation? It would make this Swiss army knife even more Swiss army knifey 😉 There should also already be emulation code available in DOSBox etc.

why do You need Covox emulation? much more fun can be earned by making this simple circuit. You already have real hard LPT port, right? )))

André 2-3 wrote on 2024-04-09, 15:33:

digistorm wrote on 2024-04-08, 09:11:

Now you have Sound Blaster working, would it also be possible to create a firmware for Covox / LPT DAC emulation? It would make this Swiss army knife even more Swiss army knifey 😉 There should also already be emulation code available in DOSBox etc.

why do You need Covox emulation? much more fun can be earned by making this simple circuit. You already have real hard LPT port, right? )))

More for the sound quality. I have the adapter from Serdashop but it still depends on the quality of the I/O controller I guess. On my Slot A motherboard it is particularly bad, sounds like bits are missing (although the LPT port works fine with other peripherals).
Edit: and it would free up the IRQ for the PicoGUS. How is that for a paradox? 😉

Covox would be trivially easy and kind of why I haven't done it, it's so simple it almost doesn't deserve its own firmware mode. 😅 I'd probably want to also support Disney Sound Source which is a little bit more complex.

@polpo -

Maybe consider a socket for an AD1848JP for your next revision and implementing WSS concurrently with SB mode? Pretty please?

Whole point of using rp2040 is that chips like AD1848 are easy to implement in software