Second CPU for audio processing?

All information relating to the Alpha plus all the WIP threads etc.
User avatar
stephen_usher
Posts: 5578
Joined: Mon Nov 13, 2017 7:19 pm
Location: Oxford, UK.
Contact:

Re: Second CPU for audio processing?

Post by stephen_usher »

exxos wrote: Thu Oct 04, 2018 8:47 am We not taking about ST-RAM here, second cpu has own ram. Also machine will run at 50mhz (CPU & ST RAM). DAC audio can work with almost zero slow down when playing from hard drive. Just we would use more RAM instead of playing from hard drive. Which would need a 020 if we want a lot of RAM.

I would suggest read whole thread, in particular first post.
I have read the initial post and the whole thread, which has somewhat morphed since the first post.

I was mostly responding to your post from yesterday evening where you were discussing using a 68020 with a 68000 for compatibility and using the second processor for 3D graphics. What you were discussing I thought about using my Computer Science background and knowledge of complex computer system architectures, including multi-processor systems. It made big beeping warning sirens sound in my head. :)

How are you proposing precisely to interface the two computer systems? Are they going to use some shared RAM mapped into each of the processor's address space? If so this where the potential issues lie as you'll need some sort of arbitrator system. You'll probably have to have some sort of interrupt system.
Intro retro computers since before they were retro...
ZX81->Spectrum->Memotech MTX->Sinclair QL->520STM->BBC Micro->TT030->PCs & Sun Workstations.
Added code to the MiNT kernel (still there the last time I checked) + put together MiNTOS.
Collection now with added Macs, Amigas, Suns and Acorns.
User avatar
exxos
Site Admin
Site Admin
Posts: 23493
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: Second CPU for audio processing?

Post by exxos »

I haven't given it much thought as it was only a idea to start with. Largest problem is it would need someone to convert the tracker code to run on the second CPU core. The main thought is second CPU would have its own RAM, which much this would be fast-ram and could even use the full 16MB. In terms of interfacing, the address and databus would have to be isolated in general between the two CPU's for obvious reasons.

I'm sure I wrote about this already somewhere, though the main CPU would do a write cycle into a address register which would trigger a PLD to enable the second CPU bus to be connected, and the CPU would basically write direct to fast ram of the second CPU via the register.

The problem is that we need also to be able to select the address in ram on the second CPU. My initial thought was that this could be done with counters in the PLD, so each time main CPU writes to the second CPU is ram area, it would automatically increase the address. So basically the first CPU would constantly write data to one register, and the PLD would copy this over to the past ram of the second CPU, then automatically increase the address register, so if the main CPU did a second write, it would go into the second address the second CPU is ram...BUT..This would actually be not a great idea as we would never be able to really read data from the second CPUs ram.

So what we would have to have, is the main CPU would have to write a address into the PLD along with the data. This unfortunately would increase the overhead in copying data across between main RAM and second RAM, we will be able to read and write in any direction between the 2 RAM areas. So it would probably take 3 bus cycles (1 for data, and 2 for address) minimum transfer data to the second RAM area.

But really loading times really what the system would be mainly doing. Basically we are just copying data from main RAM to the second CPU is ram area, then that CPU and just start running instructions the loading has finished, so we will probably need a control register as well. But then that CPU can run at full speed 100% access to RAM and basically run any code we want on it.

If for example we wanted to do some long divisions on the second CPU core.. The main CPU would have to transfer the two numbers into the second CPU ram, any code to run to actually do the division and maybe have a low priority interrupt flagged the main system that does finished the division and output number into address register where the first CPU can read it once ready. Of course the overhead of transferring data between RAM would mean the second CPU could not do the divisions as fast as the main CPU, but these are basically free cycles and even if it is 50% faster has taken a significant load off the main CPU.

Though really, in terms of audio, using the STE DAC system is already done and there is already code to use it. It's already proven that we can play audio direct hard disk with no significant slowdown. Though if we are playing data from ram, we may have slowdown in effect I really don't know at this point.. But even if there is, the whole system is going to be running several times faster anyway.

But as I said before, while this may all be possible, without software to run on the second CPU somewhat irrelevant at this point. As I was more asking if someone would be willing to do the code should I go in this direction... But I think it would just be a lot easier to go with the existing DAC system and see if we can make some improvements to it.

Going back to my the original idea, we could still have a second bank of RAM to load in sound samples which can play direct to a second bank of DAC's.. This way once data has been loaded, was the CPU would have to do is basically and press play and the PLD would loop through and play the sound automatically.. But of course this does create some interface issues as we need to copy data from main RAM to sound sample RAM...

Which then brings me back to thinking a 020 with more RAM would be the way to go to keep everything simple. I don't know much about the STE DAC sound system, maybe someone knows if playing audio from RAM causes a slowdown ? I assume it would, saying that playing from hard disk doesn't slow down access, and the hard drive would actually be probably slower than RAM access anyway..

But again, even if playing audio from main RAM does cause huge slowdown, system is going to still be faster than a 8MHz machine. We are aiming for 50MHz so even a 50% slowdown is still in effect a 25MHz machine.

And for those who are simply not keeping up with the whole project, we are not just talking about 50MHz CPU, as already discussed elsewhere, the new MMU will be using SRAM and also be running at 50MHz with the CPU. So this is indeed a true 50MHz machine.

So I think basically just forget using a second CPU as I doubt anyone is going to write code for it, plus with it not being a easy setup and a little messy, I don't think is a good direction to go in. Likely separate sound RAM for direct DAC playback would probably be the way to go playing audio without any significant load on the main system.. But again this would be more complex than just running everything on the main CPU.

So really my conclusion is as said before, using a 020 to increase the available RAM space to hold more audio data. Or secondly, think about adding a second DAC circuit with its own RAM can play audio directly outside of the main system.

In actual fact, such a system has already been widely used fruit machines to play sound samples on them. These were basically Z80 based systems which would just select a sound bank and press play on the sound card. With those systems audio was programmed into a EPROM. But we would just be using RAM instead, which would be loaded by the CPU.
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
Post Reply

Return to “ALPHA DEVELOPMENT INFO”