So I was working on a new build with my i430VX and I decided to use my PicoGUS in it for MPU midi. Seems to be working perfectly now with every firmware. No issues with initializing.

I will have to verify if this is a compatibility issue or something else. I was doing some cleaning and testing with it before vacation so I will need to try this in my other motherboards to be certain. I am also using a newer firmware release so maybe that had something to do with it.

PicoGUS hardware v1.2 is now released!

Release notes:

A new release of the more DIY friendly version of PicoGUS "backporting" improvements from the v2.0 board.

• Adds option for integrated DAC section. The purple "GY PCM5102" DAC modules have spotty QA, so integrating the DAC is both potentially lower cost and more reliable. Footprints remain to still allow use of the DAC module.
• Reset stability improvements: RC circuit on Pico RUN pin to delay start on power up and filter out glitches on ISA reset, and U5 is now 74AHC logic family for higher positive-going threshold
• ISA RESET has weak pulldown to allow reliable programming the Pico outside of powered PC
• DACK has weak pullup to allow PicoGUS to be used without DMA channel set
• 5V MIDI circuit: uses open drain inverter for better drive and uses more commonly available resistors
• U2 is now specified as an 74LVC244 in the BOM: it's cheaper and more available and in my testing performs just as well as the 74CB3T3245
• Jumper to apply power to micro USB-B connector on Pico to allow USB HID devices to be used
• Fixes to card dimensions to better follow ISA card specs: narrower card edge and better fit for card bracket in PC cases
• Production files for JLCPCB full PCB assembly
• Updates to thank you section on back

Gerbers and JLCPCB PCBA production files are available in the release at https://github.com/polpo/picogus/releases/tag/hw_v1.2. I'll be updating the build guide and Mouser and Digikey cards for the new release in the coming days.

BTW, a restock of PicoGUS 2.0 boards on my Tindie store should be relatively soon, probably next week.

I guess I don't feel quite adventurous enough to build a v1.2 while v1.1 works perfectly in my 486 but I'd love to see someone else do it and report back with any compatibility or audio quality improvements from the reset and dac integration changes 😀

Instead of the PCM5102 DAC, could a WM8804 S/PDIF transceiver chip (or something similar) be wired to Pico's i2s to get digital output and would that work with PicoGUS? Picture attached of a PI hat with WM8804 chip.

janih wrote on 2023-12-14, 08:22:

Instead of the PCM5102 DAC, could a WM8804 S/PDIF transceiver chip (or something similar) be wired to Pico's i2s to get digital output and would that work with PicoGUS? Picture attached of a PI hat with similar chip.

Ooh, I'm all for using something like this as a breakout board, maybe connected to the PicoGUS with a ribbon cable, to provide optional SPDIF out 😁

janih wrote on 2023-12-14, 08:22:

Instead of the PCM5102 DAC, could a WM8804 S/PDIF transceiver chip (or something similar) be wired to Pico's i2s to get digital output and would that work with PicoGUS? Picture attached of a PI hat with WM8804 chip.

no need, rp2060 can do spdif in/out in software, only 1 gpio required.
out https://github.com/mill1000/raspdif
in https://github.com/elehobica/pico_spdif_rx

rasz_pl wrote on 2023-12-14, 11:25:

no need, rp2060 can do spdif in/out in software, only 1 gpio required. out https://github.com/mill1000/raspdif in https://github […]
Show full quote

janih wrote on 2023-12-14, 08:22:

Instead of the PCM5102 DAC, could a WM8804 S/PDIF transceiver chip (or something similar) be wired to Pico's i2s to get digital output and would that work with PicoGUS? Picture attached of a PI hat with WM8804 chip.

no need, rp2060 can do spdif in/out in software, only 1 gpio required.
out https://github.com/mill1000/raspdif
in https://github.com/elehobica/pico_spdif_rx

Nice, so based on the "raspdif" repo for spdif output, I need to connect SPDIF port to GPIO21 (or GPIO31) and make some ALSA configuration to output audio to it. Would this work in a seamless manner with PicoGUS?

I'd bet that with a proper wiring and PIO hackery it's more than possible to output S/PDIF through MIDI Out header/jack :) the only issue is GUS emulation drops sample rate wien using more than 14 channels (down to 19 kHz for 32 channels), and I am not sure if SPDIF receivers will handle those rates properly.

polpo wrote on 2023-12-14, 05:53:

PicoGUS hardware v1.2 is now released!

Do you have plans to add the wavetable connector to this design of the pcb?
Or what are you thoughts of mod'ing < 1.2 v with an connector.

appiah4 wrote on 2023-12-14, 06:51:

I guess I don't feel quite adventurous enough to build a v1.2 while v1.1 works perfectly in my 486 but I'd love to see someone else do it and report back with any compatibility or audio quality improvements from the reset and dac integration changes 😀

If your v1.1 board works fine for you, there's really not much improvement in v1.2! Audio quality should be the same, as long as you get a purple DAC module that actually works... they can be flaky.

wbc wrote on 2023-12-14, 12:11:

I'd bet that with a proper wiring and PIO hackery it's more than possible to output S/PDIF through MIDI Out header/jack 😀 the only issue is GUS emulation drops sample rate wien using more than 14 channels (down to 19 kHz for 32 channels), and I am not sure if SPDIF receivers will handle those rates properly.

