Hah, I have put off adding Covox/Disney Sound Source support exactly because it would be so easy... maybe now is the time to actually do it!

Naw, do the GUS DMA first!! 😁 😁 (Just kidding man, you choose!)

I've got some PCBs on the way, to be able to start playing soon.

polpo wrote on 2022-12-12, 16:08:

I've released v0.1.0 of the PicoGUS firmware: https://github.com/polpo/picogus/releases/tag/v0.1.0 […]
Show full quote

I've released v0.1.0 of the PicoGUS firmware: https://github.com/polpo/picogus/releases/tag/v0.1.0

- More compatibility! Nearly every program that does not use DMA now works. See the Compatibility List for the latest status on what works: https://github.com/polpo/picogus/wiki/Compatibility-list
- AdLib and MPU-401 emulation modes. I'm looking into enabling these modes via runtime configuration but for now they are separate firmwares.
- New version of pgusinit.exe to tweak problematic programs. Currently the only tweak is changing the audio rendering buffer size. Some programs behave better with a smaller or larger buffer than the default of 16 samples.

Now that I'm finally mostly happy with IRQs, I'll start on getting DMA working again. It was working on the prototype hardware design, so I'm hopeful it won't be a major undertaking.

I'll start building mine tonight, so just in time!

Any tips for a novice with a simple soldering pen? 😁

appiah4 wrote on 2022-12-13, 08:05:

I'll start building mine tonight, so just in time!

Any tips for a novice with a simple soldering pen? 😁

For the small surface mount components, the technique of applying flux to the board, wetting the tip of my soldering iron with solder, holding the component down with tweezers and then drag soldering the ICs or just touching the pads on either side of the passives has worked best for me. Magnification helps a lot if you don't have very youthful eyes. Check for bridges with a multimeter and remove them with a bit more flux and a clean iron tip or some solder wick. The TSSOPs can hide bridges under the legs.

Good luck, let us know how it goes!

Firmware v0.2.0 is here, hot on the heels of v0.1.0...
https://github.com/polpo/picogus/releases/tag/v0.2.0
* Solved a regression where lots of channels playing 16-bit samples would cause audio stuttering (example: the demo Aeon Drift by Disaster Area). Added a super simple sample pair buffer per channel to solve this.
* Super-unstable DMA support preview. Count on it to fail, but feel free to celebrate when it works! 😅
* Fixed a small bug in pgusinit.exe that didn't set the audio buffer size to 16 if the `/a` option was not given on the command line.
* Includes firmwares for GUS port 220, 240, and 260.
* Built with a new automatic release script.

DMA support means at least one game that didn't work before now starts and is playable: Star Control II. There are sample glitches, so I only consider this a preview to show that progress is being made... I didn't actually expect it to work. I was shocked when the game started playing music when I ran it!

Video of how things are working as of firmware v0.2.0: https://youtu.be/F5Zk_hHHkTg

polpo wrote on 2022-12-15, 03:33:

Firmware v0.2.0 is here, hot on the heels of v0.1.0...
***
* Super-unstable DMA support preview. Count on it to fail, but feel free to celebrate when it works! 😅

Went ahead and tried a couple of different things to see what does not work and what doesn't either. 😁
First I tried Doom. Didn't work. BUT - didn't crash with the "Dude, the GUS ain't responding." but froze on "calling DMX_init"

Second I tried Tyrian2000. Didn't work, threw message about GUS not existing.

To test the music I had to load ULTRAMID.EXE TSR, so I tried it just for funs and giggles. To my suprise - it did work! Didn't previously.

But - the only thing it produces are clicks. I believe the samples are not being uploaded correctly to the memory but I am nowhere near expert enough to understand what it is trying to do. Took a video of it instead. Here is a test of BLOOD. Duke3D did the very same thing since they both run on the same engine. From the HDD activity it loads all the data to the memory and then plays the music but only clicks can be heared.
https://youtu.be/T7RpE3n-feY

And lastly I tried Hocus Pocus. Only clicks, the same way as all the other games. But if you know the Apogee logo sound, you can clearly hear the tempo in the clicks. Just the notes themselves are missing.
https://youtu.be/cIy2I4avtr0

That is awesome progress! From not working at and crashing everything to running and being detected on all fronts - that is incredible progress. I think you are just a tiny step away from making it work 100%.

Thanks for all of those testing results, @krivulak! I've tried Doom and it now fails in exactly the same way, so that's actually encouraging. ULTRAMID loading is surprising and good news.

How DMA is actually supposed to work is probably the least documented part of the GUS hardware docs, and the DMA as implemented in DOSBox and other GUS emulation implementations are written with the expectation that they can peek into the state of the system's DMA controller, so this has been the most challenging part. I've had to do bus captures with my real GUS in the system to see what's actually happening on the bus and see what's being written to the DMA control registers on the GUS.

FYI Tyrian2000 expects ultramid to be loaded manually before starting it (even for digital audio only). A lot of other "ultrasound compatible" games rely on it too but use an embedded version.

I've found the main reason why DMA is not working – port IO can occur in the period of time between the GUS asserting DRQ and it getting DACK in return. Handling this properly has been challenging, as timing in this situation can be really tight. The high latency of writing to PSRAM is a big hurdle here. I've tried two strategies: interleaving DMA handling in my polling for IO events, and handling DMA on the 2nd core. For the first, the PSRAM writes are causing me to miss IO events, and for the second the PSRAM writes mean I starve the mixing routines for time. I think being a bit smarter with IOCHRDY in the 1st strategy will be the way forward.

