just a quick question, can we use ESP-PSRAM64H instead of APS6404L-3SQR-SN , looks like pinout and specs are same.

https://www.espressif.com/sites/default/files … atasheet_en.pdf

bazingaa wrote on 2023-06-07, 08:24:

just a quick question, can we use ESP-PSRAM64H instead of APS6404L-3SQR-SN , looks like pinout and specs are same.

https://www.espressif.com/sites/default/files … atasheet_en.pdf

Looks very similar. However you would need the H variant because of the 3.3V supply voltage. Both seem to use 1K pages and seem to work up to 133MHz.

bazingaa wrote on 2023-06-07, 05:03:

I am planning to build one when time permits 😀 Is there any OPL3 emulator project we can integrate with this ? 😀

edit:ordered 5 PCBs in white colour for a change 😉

appiah4 wrote on 2023-06-07, 07:00:

Isn't Nuked-OPL3 open source and pretty much perfect?

I've tested several OPL3 emulators including Nuked and they are all far too slow to run on the Pico as-is. Getting one running fast enough would take an optimization effort similar to the heroic job Graham Sanderson performed on the emu8950 OPL2 emulator for rp2040-doom. I've hacked on ymfm the most because its source code is the most understandable to me but it still uses 200-300% of one core to play music of any complexity. Someone smarter than me would have to be up to the task of optimizing OPL3 emulation to be fast enough. I have a feeling it's possible, but I'm not up to the job.

bazingaa wrote on 2023-06-07, 08:24:

just a quick question, can we use ESP-PSRAM64H instead of APS6404L-3SQR-SN , looks like pinout and specs are same.

https://www.espressif.com/sites/default/files … atasheet_en.pdf

Yes, the ESP-PSRAM64H is listed as an acceptable substitute in the BOM (see the notes column). There are several PSRAM chips that are functionally the same and they are all listed.

polpo wrote on 2023-06-07, 09:21:

I've tested several OPL3 emulators including Nuked and they are all far too slow to run on the Pico as-is. Getting one running fast enough would take an optimization effort similar to the heroic job Graham Sanderson performed on the emu8950 OPL2 emulator for rp2040-doom. I've hacked on ymfm the most because its source code is the most understandable to me but it still uses 200-300% of one core to play music of any complexity. Someone smarter than me would have to be up to the task of optimizing OPL3 emulation to be fast enough. I have a feeling it's possible, but I'm not up to the job.

Bummer. I'm sure you would crack it eventually, it can't be more sophisticated than emulating a whole GUS. But then, it's not really worth the effort, PicoGUS is pretty easy to use with a second ISA card. That said, I would have really enjoyed having a Line Out header on the PicoGUS so that I could route it to a second sound card internally, now that I think of it..

root42 wrote on 2023-06-07, 09:13:

bazingaa wrote on 2023-06-07, 08:24:

just a quick question, can we use ESP-PSRAM64H instead of APS6404L-3SQR-SN , looks like pinout and specs are same.

https://www.espressif.com/sites/default/files … atasheet_en.pdf

Looks very similar. However you would need the H variant because of the 3.3V supply voltage. Both seem to use 1K pages and seem to work up to 133MHz.

polpo wrote on 2023-06-07, 09:21:

I've tested several OPL3 emulators including Nuked and they are all far too slow to run on the Pico as-is. Getting one running f […]
Show full quote

bazingaa wrote on 2023-06-07, 05:03:

I am planning to build one when time permits 😀 Is there any OPL3 emulator project we can integrate with this ? 😀

edit:ordered 5 PCBs in white colour for a change 😉

appiah4 wrote on 2023-06-07, 07:00:

Isn't Nuked-OPL3 open source and pretty much perfect?

I've tested several OPL3 emulators including Nuked and they are all far too slow to run on the Pico as-is. Getting one running fast enough would take an optimization effort similar to the heroic job Graham Sanderson performed on the emu8950 OPL2 emulator for rp2040-doom. I've hacked on ymfm the most because its source code is the most understandable to me but it still uses 200-300% of one core to play music of any complexity. Someone smarter than me would have to be up to the task of optimizing OPL3 emulation to be fast enough. I have a feeling it's possible, but I'm not up to the job.

bazingaa wrote on 2023-06-07, 08:24:

just a quick question, can we use ESP-PSRAM64H instead of APS6404L-3SQR-SN , looks like pinout and specs are same.

