polpo wrote on 2023-02-13, 04:06:

polpo wrote on 2023-02-12, 04:42:

Emulating Tandy 3 Voice would be pretty easy! FreddyV has mentioned it as a possibility to me before. 🙂 Also emulating the Tandy DAC should be possible.

Yep - getting Tandy 3 Voice running on the PicoGUS was no problem. https://youtu.be/_a-0G00XdgA

After reading about patching games and port redirection TSRs for Tandy sound, my head is kind of spinning. That was the hardest part of getting this working, to be honest... 😅 This is running on port 2C0 just like Matze79's TNDY card can.

Okay now I have to build one of these. I have a Tandy 1000 , PC Jr, OG GUS, etc but there s something about this project that is awesome. Would you change any of the hardware design knowing what you know now??

polpo wrote on 2023-02-12, 04:42:

640K!enough wrote on 2023-02-08, 08:27:

I don't know if you're aware of them, but there are some titles that don't work well (or at all) beyond a certain amount of local GUS DRAM. Do you have any facility to tell your firmware to limit available DRAM? I would assume that, if you were interested in such a feature, it could be configured via pgusinit?

I'm not aware of any in particular. If you could point some out to me, that would be great. Adding an option to pgusinit to limit the emulated GUS DRAM should not be a problem!

I thought a few demos were mentioned as well, but one title that was definitely problematic was Absolute Pinball.

polpo wrote on 2023-02-12, 04:42:

640K!enough wrote on 2023-02-05, 02:58:

Have you had a chance to test GUS DMA-streamed audio on the ALi board yet?

I've now tested it quite a bit – I got some stuttering in Doom but I've worked around the issue. I haven't seen any egregiously bad behavior on the ALi board, really. The only odd behavior I saw was the strange inability to flash the Pico, and freezing of the demo X14 at a certain point. And then the flashing issue was a one-off: the next time I tried it a couple days later it worked just fine. And the issue in X14 only happened with one of my CPUs.

I don't know if that was limited to the different versions of the P5A(-B), or if it had something to do with their configurations or previous damage. I just found it strange that two people had similar systems with the same symptoms. Since they had a reputation for certain differences, I thought it might have been caused by the ALi chipset, but your testing results seem to suggest otherwise.

When will a firmware update with DMA fixes and Tandy support be available? 😁

*camps out on sidewalk outside Polpo's house, waving "Release The Firmware Hostages!!1" placard*

But seriously, the awesome work continues, great news on the Tandy front.

Can it play multiple cards simultaneously?
GUS And Sn76489 or OPL2 ?
Will it also play Tandy DAC?

Does it emulate PC Speaker too ? Lot of Tandy games use speaker as additional channel

polpo wrote on 2023-02-13, 04:06:

polpo wrote on 2023-02-12, 04:42:

Emulating Tandy 3 Voice would be pretty easy! FreddyV has mentioned it as a possibility to me before. 🙂 Also emulating the Tandy DAC should be possible.

Yep - getting Tandy 3 Voice running on the PicoGUS was no problem. https://youtu.be/_a-0G00XdgA

After reading about patching games and port redirection TSRs for Tandy sound, my head is kind of spinning. That was the hardest part of getting this working, to be honest... 😅 This is running on port 2C0 just like Matze79's TNDY card can.

Amazing! PicoGUS is quickly becoming an all-in-one emulator for hard to find sound cards. First GUS, Adlib and MPU-401 - and now Tandy.

Yeah Adlib isnt really hard to find, neither is tandy. You always could upload pcb data to jlc and build one

flynnsbit wrote on 2023-02-13, 05:06:

Okay now I have to build one of these. I have a Tandy 1000 , PC Jr, OG GUS, etc but there s something about this project that is awesome. Would you change any of the hardware design knowing what you know now??

There are a few things I'd change – number one would be putting the RP2040 directly on the board instead of a Pico to gain 4 more GPIOs. That'd let me use the ALE ISA bus signal to gain 50-100ns more address decoding time, and allow for 1 more DMA and IRQ channel. But what both of those would bring I'd only consider "nice to haves." Studio 8502 is designing a version of the PicoGUS with an RP2040 and is thinking of using the extra GPIOs for a gamepad port.

matze79 wrote on 2023-02-13, 08:26:

Can it play multiple cards simultaneously? GUS And Sn76489 or OPL2 ? Will it also play Tandy DAC? […]
Show full quote

Can it play multiple cards simultaneously?
GUS And Sn76489 or OPL2 ?
Will it also play Tandy DAC?

Does it emulate PC Speaker too ? Lot of Tandy games use speaker as additional channel

Nothing can play simultaneously yet, but it's on my roadmap. Some cards like the GUS are intensive enough to emulate that I don't see them easily coexisting with other cards, but other things like Tandy, OPL2, CMS, and Covox are so simple or so optimized that they should be able to coexist and mix together with no problem.

Tandy DAC should be possible... from looking at DOSBox-X's implementation, it's fairly simple. I might give Tandy DAC a go as a proof of concept for streaming DMAed sound before I work on Sound Blaster DAC.

