Yes, you are right with the dma @ I was probably tired when I did post 😀

Mod master XT support adlib, tandy and CMS so you can test everything.

My C++ skills and raspberry are really low, that is why I wanted to work on a project like this.

Regarding the multiplexing , it can also allow to add the memory signals and use the Pi as RAM/ROM and video.

A much faster code will be needed to manage the I/O, Mem, dma....
Have one core dedicated to this and communicate with the emulation code through some FIFO can surely help.

FreddyV wrote on 2022-06-17, 15:07:

Do a 100% accurate FPGA is way more complicated to do than software emulation, and much more complex to maintain. A big enaugh F […]
Show full quote

carlostex wrote on 2022-06-17, 13:40:

On the other hand, a big enough FPGA, could support several sound cards as once. Synth chips like the OPL3, dual OPL2's could be done in FPGA, its logic replicated to 100% would be impossible to distinguish from the real thing. I know there's someone on VCFED working on it but i'm sure it's not easy. In any case, i believe that a single card that does it all on a big enough FPGA is the future and the way to go.

Do a 100% accurate FPGA is way more complicated to do than software emulation, and much more complex to maintain.
A big enaugh FPGA is more expensive than a Pi Zero that can surely do the job.
The Board design and soldering itself is a nightmare compared to a simple connector for a Pi.

We are talking about a board for Old PC, 100% accuracy is not really needed, and the number of person wanting a board like this is not worth the effort to go to a FPGA design.

I never understood that argument. Why would a software emulation be different from an FPGA implementation? You can do the same things in software that you can do in FPGA. You can even emulate FPGAs in software... If you want cycle accurate emulations, you can do that either in an FPGA or software. I would go with whatever is cheaper and more readily available and what I can actually code.

root42 wrote on 2022-06-17, 20:03:

I never understood that argument. Why would a software emulation be different from an FPGA implementation? You can do the same things in software that you can do in FPGA. You can even emulate FPGAs in software... If you want cycle accurate emulations, you can do that either in an FPGA or software. I would go with whatever is cheaper and more readily available and what I can actually code.

FPGA and C/C++ Code are really different.
Basically, in Verilog everything is executes at the same time and to sequence actions, state machines are needed.
With a FPGA, we can implement 2,3,5 Data bus, with different registers and access is at the same time. It is not possible with a Microprocessor...
There are things that can be done with an FPGA and can't be doine with a microprocessor, that is why it is often said it is the only way to be 100% Accurate,

Then, go with a FPGA Core mean rewrite everything (Start from scratch).
When here, we take the DOSBOX Code, compile and it is "Done".

If we take the example of the Sound Blaster, the DSP is a microcontroller.
To emulate it at 100% in FPGA, what is needed is to reproduce the microcontroller and have it executing the original DSP Code.
Or, someone that is "Not Aware" of this will try to reproduce the DSP Behaviour and will never be 100% Accurate.

FreddyV wrote on 2022-06-17, 20:22:

Basically, in Verilog everything is executes at the same time and to sequence actions, state machines are needed.
With a FPGA, we can implement 2,3,5 Data bus, with different registers and access is at the same time. It is not possible with a Microprocessor...

again - you can emulate FPGA with software

FreddyV wrote on 2022-06-17, 20:22:

There are things that can be done with an FPGA and can't be doine with a microprocessor

see above

FreddyV wrote on 2022-06-17, 20:22:

that is why it is often said it is the only way to be 100% Accurate,

is false

The only benefits of FPGA are speed and IO (number of pins and their speed/latency), not accuracy. There is no magic. Microcontrollers used to be too slow to interface fast parallel busses by bitbanging, evidently that changed as shown by projects like pistorm and this.

polpo wrote on 2022-06-17, 16:51:

Small update: I have IRQ somewhat working but it is not 100% reliable yet. For example, timers are funny. Crystal Dream II runs at about 33% speed as it's reliant on the GUS timer to time the whole demo. I will be doing some captures with my logic analyzer of my actual GUS card to see how it drives the IRQ line so I can achieve parity.

Awesome work man, cheers, please keep us posted on all the details.

The limits of emulation come to the simple fact that it will never be exact without being a 100% identical fabrication. And emulating as close as possible is hard anyway, because no one will have full specs or enough knowledge of everything that is happening to something that is closed source. Even an FPGA clone is not a complete answer due to inherent differences and lack of knowledge. So the best we can do is just come close and there are several ways to go about it. Each have their advantages.