https://www.espressif.com/sites/default/files … atasheet_en.pdf

Yes, the ESP-PSRAM64H is listed as an acceptable substitute in the BOM (see the notes column). There are several PSRAM chips that are functionally the same and they are all listed.

Thanks a lot for the information. Hope we can sort out the OPL3 soon. I was watching project videos from the beginning of the project 😀
I ordered both GY-PCM5102 (AU$2.89 each at https://www.aliexpress.com/item/1005002898278583.html) and APS6404L-3SQR-SN (AU$1.54 each at https://www.aliexpress.com/item/1005003308679029.html) from Aliexpress, I couldn't find them cheaper in any other place.

Thanks for such a great project! I've ordered parts and should be able to build it soon.

What's the accuracy on the GUS compared to real hardware? (I'm specifically looking forward to the Second Reality demo)

That's also disappointing about the Nuked OPL3 code. When I'm looking at these projects I'm always hoping they are extremely accurate and that seems to be the best, but even having an accurate GUS card will be fantastic!

Speaking as another PicoGUS user: I don't have an original GUS so I can't speak from experience, re: exacting accuracy. To be honest I don't think the robust experimental data exists yet, beyond "it sounds right". There is for example no mdfourier test, or similar, comparing the two! Correct me if I'm wrong.

In my anecdotal travels, I've seen plenty of PicoGUS user comments that are perfectly satisfied with the results but I've also (very rarely) seen a user comment-or-two (e.g. on Youtube) which claimed inaccuracy. Based on which version, I do not recall - which sums up my view on the overall question: the accuracy seems good, but afaik we don't really have deep analytical data or consensus yet.

Some minor inaccuracies in other modules (e.g. CMS/Tandy) are known and, afaik, are works in progress. e.g. see the recent live stream working on improving the CMS module by adapting a better 3rd-party implementation.

But one underlying factor is the origins of the sound emulation code. For example the PicoGUS's GUS is an adaptation of the GUS emulation code that was made for, and/or used in, DOSBox. So, in theory - and notwithstanding any changes made - the PicoGUS's GUS is about as accurate as DOSBox's emulated GUS, and in general brings with it the code-based pros and cons of that implementation.

Thanks for the reply!

I've looked around and I can't find too many GUS emulations besides DOSBox either. I know it also exists in 86Box/PCem but they probably just ported the same code.

In my humble opinion, accuracy is quite good. I have a real GUS and to my ear the sound is right on. I've listened to songs hundreds of times on my real GUS as well as on PicoGUS and my ear for picking out differences is pretty good. One thing to mention, though: in the most recent couple firmware releases, I use the RP2040's hardware interpolators to reduce CPU usage at the cost of slightly less accuracy. The GUS has 9 fractional bits of inter-sample resolution while the RP2040 hardware interpolator has 8. In almost all cases, you can't tell the difference, but I've noticed a few songs that sound slightly bit off, especially chiptunes. I'll be going back to CPU-based interpolation in the next release. Another factor that can cause inaccurate playback is bugs in DMA sample upload... these are usually audible in chiptunes and only very occasionally.

The landscape of GUS emulation code that is out there is actually quite diverse! The GUS emulator that PicoGUS uses is from DOSBox-X, albeit with many modifications by me at this point. DOSBox-X's GUS emulator has diverged quite a bit from the original DOSBox code, mainly to increase playback accuracy and compatibility with niche demos. Jon Campbell has put a lot of effort into improving DOSBox-X's GUS accuracy, comparing it against his GUS MAX.

Also in the DOSBox lineage is DOSBox-staging's emulator, which is also quite different from the original DOSBox GUS emulator... And then PCem and 86Box have their own GUS emulation, developed independently from the DOSBox lineage. A look at the code shows it is very different! And then MAME also has its own emulator. I've read all of them in depth... it's great having multiple independently developed examples of GUS emulation to draw from and get a good idea of what's going on under the hood on the actual GF1.

Edit: I just discovered that qemu uses code from GUSemu, which I didn't even realize was made open source. So that's yet another GUS emulator...

Thanks for the information and for all the hard work on this amazing project! I'm glad to see that you care about accuracy and I look forward to seeing each improvement!

By the way, do you have a donation page? I tried to look couldn't find anything.

sofakng wrote on 2023-06-11, 14:48:

By the way, do you have a donation page? I tried to look couldn't find anything.