Coax through the MIDI out jack wouldn't be possible due to its open drain circuit, but optical toslink out via an adapter is totally possible since after all, MIDI receivers are just blinking an LED in an optoisolator. There's code for spdif audio out in the pico_extras audio library that I use that would just drop in but like wbc says, the issue is non-standard sampling rates. GUS *might* be able to be forced to 44.1kHz (I still need to experiment with this) but OPL2 is at a totally weird 49.716kHz. Resampling to 44.1 or 48kHz on the Pico probably wouldn't give you the best quality so I'm not super excited about that. It does make me wonder what the Orpheus cards do for their SPDIF output... Tandy and CMS are constant 44.1kHz so those would probably "just work." It's kind of ironic that the lowest-fi audio modes are the ones that are easiest to have SPDIF output. 😄

Pickle wrote on 2023-12-14, 13:36:

Do you have plans to add the wavetable connector to this design of the pcb?
Or what are you thoughts of mod'ing < 1.2 v with an connector.

I have no plans to add wavetable to this type of PCB... that's what the v2.0 board is for in my mind. I do have a more "DIY-able" wavetable design with passive volume control on the Femto Edition's ISA adapter, and I welcome anyone who wants to try a design based on that.

Only the original GUS (GF1) reduced the output sample rate when more channels were enabled. The AMD Interwave (used on the Orpheus) still uses the lowered rate for input but then resamples to the fixed output rate.

jmarsh wrote on 2023-12-14, 18:24:

Only the original GUS (GF1) reduced the output sample rate when more channels were enabled. The AMD Interwave (used on the Orpheus) still uses the lowered rate for input but then resamples to the fixed output rate.

Indeed, I was wondering how it handles the 49.716kHz rate of the OPL3.

There is nothing wrong with resampling if done correctly. It got bad rep with broken hardware implementations like Creative Labs Sound Blaster Live! or lazy coding https://github.com/dosbox-staging/dosbox-staging/issues/1673.

Just a quick update, my picogus seems to be working fine in all my computers now so the issue before was not a compatibility problem. Maybe it was because I was using older 0.7 firmware by accident?

jmarsh wrote on 2023-12-14, 18:24:

Only the original GUS (GF1) reduced the output sample rate when more channels were enabled. The AMD Interwave (used on the Orpheus) still uses the lowered rate for input but then resamples to the fixed output rate.

if I am reading the OrpheusII page correctly, the Interwave chip analog output is hooked to CS4237 Synth input, and the Crystal chip is responsible for S/PDIF output.
The Interware IC also supports routing wavetable synth data to the serial audio output port, with support of rates lower than 44100 Hz in GUS compatible modes:

rasz_pl wrote on 2023-12-14, 11:25:

no need, rp2060 can do spdif in/out in software, only 1 gpio required.
out https://github.com/mill1000/raspdif
in https://github.com/elehobica/pico_spdif_rx

I assume this was a typo and you meant `rp2040`? Because I can't find any reference to a successor to the rp2040 chip (or a "Raspberry Pico 2") having been released yet, at the time of this writing.

digger wrote on 2023-12-15, 12:16:

I assume this was a typo and you meant `rp2040`?

yes, of course 😀

rasz_pl wrote on 2023-12-15, 04:04:

There is nothing wrong with resampling if done correctly. It got bad rep with broken hardware implementations like Creative Labs Sound Blaster Live! or lazy coding https://github.com/dosbox-staging/dosbox-staging/issues/1673.

I agree – I just worry about the RP2040 having enough horsepower to do high quality resampling on top of everything else it's doing. A simple linear interpolation-based approach would be possible especially since it could rely on the RP2040's interpolator peripheral, but anything fancier than that may not be possible.

While I'm eagerly waiting for restocking it's "nitpicking Sunday" 😀 time for me.

Q: polpo, is PicoGUS isa connector edge rounding/shaving (my English's failing on me here) oversight or cost cutting measure?
Asking because other modern replica isa cards like Blasterboard and Orpheus have it(attached pic) so PCB houses are able to do it...

vutt wrote on 2023-12-17, 10:29:

Q: polpo, is PicoGUS isa connector edge rounding/shaving (my English's failing on me here) oversight or cost cutting measure?
Asking because other modern replica isa cards like Blasterboard and Orpheus have it(attached pic) so PCB houses are able to do it...

The common term is edge chamfering or beveling. It was an oversight in my original design. In the PicoGUS v1.1 and v1.1.1 design, the distance from the edge of the board to the "fingers" is 0.2mm. The card edge design was inherited from another open source ISA card project. This distance is too short for most PCB houses to reliably do chamfering (for example here are JLCPCB's guidelines). Sometimes they can do it at that distance, sometimes they can't, or sometimes they will edit the design for you if you specify you want chamfering. To fix this, starting with the PicoGUS Femto ISA adapter, PicoGUS v1.2 and v2.0, I've been using a larger distance for the fingers so the PCB houses can do chamfering reliably. All PicoGUS boards I've sold personally have chamfered edge connectors.

Edit: one thing to note is that chamfering is not part of the PCB design and is something you have to specify in the options when placing the PCB order.