polpo wrote on 2022-12-21, 20:48:

I've found the main reason why DMA is not working – port IO can occur in the period of time between the GUS asserting DRQ and it getting DACK in return. Handling this properly has been challenging, as timing in this situation can be really tight.
***

Maybe this is the reason why the original hardware has separate memory controller?

Has anyone found a suitable PSRAM chip anywhere other than Mouser? (I mean currently in stock, available to purchase in small quantities.)

If not, then it looks like my choice of component store is already decided. 😀

It can be found on Aliexpress.

I actually just ordered the parts a few days ago and ended up getting the PSRAM from mouser also.

Interestingly the BoM also lists this part in the digikey column: 870-ISS1M8BLL-104NLI
Seems to be an 8Mbit instead of 64Mbit, but it's also out-of-stock at Digikey, but available on mouser (just more expensive).

Funny enough, the BoM tool on Mouser has somehow managed to put both of them into the basket.

MJay99 wrote on 2022-12-30, 09:35:

It can be found on Aliexpress. […]
Show full quote

It can be found on Aliexpress.

I actually just ordered the parts a few days ago and ended up getting the PSRAM from mouser also.

Interestingly the BoM also lists this part in the digikey column: 870-ISS1M8BLL-104NLI
Seems to be an 8Mbit instead of 64Mbit, but it's also out-of-stock at Digikey, but available on mouser (just more expensive).

Funny enough, the BoM tool on Mouser has somehow managed to put both of them into the basket.

Thanks, I found it on Aliexpress, also the SN74CB***** chips which I was having trouble finding local.

Now begins the Aliexpress Wait.

Shreddoc wrote on 2022-12-30, 09:18:

Has anyone found a suitable PSRAM chip anywhere other than Mouser? (I mean currently in stock, available to purchase in small quantities.)

If not, then it looks like my choice of component store is already decided. 😀

I got mine from LCSC: https://www.lcsc.com/product-detail/SRAM_Lyon … IT_C261881.html

P.S. Mr. @polpo recommended me this part. I have yet to finish soldering my card so I can't say it works 100%, but I'd trust his word on it 😀

Ack, I need to correct the BOM CSV then - the ISSI 870-ISS1M8BLL-104NLI part is only rated for 104MHz. I was hoping it'd tolerate being overclocked to the 133-140MHz that the PicoGUS runs it at, but at that speed it's not reliable. Samples are somewhat recognizable so it kind of works but it's definitely not fast enough. I was hoping it'd work because ISSI is the only SOIC PSRAM that Digikey sells, and I generally prefer them.

The following parts I have tested and work:

APMemory APS6404L-3SQR-SN -available at Mouser
Lyontek LY68L6400SLIT - available at LCSC
IPUS IPS6404L-SQ-SPN - not generally available
Espressif ESP-PSRAM64H - not generally available

Adafruit has a "generic" PSRAM, model 4677, that is one of the above 4 chips, but is out of stock and has been for a long time. Digi-Key also sells it but it has also been out of stock with no restock in sight.
PJRC, makers of the Teensy, also sells one of the 4 above chips here.

Aliexpress links, hopefully these are ok :

PSRAM, APS6404L-3SQR-SN
https://www.aliexpress.com/item/1005003308679029.html

SN74CB3T3257
https://www.aliexpress.com/item/1005004921069864.html

People in North America or Europe will generally source these from Mouser et al. But for others, e.g. in Asia/Pacific region, Aliexpress might be useful to pick up the couple of BOM items that local outlets such as element14 don't have.
-----------
^^Hindsight Edit: Mouser might still be the better choice, if you can push your order up enough to qualify for free shipping. The key advantage being that they're probably the only place from which you can get everything (barring the PCM5102A DAC) at one time.
-----------

I'm looking forward to building a card or three. Everything is sourced now. But, based upon delivery times, I won't be building until February.

The PCBs are here already. JLC is fast. Such a cool service.

Update: Due to how I've seen DMA events actually happen on the ISA bus, I can't rely on IOCHRDY to slow down DMA events as I wait for writes to PSRAM to complete. However, I have another idea in mind: when sample RAM is written to via ISA DMA, a DMA event is kicked off on the RP2040 which will allow the write to PSRAM to complete in the background with no CPU intervention. I have this working on a Pico with attached PSRAM, but I won't be able to test in a real computer until I return from visiting family for the holidays.

Shreddoc wrote on 2022-12-30, 21:45:

The PCBs are here already. JLC is fast. Such a cool service.

Since I have LCSC part numbers in the BOM for all of the SMT parts, it wouldn’t take much more effort or cost to have JLC do all of the SMT assembly. I was holding off on doing that until I was 100% confident in the hardware design, but I’m feeling good about it. I’ve also thought about doing a revision that uses an RP2040 directly. That would gain a couple GPIOs for some extra bus signals like ALE. FreddyV’s PicoMEM uses ALE to get a head start on address decoding, which could gain ~50ns or so extra time for each bus event. I don’t think it’s really necessary for GUS or other sound card emulation, but it would be nice to have.

Using the RP2040 directly sounds pretty neat. It would look more tidy then as well. Only thing that would be weird would be the DAC then, which will be a separate PCB.

I still have to solder my PicoGUS. Should be the next assembly project. Maybe the DMA code is done by then. 😁