Good point about emulating PC Speaker – I'd have to snoop on the programming of channel 2 of the PIT to handle it but I think it'd be possible. This emulation would operate in parallel to the PC's actual speaker output – the current hardware design wouldn't allow you to connect the speaker and mix it like your board does.

polpo wrote on 2023-02-13, 21:50:

There are a few things I'd change – number one would be putting the RP2040 directly on the board instead of a Pico to gain 4 more GPIOs.

Theoretically, there's options with all GPIOs exposed, like this:
https://lectronz.com/products/rp2040-stamp

There's also versions on Aliexpress with more GPIOs exposed - albeit with a different pinout also. I've modified a Kicad footprint for it and put it onto a breakout board, but am still in the progress of ordering a replacement eeprom for that Pico, since the 16MB SOP one it came with doesn't seem to be working properly (one of those unlabeled Chinesium things). I've swapped it to the tiny eeprom the original pico came with, which made it work, but I'm rather interested in a less microscopic work 😀 Putting the RP2040 directly onto a card would also help, of course.

By the way, were you able to reproduce the issues I saw while trying FW 0.4.0 (e.g. Doom 2 starting to sound distorted after a level jump, e.g. by 'idclev 22', etc.)?

I've tried different mainboards, two different PicoGUS cards and also different configs, but ran into this consistently.

polpo wrote on 2023-02-13, 21:50:

Good point about emulating PC Speaker – I'd have to snoop on the programming of channel 2 of the PIT to handle it but I think it'd be possible. This emulation would operate in parallel to the PC's actual speaker output – the current hardware design wouldn't allow you to connect the speaker and mix it like your board does.

there existed sound cards doing just that, mediavision being one of them https://en.wikipedia.org/wiki/Media_Vision_Pr … #Other_features

Just in theory... would it be possible to add an sd slot to the SPI lines used for the sample ram (requires finding a pin for the SD CS) in order to add ATAPI IDE emulation? Seems like a logical step since there's already a DAC hooked up for CDDA output...

Edit: Actually nevermind... realized that would require the high data lines / a lot more GPIOs.

FreddyV is working on drive emulation in his PicoMEM project. So far it is looking extremely promising: https://forum.vcfed.org/index.php?threads/pic … -board.1241199/

I have a feeling that the best route to creating an optical drive emulator on a Pico that works in DOS wouldn’t involve emulating ATAPI. The Sony/Panasonic/Mitsumi interfaces are much simpler and might be a good option. That or a completely custom interface with a driver that interfaces with MSCDEX.

polpo wrote on 2023-02-18, 17:28:

FreddyV is working on drive emulation in his PicoMEM project. So far it is looking extremely promising: https://forum.vcfed.org/index.php?threads/pic … -board.1241199/

That project also looks like it's 8-bit only, so would have the same limitation/issue. While it's possible to replace INT13 functions for disk access, that doesn't apply for CD-ROMs.

I have a feeling that the best route to creating an optical drive emulator on a Pico that works in DOS wouldn’t involve emulating ATAPI. The Sony/Panasonic/Mitsumi interfaces are much simpler and might be a good option. That or a completely custom interface with a driver that interfaces with MSCDEX.

I wasn't looking for a DOS only solution (or even a PC only solution; IDE is basically a subset of ISA signals...), hence the target being IDE/ATAPI.

Hi!

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.

JazeFox: Thank you very much for your very detailed feedback and suggestions! I appreciate the time that you took to do all of this testing and experimentation.

Overclocking and Flash:

This YouTube video and its followup were how I got a good feel for what I felt was safe and appropriate for overclocking the Pico. In his video with his particular Pico, he lost communication with the flash above 300MHz, and the 280MHz that I run at is pretty close to that. In normal operation with my firmware, the Pico copies the program from flash (due to PICO_COPY_TO_RAM being set to 1) and then overclocks, so if the flash is unstable at that particular frequency, it doesn't show up until flashing from DOS with pgusinit. BTW the followup video to the above video he fixes access to flash above 300MHz by increasing the clock divider for the QSPI peripheral to 4 from its default of 2. The datasheet for the flash chip used on the Pico says it's rated for 133MHz, so at the stock clock divider of 2 with my 280Mhz overclock, the flash would be running at 140MHz, above that rated speed. So in my next firmware release (which I was about to do, so your post was very timely!) I will clock the Pico down during flashing. The point about disabling interrupts is a good one. I didn't put that in because I have been assuming that interrupts shouldn't be firing during flashing (no timers or DMA events will be happening) but it's good to be extra safe so I'll disable interrupts as well.

As for risk to the Pico itself from overclocking, I run at the stock voltage of 1.1V, so I feel it is quite safe. At 280MHz at 1.1V the Pico should be drawing ~28mA instead of the ~20mA at the stock frequency of 125MHz. I've toyed with the idea of raising clocks even higher (I can always use more speed so I can react to bus events faster) but I didn't feel comfortable with needing to raise the voltage. If you look at the code you can see a commented out line for raising Vreg...