rasz_pl wrote on 2022-06-17, 21:26:

FreddyV wrote on 2022-06-17, 20:22:

Basically, in Verilog everything is executes at the same time and to sequence actions, state machines are needed.
With a FPGA, we can implement 2,3,5 Data bus, with different registers and access is at the same time. It is not possible with a Microprocessor...

again - you can emulate FPGA with software

Why do you say "Again" to me ? I never discussed this subject with you .
We can "Emulate", but not in real time, CPU and FPGA are physically not the same thing.

rasz_pl wrote on 2022-06-17, 21:26:

see above […]
Show full quote

FreddyV wrote on 2022-06-17, 20:22:

There are things that can be done with an FPGA and can't be doine with a microprocessor

see above

FreddyV wrote on 2022-06-17, 20:22:

that is why it is often said it is the only way to be 100% Accurate,

is false

True, I explaine it above.....
A Microprocessos is Synchronous, and we can't simulate with 100% accuracy Asynchronous logic.

FreddyV wrote on 2022-06-18, 14:20:

rasz_pl wrote on 2022-06-17, 21:26:

FreddyV wrote on 2022-06-17, 20:22:

Basically, in Verilog everything is executes at the same time and to sequence actions, state machines are needed.
With a FPGA, we can implement 2,3,5 Data bus, with different registers and access is at the same time. It is not possible with a Microprocessor...

again - you can emulate FPGA with software

Why do you say "Again" to me ? I never discussed this subject with you .

because you didnt get it the first time root42 said it 😀

FreddyV wrote on 2022-06-18, 14:20:

We can "Emulate", but not in real time, CPU and FPGA are physically not the same thing.

How they operate doesnt really matter, different means arriving at same result. Lets take OPL2 example cited above https://kilograham.github.io/rp2040-doom/sound.html uses rp2040 "5%-20% of one overclocked core". We can in fact run 100% accurate (same output audio bitstream) emulation of a real thing at 10x the realtime speed. Internally OPL2 is a shift register with adders and lookup tables http://yehar.com/blog/?p=665 https://www.righto.com/2021/11/reverse-engine … yamaha-dx7.html

FreddyV wrote on 2022-06-17, 20:22:

There are things that can be done with an FPGA and can't be doine with a microprocessor
A Microprocessos is Synchronous, and we can't simulate with 100% accuracy Asynchronous logic.

something to think about:
- Boot Vivado up, make as elaborate async logic you like, click Simulation/run simulation. What happened here?
- DRAM is asynchronous, doesnt stop you from interfacing it using ordinary atmega https://github.com/zrafa/30pin-simm-ram-arduino

The only difference is speed and latency, as long as software solution is fast enough there is no end result discrepancy.

Very cool project! It's always cool to see people trying things like this. Makes me happy.

Sorry that your thread got hijacked by people arguing about FPGA 🤕

rasz_pl wrote on 2022-06-18, 16:28:

The only difference is speed and latency, as long as software solution is fast enough there is no end result discrepancy.

Indeed -- and even FPGAs can have different timings and problems than "the real deal". Also on real ICs the signal delays etc. can have an impact on how the whole chip is designed and interfaces with other ICs.

Anyway, back to the topic: How much CPU is currently spent emulating the GUS? Or in other words: how much spare resources are still left?

root42 wrote on 2022-06-20, 07:58:

Anyway, back to the topic: How much CPU is currently spent emulating the GUS? Or in other words: how much spare resources are still left?

Short answer: I don't really know, but I could add some instrumentation to see how much time is actually spent in GUS emulation. In the multi-core bare metal environment I am using, there is little to nothing in terms of profilers, debuggers, etc.

Longer answer: to break it down, I am using all 4 cores of the Raspberry pi:
Core 0: system bringup, servicing asynchronous events such as deasserting IRQs
Core 1: GUS sound emulation, resampling, and sound output
Core 2: Polling of IO lines, GUS register handling
Core 3: Polling of timers

Core 0 is idle pretty much all of the time, but it's there to handle things the other cores throw at it.
Core 1, where the actual sound generation happens, is actually pretty resilient as the sound output is buffered. This is the most ripe for setting up instrumentation to see how much time is spent.
For cores 2 and 3, actual work done is very low: updating GUS registers, setting up timers, etc., but meeting timing deadlines is essential, so they are constantly busy polling for events to handle. Doing something as innocuous as printing to the screen in cores 2 and 3 are enough to throw the emulation completely off, causing missed notes or timers, halting playback. There's almost certainly CPU to spare, but the busy loops that they are both in need to hit their deadlines. I could probably figure out how to instrument these to see how much timing budget is left.