I've finally added a Ko-fi link to my Github. Also I'd gladly take any motherboard donations, as I'd just use any monetary donations to buy any motherboards with chipsets I don't have to test on. 😀

Where do you live Ian? Asking to figure out shipping costs

Also, what platforms do you need?

polpo wrote on 2023-06-12, 01:55:

sofakng wrote on 2023-06-11, 14:48:

By the way, do you have a donation page? I tried to look couldn't find anything.

I've finally added a Ko-fi link to my Github. Also I'd gladly take any motherboard donations, as I'd just use any monetary donations to buy any motherboards with chipsets I don't have to test on. 😀

Finally!! Now we can help

appiah4 wrote on 2023-06-12, 05:12:

Where do you live Ian? Asking to figure out shipping costs

Also, what platforms do you need?

I'm in the US, Colorado specifically (as evidenced by the flag on the back of the PicoGUS). The biggest need was a VIA MVP3 chipset Super Socket 7 board, as I've gotten multiple reports of DMA issues on those. I currently have one purchased on eBay on the way to me, but it's untested so I'm not sure if it will work. Also in this thread, JazeFox reported problems with an OPTi 82C495SLC chipset motherboard, so one with that or a similar chipset would be very useful.

Here's what I have currently or have on the way:
- XT: NEC chipset XT clone board, not yet tested
- 386SX: C&T NEAT chipset, tested good with PicoGUS, HAND 386 w/ M6117D SoC, not yet tested (but known to have issues with RESET signal)
- 486: ALi M1419, tested good with PicoGUS; SiS 85c496, not yet tested (board needs repair due to battery damage)
- Socket 7: Intel 430FX, tested good with PicoGUS; Intel 430VX, tested good with PicoGUS
- Super Socket 7: ALi Aladdin V, tested good with PicoGUS; VIA MVP3, not yet tested (but problems are reported)

I don't have any Slot 1/S370 boards, but I'd guess Intel chipsets would work fine, so I'd be most interested in non-Intel chipset boards.

You are too far away for me to feasibly donate boards I'm afraid 🙁 I'll be sure to buy you a Ko-Fi at some point though 😀

Hi Ian!
Can we expect a new firmware release soon? More on the GUS side emulation?
Thanks!

I'm still thinking about the Nuked OPL3 implementation...

You said the Pico is too slow but what about if we can overclock it a bit?

jcarvalho wrote on 2023-06-14, 19:05:

Hi Ian!
Can we expect a new firmware release soon? More on the GUS side emulation?
Thanks!

I mentioned GUS improvements in the livestream that I had last month, but after looking at the state of the code... all of my supposed "improvements" were commented out. 😓 I had been experimenting with a different way of locking the GUS state when certain bus events came in, similar to how DOSBox-derived do it, but it resulted in stuttering audio on the GUS.

Due to family obligations I've had to be away from working on things so there has been no recent progress. The last thing I was experimenting before having to leave was more extreme overclocking of the RP2040 above its default speed of 125MHz. PicoGUS's firmware normally runs at 280MHz, and I was seeing how the GUS emulation behaved at speeds up to 420MHz. I was getting some really promising results, as the speed allows me to check for IRQs with every sample generated. I'll be picking that back up and tweaking that approach once I'm back at my workbench in a few days. I do worry a little bit about such an extreme overclock, however the RP2040 remained ever so slightly above ambient at such speeds.

sofakng wrote on 2023-06-16, 04:06:

I'm still thinking about the Nuked OPL3 implementation...

You said the Pico is too slow but what about if we can overclock it a bit?

I haven't tried Nuked at the extreme overclock but I did try ymfm's OPL3 – it's still not quite fast enough even rendering audio at half the normal sampling rate. I can try Nuked but I'm not hopeful, given the report in the rp2040-doom writeup saying it consumes 300% of one of the RP2040 cores at 270MHz.

Can the Pi Pico be used with heatsinks to ease the burdeon of overclocking? The IC is pretty small, but I guess one of the smaller heatsinks from a Pi 3 heatsink kit could be used?

Also, there is no multithreaded OPL3 emulation? That is strange..

Just got PCBs from JLC PCB (USD 9 for 5 PCB including shipping) and SRAM, DAC from Aliexpress 😁 Gonna order other parts from Digikey and build it 😀
I plan to build one as GUS and other one as OPL. I think I don't need the SRAM to be soldered for the OPL one ? isn't it ?