Motherboard chipset matters

I've done almost all of the development of PicoGUS on boards with Intel 430FX and 430VX chipsets, with a Pentium 120 and Pentium MMX 166. I've recently increased my selection of testbenches with an ALi M1419 486 board and an ALi Aladdin V Super Socket 7 board. I also have a 386sx20 with a C&T chipset that I test on very occasionally.

From what you describe, most of the strange behavior you're seeing is related to ISA DMA. I've found that the idealized timing diagrams for ISA DMA in almost all of the references I've read don't always match with real behavior from chipsets. For example, on my Intel chipsets I've found that DMA data is not latched when IOW is asserted, and I must wait to read it until IOW is deasserted. I imagine that things could vary even more on other chipsets, so I'd have to do some captures with my logic analyzer on boards with those other chipsets to see what the timing is like.

I can get more motherboards with varying chipsets to test on, especially to add the common ones. I may have to put up a Ko-Fi link or something on the GitHub repo to help fund this because I've already sunk quite a lot into this project between the multiple motherboards, logic analyzers, and parts I've bought. And eBay prices keep going up and up... BTW I had a couple computers with VIA chipsets back in the 90s and I always had problems with strange behavior and instability. Those are some retro memories I'd rather not relive, so I've specifically avoided buying them.

I think I should add a list of known compatible and incompatible chipsets on the project wiki at the very least.

Another thing to keep in mind, and something I will be highlighting in the documentation in the future: the PicoGUS is sensitive to ISA bus timing. Running at 10MHz is questionable, and above that will give you silence. Running the ISA bus 8.33MHz or below is a hard requirement for PicoGUS.

Once again, thanks JazeFox for all of your great testing and insights!

jmarsh wrote on 2023-02-18, 10:56:

Just in theory... would it be possible to add an sd slot to the SPI lines used for the sample ram (requires finding a pin for the SD CS) in order to add ATAPI IDE emulation? Seems like a logical step since there's already a DAC hooked up for CDDA output...

Edit: Actually nevermind... realized that would require the high data lines / a lot more GPIOs.

It is what I did for the PicoMEM.
It need one other Pin for the SD Chip select
but if the disk emulation is active, GUS emulation will no more be possible.

@polpo Please do establish a Ko-fi link or some other way for the community to contribute towards development costs.

Hi All! Firmware v0.5.0 is finally out: https://github.com/polpo/picogus/releases/tag/v0.5.0
Firmware v0.5.1 is out: https://github.com/polpo/picogus/releases/tag/v0.5.1

This one had a lot of rabbit holes with regards to GUS compatibility, but DMA should be more reliable. Doom should no longer have the stuttering/slowdown issues and Ultramid programs should be much more reliable (not not quite perfect yet...).

Release notes:

General:

• More reliable firmware flashing from pgusinit by clocking down the Pico and disabling interrupts. Many thanks to JazeFox at Vogons for debugging this issue and suggesting a fix.

Tandy emulation:

• New emulation mode: Tandy 3-Voice. This emulation is on port 2C0h by default, to avoid conflicts or masked IO on the default Tandy port of 0C0h in non-Tandy systems. This is the same alternate port that Matze79's "TNDY" card can use. Use the TNDY driver program to redirect port 0C0h to 2C0h. Also many games need to be patched to allow for Tandy sound on non-Tandy systems with CGA, EGA, or VGA graphics. Note that this mode has not received much optimization, so accuracy and compatibility can be improved.

GUS emulation:

• Resets DMA status bit to 0 on completion of DMA handler. Fixes some Demoscene titles.
• Buffers uploaded DMA samples instead of writing 1 byte at a time. Currently this buffer is 8 bytes, and may be configurable in future releases. Should help stuttering/slowdown issues in games that use streaming DMA audio like Doom.
• Bails out on sound rendering when sample rate changes. This should eliminate any "warbling" sounds when Impulse Tracker resets the channel count on the fly.
• Uses the RP2040 hardware interpolation unit to interpolate samples and clamp output to 16 bits.

For known issues, please see the Compatibility List wiki page.

Edit: I've found a bug where firmware flashing from DOS does not work when the Tandy firmware is loaded. I'll release a fix for that soon.
Edit 2: The flashing issue with Tandy firmware is fixed in v0.5.1. There was also an issue with pgusinit not reporting the port correctly with Tandy firmware.

Just quickly checked Doom II level jumps on my testing rig - seems to indeed work perfectly now, really awesome, thank you!

Just a day after v0.5.x, firmware v0.6.0 is released! https://github.com/polpo/picogus/releases/tag/v0.6.0

Not much in the way of release notes for this one... just one line: it adds CMS/Game Blaster emulation support! Here's a video of it playing the Monkey Island title song: https://youtu.be/ZYp9p7xOD0A

There was an issue introduced in v0.5.0 where Descent would freeze when starting. Firmware v0.6.1 fixes that issue: https://github.com/polpo/picogus/releases/tag/v0.6.1