By the way, I'm considering switching to the GUS emulator in DOSBox-X. While similar to the code I'm currently using from DOSBox-staging, it has a few benefits: it can have fixed 44.1Khz sound output regardless of channels, it appears to have more focus on ensuring that Demoscene productions work (a major priority for me), and I like the way it handles IRQs a little better. Downside is that the code is a bit rougher; DOSBox-staging's emulator had a nice refactor not long ago.

If I do that, I plan on being able to switch between accurate GUS sample rates (dropping to 19293Hz at 32 voices) and constant 44.1Khz output. This (and other potential options) will be switchable via a DOS initialization utility that replaces ultrinit.exe. First stab at such a utility is here: https://github.com/polpo/pigus/blob/main/pgusinit/pgusinit.c

Such a great project, looking forward to this! 😀

polpo wrote on 2022-06-20, 16:17:

By the way, I'm considering switching to the GUS emulator in DOSBox-X. While similar to the code I'm currently using from DOSBox-staging, it has a few benefits: it can have fixed 44.1Khz sound output regardless of channels, it appears to have more focus on ensuring that Demoscene productions work (a major priority for me), and I like the way it handles IRQs a little better. Downside is that the code is a bit rougher; DOSBox-staging's emulator had a nice refactor not long ago.

If I do that, I plan on being able to switch between accurate GUS sample rates (dropping to 19293Hz at 32 voices) and constant 44.1Khz output. This (and other potential options) will be switchable via a DOS initialization utility that replaces ultrinit.exe. First stab at such a utility is here: https://github.com/polpo/pigus/blob/main/pgusinit/pgusinit.c

Hi,

This is exactly what I wanted to ask you, because DOSBOX-X is more focus on compatibility, and is surely less CPU intensive.
and for the 44KHz mixing as well 😀

So… for the time being I have added fixed 44.1kHz output to the DOSBox-staging GUS emulator and have also added IRQ deassertion to it. Now IRQs are working as expected.

Here are a couple demos that use IRQs for timing playing on the PiGUS:
Crystal Dream II: https://twitter.com/ianpolpo/status/1539829986693369857
X14: https://twitter.com/ianpolpo/status/1539832957606670336

Next step is DMA. I’m still foolishly optimistic about being able to do it with the signals I currently have on my adapter board. I’ll be away from home for a couple weeks so I won’t be making much progress for a while.

polpo wrote on 2022-06-24, 05:34:

Next step is DMA. I’m still foolishly optimistic about being able to do it with the signals I currently have on my adapter board. I’ll be away from home for a couple weeks so I won’t be making much progress for a while.

What is DMA used for on the GUS? Sample upload? Recording and playback of audio?

root42 wrote on 2022-06-24, 07:12:

polpo wrote on 2022-06-24, 05:34:

Next step is DMA. I’m still foolishly optimistic about being able to do it with the signals I currently have on my adapter board. I’ll be away from home for a couple weeks so I won’t be making much progress for a while.

What is DMA used for on the GUS? Sample upload? Recording and playback of audio?

Probably streaming playback and recording audio, it doesn't do graphics very well... 😀

Fascinating project! Kudos! 😎

If only the Raspberry Pi (2, 3, 4, Zero) wasn't almost as hard to come by as a GUS.
I think that's a bit of an irony right now.

Hackaday.com articles are similar in that respect.
So many of them are about the Raspberry Pi in these days.

However, with the exception of the Pi 400, the obscure computing modules and the ancient Raspberry Pi 1 series (used),
a Raspberry Pi is hard to come by. 😔

Edit: https://www.zdnet.com/article/raspberry-pi-wh … an-do-about-it/
In my place, new Pis are expected to appear somewhen in late 2023.

Jo22 wrote on 2022-06-24, 15:30:

Fascinating project! Kudos! 😎 […]
Show full quote

Fascinating project! Kudos! 😎

If only the Raspberry Pi (2, 3, 4, Zero) wasn't almost as hard to come by as a GUS.
I think that's a bit of an irony right now.

Hackaday.com articles are similar in that respect.
So many of them are about the Raspberry Pi in these days.

However, with the exception of the Pi 400, the obscure computing modules and the ancient Raspberry Pi 1 series (used),
a Raspberry Pi is hard to come by. 😔

I really can't believe how this came to happen. I feel lucky to own 4 3Bs..