appiah4 wrote on 2022-07-28, 11:30:You never know when these things will go out of stock anymore so I ordered a few pi picos for cheap. I don't even know what to do with them until this project is finalized 🤣
I had no need to for a pico pi but I bought two last week just in case. How wrong I was. And right.. I had been watching the PI project but hadn't noticed the Pico version
GUS emulation on the Pico is working great and the Pico has no problem mixing 32 channels of audio, especially if it is faithful to the GUS and reduces the sample rate as the channel count goes above 14. I am using external SPI PSRAM to support the full 1MB sample ram for the GUS. Here is a video from before I added PSRAM support and could only play chiptunes 😉
https://www.youtube.com/watch?v=rZopvkDTv08
I'm now working on adding IRQ and DMA support!
I've also been missing having a UART out pin for debugging purposes, so I managed to get a GPIO back for that by moving some reset/enable logic to hardware. And since I have a UART now, I will be adding a MIDI out port. This card should be able to handle MPU-401 intelligent mode emulation with no problem, using code from SoftMPU and/or HardMPU projects.
oh this is great news!
have you even measured the power consumption polpo? does the pico get hot?
I haven't measured power consumption... I currently have the Pico overclocked to 270MHz, at the default Vreg of 1.1V and the RP2040 is cool to the touch with no heatsink. From other people's data on overclocking the RP2040, the Pico should be consuming less than 40mW at that speed and Vreg. There are a couple videos on YouTube with data from overclocking measuring power draw and thermals.
https://www.youtube.com/watch?v=G2BuoFNLoDM
https://www.youtube.com/watch?v=rU381A-b79c
This is pretty amazing, considering I had to run a Raspberry Pi 3 at maximum speed to emulate a GUS and respond to ISA bus events fast enough, and at that speed, its little heatsink got quite hot.
this is indeed nice , 40mW is very low!
Just loving all these bare metal Pi projects popping up everywhere. Finally ppl has started doing this kind of stuff right, skipping the full blown OS underneath 😁
The Pico version looks completely awesome, definitely going to try it at some point 😀
polpo wrote on 2022-08-09, 19:30:This is pretty amazing, considering I had to run a Raspberry Pi 3 at maximum speed to emulate a GUS and respond to ISA bus events fast enough, and at that speed, its little heatsink got quite hot.
This is in parts thanks to the state machines in the RP2040, right?
Is there a test release on the way? Or is that still far off?
Retronautics: A digital gallery of my retro computers, hardware and projects.
polpo wrote on 2022-08-09, 19:30:I haven't measured power consumption... I currently have the Pico overclocked to 270MHz, at the default Vreg of 1.1V and the RP2 […]
I haven't measured power consumption... I currently have the Pico overclocked to 270MHz, at the default Vreg of 1.1V and the RP2040 is cool to the touch with no heatsink. From other people's data on overclocking the RP2040, the Pico should be consuming less than 40mW at that speed and Vreg. There are a couple videos on YouTube with data from overclocking measuring power draw and thermals.
https://www.youtube.com/watch?v=G2BuoFNLoDM
https://www.youtube.com/watch?v=rU381A-b79cThis is pretty amazing, considering I had to run a Raspberry Pi 3 at maximum speed to emulate a GUS and respond to ISA bus events fast enough, and at that speed, its little heatsink got quite hot.
I think you did not implement the IOCHRDY Signal on the Pi3 board, It can explain the problem.
root42 wrote on 2022-08-10, 06:46:This is in parts thanks to the state machines in the RP2040, right?
100% Yes.
But even a Pi Zero can be much more faster than a Pico, I think it is only a matter to optimize the I/O Code.
And the internal memory remove the need of SPI External RAM > More I/O
This is now a Pi Pico Stamp board, with the full 30 GPIO Available.
Even only 4 GPIO can add much more possibility.
Ultimately, a board with the RP2040 directly soldered ?
A 8086 emulator on Pico.
FreddyV wrote on 2022-08-15, 14:50:I think you did not implement the IOCHRDY Signal on the Pi3 board, It can explain the problem.
I'd like to go back eventually to the Pi3/4 and look at that. I can't trigger IOCHRDY in software on a Pi3/4 as fast as the RP2040 can in PIO, but I'm pretty sure I can at least drive it low within the 500ns deadline.
polpo wrote on 2022-08-15, 17:06:FreddyV wrote on 2022-08-15, 14:50:I think you did not implement the IOCHRDY Signal on the Pi3 board, It can explain the problem.
I'd like to go back eventually to the Pi3/4 and look at that. I can't trigger IOCHRDY in software on a Pi3/4 as fast as the RP2040 can in PIO, but I'm pretty sure I can at least drive it low within the 500ns deadline.
The Pico is a much more interesting project for the moment. As the others are difficult to find, and the solution will be cheaper.
related: https://www.yyzkevin.com/pcmcia-pico-w-card/
>Then I saw the work by Ian Scott on the PicoGUS that was using a Rasberry Pi Pico to talk to an ISA bus. This brought the Pico to my attention and I quickly connected one to the PCMCIA bus to play around. I quickly saw that the interrupt latency for the PIO was very low, and the PIO itself allowed some very fast and easy coordination of the I/O wait signals and other potential multiplexing and that is how I arrived where I am at now.
pcmcia GUS when? 😀
rasz_pl wrote on 2022-09-23, 13:23:pcmcia GUS when? 😀
This does actually make even more sense for a GUS (than compared to the soundblaster PCMCIA clone), as DMA is absent on 16-bit PCMCIA.
Sound Blaster heavily relies on DMA for streaming sound. So PCMCIA Sound Blaster need to emulate the transfers. (or one needs to fumble some custom solution with a DMA-enabled parallel port I guess? Has anyone tried abusing an IEEE1284 ECP mode (e.g.: from a business-range laptop) to assis PCMCIA SoundBlaster emulation?)
Whereas GUS could optionally use DMA for loading patches/soundfonts to RAM but, as far as I've read (I didn't own one back in the days) this use wasn't that widespread among mod-players -- you could support most software simply by implementing the IO ports used by most.
(Could any low-level assembler hacker from back then confirm?)
Dr.Yak wrote on 2022-10-17, 17:53:This does actually make even more sense for a GUS (than compared to the soundblaster PCMCIA clone), as DMA is absent on 16-bit P […]
rasz_pl wrote on 2022-09-23, 13:23:pcmcia GUS when? 😀
This does actually make even more sense for a GUS (than compared to the soundblaster PCMCIA clone), as DMA is absent on 16-bit PCMCIA.
Sound Blaster heavily relies on DMA for streaming sound. So PCMCIA Sound Blaster need to emulate the transfers. (or one needs to fumble some custom solution with a DMA-enabled parallel port I guess? Has anyone tried abusing an IEEE1284 ECP mode (e.g.: from a business-range laptop) to assis PCMCIA SoundBlaster emulation?)
Whereas GUS could optionally use DMA for loading patches/soundfonts to RAM but, as far as I've read (I didn't own one back in the days) this use wasn't that widespread among mod-players -- you could support most software simply by implementing the IO ports used by most.
(Could any low-level assembler hacker from back then confirm?)
Doom(2) and playmidi use DMA for patch loading, for example.
[SOLVED, sort of] Doom and doom 2 freeze at "calling DMX_Init" with GUS PnP (ITE 8888 bridge)
Usage of DMA for sample upload by demoscene productions is much more rare than games, but there are a few that do it. Inside by CNCD (but that can be disabled in setup) and Stars by Nooon are two that come to mind. Several module players like Capamod and Cubic Player also use DMA for sample upload but it can be disabled and IO port based upload used instead.
@polpo How's the progress going? I see that the next WIP steps are -
* Fabricate and test release candidate PCB
* Better IRQ support
* Better DMA support
No pressure!, I am just curious if there is any more current detail you can share with we curious + eagerly looking forward public.
So the beta PCB I've designed, and I've sent a few boards out to testers in North America. A few other people have fabricated their own boards as well using the KiCAD project I have on my Github. If you search picogus on Twitter you'll see them! I'm not confident enough in the design to say it's final though, but it's close.
As for better IRQ support, that's been eluding me for a while. The symptom is the IRQ line going high and never going back down – the interrupt handler on the PC side somehow doesn't convince the emulated GUS that it's serviced the IRQ. This usually manifests in hanging playback. I've waited to get a logic analyzer with more channel to dig into it and after a false start with the Digilent Digital Discovery (which has clunky software and produced questionable captures that I don't think fully reflected reality...) I finally have one I'm happy with, the DSLogic U3Pro32. What's happening seems to be with voice IRQs, which have to be serviced in a particular way by reading the voice IRQ source register according to the GUS docs:
Note: It is possible that multiple voices could interrupt at virtually the same time. In this case, this register will behave like a fifo. When in your IRQ handler, keep reading (and servicing) this register until you do a read with both IRQ bits set to a 1. This means there are no voice IRQs left to deal with.
However, a lot of demoscene productions only read the IRQ source register once after getting a voice IRQ, even if there are multiple voice IRQs in the queue on the PicoGUS to be serviced. On real GUS hardware with its timing, that assumption appears safe, but the PicoGUS reacts to ISA bus events a bit slower than the real thing so things get a bit out of whack. I'm currently experimenting with re-raising the IRQ if there are still voices to be serviced. Things aren't perfect yet, but demos that hung previously now continue running. I'm also working on improving the speed in which I react to bus events – for example, I lower IOCHRDY on every IO write or read even if it's needed or not because it keeps the PIO code much more simple, and PIO instructions are precious on the RP2040, as there are only 32 available on each of the two PIO units. I may have enough instructions left to only lower IOCHRDY on writes or reads I know can't complete in the typical 500ns event time on the ISA bus.
As for DMA, I've had a bit of a regression. DMA sample upload worked at least some of the time on my first prototype board, but now it fails on the beta PCB. I'll wait until I get IRQs fully sorted out before I tackle that one, though.
polpo wrote on 2022-10-19, 03:15:PIO instructions are precious on the RP2040
afaik there are tricks you can employ like streaming new code into PIO using dma.
Hmm. You would have to design a graph of states and routines they need at every point and stream that in in real time? At least I think thats how it was designed to be used.
Hi,
yesterday I've got a PicoGUS PCB as a gift and because of that I became interested in this topic and then I thought - why not go PC/104?
What do you think? Can I make it? I am not sure about the license stuff... Kept everything the same, just added my name as a "modificator"
Edit: Forgot to mention - I know about the IRQ/DMA connector being wrong way - I had to mirror it since PC/104 interface is backwards from ISA and didn't feel like redrawing the whole connector. The same goes for the PC/104 interface, the only thing that matters is the hole pitch for the connector.
