I've adapted my post to the edit of yours, so this doesn't cause even more confusion for others 😀

On your card (and everyone's, who got an older card version with similar reference placement): C9 (at the PSRAM on top) should be a 1nF and C10 (at the lower, smaller IC) should be 100nF.

If it's a later version (e.g. with the markings swapped or an updated 1.1.1 silk): the 1nF will be C10 and the 100nF will be C9 (here's the current gerber view from the repository):

My recommendation for easy building would be: don't even bother too much with the reference for the 1nF cap, simply put it next to the PSRAM and all other MLCCs are then 100nF anyways 😉

OK, let me replace C9 and C10 tonight while I wait for the SN74LVC1G00DBVR to arrive..

appiah4 wrote on 2023-07-20, 07:57:

The photo I posted ABOVE is not mine, it's from the PicoGUS git page.. the one on the bottom is mine, and on mine the top cap is […]
Show full quote

The photo I posted ABOVE is not mine, it's from the PicoGUS git page.. the one on the bottom is mine, and on mine the top cap is marked C9 (and likely populated 100nF in error) and the bottom cap is marked C10 (and likely populated 1uF in error) 🙁

To clarify, this his HOW IT SHOULD BE:

- Top should be C10, and populated with 1uF
- Bottom should be C9, and populated with 100nF (0.1uF)

Right?

Yes, correct.

Done. Still waiting on G00 to populate U7 and give the card another go 😀

Funny story, I accidentally removed C6 instead of C9 and had to replace that as well.. 🤣

I just found this project at the right time, I put an order for the PCB's in. Haven't ordered anything else yet as I chose the slow ship for the PCB's. Should be a fun project.

I installed the G00 at U7, plugged it back into my test bench and..

Great success! My soldering was (probably) faultless all along, I just failed to RTFM 🤣 Thanks to everyone who helped me out here, I'd never have noticed using the wrong IC at U7 by myself!

I tested it with Shareware Doom and both music and sound fx worked flawlessly for the 2-3 minutes I tested it. Amazing work @polpo, can't wait for the firmware update!

There you go!

Somehow I missed all the notifications for this thread, glad you discovered the rogue component @appiah4!

Sorry for the confusion about C9/C10... it was a real mixup on my end and I had old versions of the Gerbers checked into the GitHub repo for a long time. As you saw in my photos, the boards I made for myself and sent to a few other people match the v1.1.1 gerbers. The actual KiCad project files have had the "correct" labels for C9/C10 all this time, it was just the v1.1 gerbers that were wrong.

rafpereira wrote on 2023-07-19, 10:47:

I noticed that PicoGUS has a narrow ISA Bus working frequency range while testing it in a UMC 386DX board.

The docs say that 8.33MHz or below is required for PicoGUS. However the next firmware release uses a much faster CPU clock on the RP2040, so I have a feeling higher ISA bus speeds will be possible. Watch for a release sometime in the next 24 hours...

In other news, I've released a video about the new miniaturized version of the PicoGUS that I've created for the new Hand386 and Book8088 retro PCs. In the video I go over some of the hardware differences between the two different versions of PicoGUS. https://www.youtube.com/watch?v=wWUtMPxmKD8

I'll be having a batch of them made and made available at Tindie sometime soon, and I'll be attending VCF Midwest in September and will have some to sell there. The project is still open source of course and I've just merged the design files for this new version and the ISA adapter into the main branch on GitHub. This new board is 100% firmware compatible with the "full size" PicoGUS, so both versions are fully supported. 😁

Finally, it's release v0.7.0 of the PicoGUS firmware, the first since February!

https://github.com/polpo/picogus/releases/tag/v0.7.0

General:

• Runs the RP2040 at 400MHz. This allows for faster reaction to ISA events, holding IOCHRDY low for shorter time periods. This allows better performance for other ISA cards and may help run on faster ISA bus speeds.

GUS emulation:

• Higher clock speed enables much shorter interval before checking for IRQs. This should improve compatibility in titles that use IRQs and DMA.
• Fixes for Hand386 and other M6117D-based systems.

Tandy emulation:

• New emulation core contributed by Aaron Giles. This is the same core used in DREAMM and should result in better accuracy across all titles. or example, sound effects such as crickets chirping and meteor crash in Maniac Mansion and snoring in Zak McKracken sound much better.

CMS emulation:

• New emulation core contributed by Aaron Giles. This is the same core used in DREAMM and should result in better accuracy across all titles.
• Fixes issue with pitch of CMS sound being too high.

MPU-401 emulation:

• Misc optimizations might improve compatibility in some titles.

And there was MUCH rejoicing!

Awesome work polpo!

Out of curiosity, does PicoGUS get detected as a GUS PnP and run as such in Win9x? Is that eventually in the cards? Asking because I'm not sure whether to plug this into my Cx5x86-120 system (which means I'd have to replace the external MT32-Pi with a McCake, and route the PicoGUS to MK8330's L/I) or keep playing with it in my test bench and eventually move it to my Socket 7 Win95C system as a second fiddle to my AWE32/OPL3..

