First of all, thank you for this great project. I enjoyed reading about it since the beginning! It's awesome! 😀
I decided to build a few PicoGUS cards for my systems recently, and finally I got them working (with some headaches in the process, read below if you are interested!).
I found some problems (and solutions) that may be of your interest for the project, or could help someone having the same symproms I observed.
Short story (conclusions):
1- Caution with overclocking. Not all Picos are equal. And SPI flash is very sensitive.
2- Sometimes hardware (chips) can be just defective.
3- Motherboard chipset matters. Some are very compatible with PicoGUS, some aren't (yet, I hope 😁)
Long story (full explanation):
1- My first PicoGUS had a very strange behaviour....
When I built my first PicoGUS, I flashed it the usual way, USB to computer, drop UF2 file and voilà!
Tested GUS implementation with some different systems and wow, it worked very well (well, not in some chipsets, like VIA, read it in point 3 later if you are interested). Games like Descent, Tyrian and Epic pinball... Sound programs like Cubic Player (classic), Impulse Tracker or Grind.. Very good GUS support! 😀
Then I wanted to change to MPU firmware to test it with my MT-32. Aaand... ouch! Trying to flash in DOS with pgusinit failed. Well, computer just freeze completely after "Programming" word (no dots printed after it). What's happening? In addition, flash is corrupted and must be re-flashed via USB.
I tried with different boards (486, Pentium, K6-2..) but I always got the same result. Then I thought... maybe I did something wrong when building the card... I checked multiple times... hmmm nope, It's OK. Just in case, I built a second PicoGUS (that one failed to work, and then I fixed it, but if you are interested in that story, read point 2).
The second (repaired) PicoGUS worked flawlessly... and flashing in DOS with pgusinit worked like a charm! Hmmm... what's happening then with the 1st PicoGUS?
Well, as emulation (GUS, Adlib and MPU) is working perfectly, first thing to think about is the flashing procedure. Pico Flash seems to be OK, because flashing via USB is working well and the firmwares are working...
Next step is to do some debugging... I connect the PicoGUS UART header to my FTDI serial-USB adapter and started monitoring (btw I learned the hard way that the serial output is only working correctly with GUS firmware).
Ok, running pgusinit flash procedure... the debug output stops at "numBlocks: xxx".
Then I check source code...
In pico_reflash.c below the numBlocks printf, the part of the calls to flash_range_erase and/or flash_range_program should be the conflicting point.
I added some additional printfs to locate the exact point of failure, and it's flash_range_erase. After some investigation, I tried, as suggested in Pico forums, to wrap flash writing functions between save_and_disable_interrupts() and restore_interrupts() (In this case it could be not needed, but, just in case...). Recompiled, flashed via USB... tried pgusinit flash... no change. Same symptoms.
Next step... tried to do per-block erase prior to every block write instead of full erase at start (as suggested in Pico forums too). Result: well, some improvement there. Now with pgusinit, i got some blocks written before freezing (between 5 and 15 blocks every time I tried pgusinit). Strange...
As the 2nd PicoGUS I built is working well, I start thinking if the 1st Pico is defective or something.. but then, after checking picogus.cpp i see the overclocking and I got it... it could be that... Maybe this Pico is not as overclockable as others? 280Mhz is a lot! Ok, I tried different values for the set_sys_clock_khz in the main() and as expected, too low values turn the card undetectable to pgusinit or the flashing procedure had errors... then I found the "sweet" value: 240Mhz. Flashing with pgusinit finished OK! All the times.
Ok, I guess that GUS/MPU/.... emulation won't be as good as it it's with Pico at 280Mhz,so I left set_sys_clock_khz(280000) as is in picogus.cpp and then added the change to 240Mhz just before the flashing procedure in pico_reflash.c. Once flashed and reset, the Pico will be back to 280.
Done. It worked flawlessly. I don't know if this particular Pico board will last a lot of time at 280.. but well, at least it seems to be working well this way. I guess there are more Pico boards like this out there...
Anyway, SPI flash in general is not very reliable at high speeds. So it's better to be cautious with overclocking.
My humble suggestions for the firmware: 1- To "underclock" only in the flashing procedure to make it more reliable in any case. Good for every Pico. 2- To add the per-block erase and then block-write in every block cycle. 3- If needed, just to be safe, use save_and_disable_interrupts() and restore_interrupts() with the flashing functions. 4- Use the minimum needed overclocking in every emulation firmware, to preserve the life of the Pico.
2- Sometimes hardware can be just defective (2nd built PicoGUS)
When I built my 2nd PicoGUS to troubleshoot the 1st (if you read the point 1) It was not working:
- pgusinit detected it, is able to flash it in DOS but with GUS firmware, i got the error "ERROR: Card not responding to GUS commands on port 240"
- With Adlib and MPU firmwares I don't get pgusinit errors, but...
- GUS , MPU and Adlib emulation are not working. Silence or detection errors in games.
First thing I do is to re-check my soldering work... It's OK, even under the microscope. Anyway, I resolder. No change.
I tried with a different Pico board... no change.
Analyzing the situation... why detection and flashing with pgusinit is working then? Hmm... I see in sources that PicoGUS firmware talks to ISA BUS with fixed address ports (control, data...): $1Dx , and emulation (GUS, Adlib and MPU) are usually using $2xx, $388, $3xx .. hmm what's the difference there? It seems to be the bit 9... not needed in the PicoGUS base address.
Just to be sure... I got my logic probe and checked the buffer chip (U2) in the PicoGUS board... guess what? Normal activity on all pins except pin 12... "RA9", which is completely dead.
Yes, it was a defective chip. I replaced with a new one and boom! Everything is working!! 😀
3- Motherboard chipset matters.
Well, about this topic I have a lot more to test (only did basic testing and for a very short period of time), but for now, this is what I observed testing PicoGUS in different chipsets:
- Intel chipsets (Tested FX and VX Pentium chipsets): Working perfectly with 120Mhz and 200Mhz CPUs.
- 486 chipset ALi M1429G: I have 2 boards with this chipset. PicoGUS is working perfectly in one board, and then pgusinit show PicoGUS not detected in the 2nd board. This 2nd board has some corrosion, so I should fix that and retest (Anyway other sound cards like ALS, ESS, SB16 are working well... weird...). Both with an intel DX2/66.
- 486 chipset OPTi 82C495SLC + F82C206. Detected and initialized OK, but GUS emulation is not working well. some games can't detect the card, others run, but with glitched sound. Patch loading fails in descent and also in Ultramid. Descent's setup test of digited sound works however. Changes to BIOS didn't help either.
- K6-2 300 in VIA VT82C598MVP + VT82C586B: Bad. Similar symptoms as the OPTi chipset. Patch loading in Ultramid and Descent is always failing. Some games run well like Epic Pinall, but others don't, some output garbled sound and other freeze. Tried every option in BIOS related to timing, also tried different FSB speeds, nothing helps.
Well, that's all for now. I know this is a very loong post. Anyway, if it is useful for helping with something, I'll be happy.