Second CPU for audio processing?

[stephen_usher]

I s'pose the biggest question is, what do you really want a second processor to do?

Do you want to leverage the current Falcon code base for the DSP? If so then you could have a modern, faster general purpose system hang off the Atari bus and run a DSP emulator. You can feed the YM analogue audio into a daughter card and it can do all the mixing also. (There are DSP emulator codes out there, apparently, which could be reused.)

Do you want it to be more than purely a sound processing device? If so why not take the direction that Acorn did with the "Tube" interface on the BBC Micro as compatibility with old code is not at all required? That system used a high speed one byte wide bi-directional, parallel communcation bus.

Are you sure putting another M68K processor in the system is the best idea?

[exxos]

The problem with the DSP has been already talked about, it would be really good, but whos going to program for it ? I already talked about trying to port some falcon code over, but pretty much wasn't welcomed by people. So I abandon the idea.

Thread already talked about lots of things already, all solutions need a lot of extra work.. work I am not willing to do myself. I could build on a DSP5002 if someone is going to program a framework for it, but seems not. So that pretty much rules out any solution regardless of how good it may or may not be.

CPU isn't best solution for audio in all cases, but whole point is asm code is already done to play audio such as tracker tunes. Doing this on a second CPU would mean the code is 99% done and people would likely spend some time to adapt code to run on second CPU.

In terms of hardware, like mentioned before, interfacing to ST bus is main issues, the 68K can do this, the code is already there and hardware would be simple enough to develop. So in that respect is its the best solution to get a new audio system running with minimal work.

Of course CPU here is probably overkill for audio. It could be used for other things.. as to what, no idea. Nobody ever build a dual core ST before. That would be up to the coders to find uses for it. Though I have to assume it would be lucky to get audio working nevermind anything else.

Other options is to just have extra ram with direct output to DAC's to play wav files. Proper wav sound effects & music could play without slowing down the CPU. Easy to adapt games to control sampled sound banks held in RAM. No need for CPU for that. I may do that method if nobody is willing to port tracker player code over.

Of course we have no huge programmer base, so re-using what is already available is the best idea. If new 3D games were done, the second CPU could do long divisions at the same time as the main CPU was doing the same. Graphics rendering with such real time calculations could be done very fast on 2 CPU cores.. but of course while that is possible.. unless people code for it, looking at other features is a bit pointless. Though there are a lot of possibilities.. it can basically run any 68k code.. at least which doesn't need any OS access or other hardware dependencies such as YM or MFP etc.

In anycase, if anyone wants to spend time developing a new audio system hardware and software , such as DSP etc, I can add dedicated IO port on next STF PCB. There are some interesting MP3 playback chips out there which I already mentioned a few weeks ago for example. Linux stuff could maybe do a lot more, but its getting a bit over complicated with hardware and software in that case.

[stephen_usher]

Hmmm... Maybe instead of creating something yourself you could design a memory mapped interface similar to the cartridge port but read-write and with a method for the external device to cause an interrupt?

You could use a header to make connection simple, add a few pins for audio out from the YM and stereo audio in. I suppose it could even work as a bus, with various peripherals stacking and using sub-sets of the address range, though you would then have to add some sort of table and discovery system in the TOS ROM and/or ROM extension system. Could be tricky. Hmmm... you'd definitely have to isolate the main bus from this so as not to load the address/data lines too much. (Sorry, thinking out loud.)

In that way it makes a far more flexible system for others to add to in the future and decreases what you need to design to get a working system. (Of course you could design modules to fit if you wish.)

[rpineau]

That's called an expansion bus

[exxos]

There is something else to consider... That the DMA playback on the STE with SRAM and 50mhz CPU would be able to kick audio power into high gear by itself... The main limiting factor would be ram.. That goes back to my idea of using a seperate ram block for DMA audio again..

Maybe the best solution there wouild be to simply use the 030 CPU as it can access more ram areas. That way all ram is shared and can be used for whatever.

It really begs the question if the STF should just become in effect a 030 based machine , but keep the 68000 as well for backwards compatibility. Its possible CPUs could be selected in realtime.. Not like it would really matter.. But for 3D games , if they wouldn't run on a 030, games could be patched to farm out long divisions to the 030, which would be faster than a 68000, then switch back to 68000 after the division is done. Just thinking out loud as to how both cpus could be used .. Poor man's dual core I guess.

I was really considering the 020 as the main CPU , no data caches means its more like a 68000, plus 32bit is good for the 020. But in terms of more ram for audio, the 030 would be a better solution. We can add a lot more ram to hold wav samples for example... And just forget about trying to do a new audio system..

[rpineau]

The 68020 can access the same amount of ram as the 68030 as they both have a 32 bit address bus (physical).
68030 is becoming hard to find, Tekmos manufactures new 68020 (expensive though.. ~ $100 per CPU) but SMD version only.

[exxos]

Well, I looked on wiki and it said 020 was 24bit address bus.. But if its 32bit then sure the 020 I think would be good. Would still be easy for a 030 add on card to be done anyway.

Edit.
OK there is a ec version then it seems.. I guess aside from avaibility , either cpu could be used on a add on card.

[rpineau]

Yep, the EC version is 24 bit address bus, the normal 68020 has 32 bit of address bus

[stephen_usher]

Surely the biggest problem with any faster processor is that the major performance bottleneck is the memory access speed?

Even on the stock ST the processor speed is hobbled by the "ST RAM". It was for this reason the MegaSTE had a cache to help, otherwise the processor is just twiddling it's thumbs much of the time.

Of course, if you add another processor you just make the whole thing much worse. Not only do you have the predictable "ST RAM" access problem but also the unpredictable access from both processors trying to access the memory at the same time. This could potentially make the system far SLOWER than having a single processor. Multi-processor architectures are difficult to get right.

Even just having one processor running at a higher clock rate will not bring massive benefits as can be seen by the CPU boosters only getting a 50% speed-up even when running multiple time the original processor's clock rate.

So, to get any decent performance out of a second processor it would have to have dedicated RAM. Preferably the RAM speed and architecture would have to be fast enough to allow the processor to run at full speed otherwise you're just wasting resources.

On another front... How many bus control lines need to be added to make the cartridge port read/write with interrupts? Could there be a case to add these (as a separate port) so as to allow the cartridge port to become a full expansion slot, but in a fully backwards compatible manner?

[exxos]

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.