appiah4 wrote on 2023-07-24, 13:27:

Out of curiosity, does PicoGUS get detected as a GUS PnP and run as such in Win9x? Is that eventually in the cards? Asking because I'm not sure whether to plug this into my Cx5x86-120 system (which means I'd have to replace the external MT32-Pi with a McCake, and route the PicoGUS to MK8330's L/I) or keep playing with it in my test bench and eventually move it to my Socket 7 Win95C system as a second fiddle to my AWE32/OPL3..

My guess is if you run the Pico GUS init in your autoexec.bat of Win9x, you might be fine. Question is how compatible it is with the drivers...

appiah4 wrote on 2023-07-24, 13:27:

Out of curiosity, does PicoGUS get detected as a GUS PnP and run as such in Win9x? Is that eventually in the cards? Asking because I'm not sure whether to plug this into my Cx5x86-120 system (which means I'd have to replace the external MT32-Pi with a McCake, and route the PicoGUS to MK8330's L/I) or keep playing with it in my test bench and eventually move it to my Socket 7 Win95C system as a second fiddle to my AWE32/OPL3..

No, GUS PnP support isn't really in the cards. For one I don't think PSRAM bandwidth is high enough to support the mixing rates the Interwave is capable of, and I don't know if the Interwave requires to be in a 16-bit ISA slot. However, the PicoGUS works perfectly with the Windows 3.1 and 9x GF1 drivers. But when you're talking about those drivers, even "perfect" is not very good... My memories of the Windows 9x drivers with a real GUS included stuttering sound and instability, especially with DirectX titles. They're fun to play around with for a while on the PicoGUS, though.

Thanks guys. How about a COMMAND.COM window under Win9x? I could avoid all Win9x drivers, and presumably run PGUSINIT.EXE from a window, then run DOS games/demos inside that window?

Problems with FW 0.7

Removed picoGus from slot and programmed directly from usb port, card inserted in isa slot and using the provided pgusinit it reports good, picogus initialized with success but no sound on cmod or second reality. Verses demo doesnt start (No more sw was tried)
reflashing it on isa slot using pgusinit with /f option I can ear a beep for each dot on screen while flashing FW
CPU Via c3@800
256MB RAM
Board MSI MS-6153 Ver 2.1

Was working good with FW 0.6.1

P.S. PLEASE IGNORE THIS ---> for some reason the old firmware also does not output sound... Maybe the card developed some fault but initialize correctly and passes the ram verification tool

It's working with sound on 2nd reality on mine, but there is a repeating sample echo right in the intro tune.
Still need to play around a bit and see if the older FW doesn't have that.

Edit: It's in 0.6.1 also, so nothing new. Still needs some investigation if it can be remedied (bootup without any TSR, etc. didn't change it).

Edit2: This FW somehow fixed a sound distortion I had on a card version, I'm toying around with... now that's very nice!

Cubic Player 2.6.0a still hangs on the second or third tune selected and starts with a wrong note, which it doesn't do on a real GUS, but: CP1.7 seems to work perfectly fine.
A quick test with doom was also good.

jcarvalho wrote on 2023-07-24, 14:28:

P.S. PLEASE IGNORE THIS ---> for some reason the old firmware also does not output sound... Maybe the card developed some fault but initialize correctly and passes the ram verification tool

I once had one of those DACs with a lost channel - ended up simply being a bad soldering of the connector iirc - maybe worth redoing them (or the PCM5102 DAC).

Oh, and there is one common and easy to fall for mistake: make sure the cable is attached to the DAC's connector and not the more prominent MIDI port - that happened to the best of us... 😉

MJay99 wrote on 2023-07-24, 16:57:

jcarvalho wrote on 2023-07-24, 14:28:

P.S. PLEASE IGNORE THIS ---> for some reason the old firmware also does not output sound... Maybe the card developed some fault but initialize correctly and passes the ram verification tool

I once had one of those I2C DACs with a lost channel - ended up simply being a bad soldering of the connector iirc - maybe worth redoing them (or the PCM5102 DAC).

Oh, and there is one common and easy to fall for mistake: make sure the cable is attached to the I2C DAC's connector and not the more prominent MIDI port - that happened to the best of us... 😉

Which incidentally also produces some kind of noise!

root42 wrote on 2023-07-24, 17:26:

Which incidentally also produces some kind of noise!

Indeed, every time something is printed to the UART you can hear it as noise if you have your audio plugged into the MIDI connector. And when firmware is being flashed, it prints every time a block is programmed. So double check and make sure your audio is plugged into the line out jack.

This is one of the reasons I moved to a 2.5mm MIDI connector on the Hand386 version of the board. That jack size is also recommended by the MIDI Manufacturer's Association.