My new ARM7 based sound emulator is coming along nicely, and aside from some bugs, it's working quite well.. However, I have hit a big problem with execution speed. The ARM7 is clocked @ 40Mhz, and uses an internal timer to generate an IRQ @ ~24Khz to output 1 sample at a time.
It sounds quite perfect, except that the 40Mhz cpu is killing me, and I can only manage 2FPS at best on a 2GHz machine.. I'm told 3Ghz maybe gets an extra 2 FPS, from someone who tried it.

I'm no expert at cpu cores, so i'm sure the core could stand some optimization, but I had a crazy idea, which I wondered if it could work..

Could I somehow slow down the cpu speed (say to 20Mhz or even as low as 4Mhz), and simply resample the output stream up to match the original 24Khz?

Can this work? Thanks for any advice/suggestions-
Steve

you might be runnning too many instructions anyway, cpu's with data/instruction caches can't always run full speed as they have to wait for ram accesses. clocking the cpu down but running the timer at the right speed might be enough.

It sounds like your cpu core could do with being optimised a bit though.

smf

Yes, i'm sure the core could use some optimization! :)

Tell me more about what you mean about having to wait for ram access in relation to what I might be doing wrong... ie, are you saying my instructions need to eat more cycles? To be honest, I'm a bit confused in general about the timing on the Arm7 especially with all the pipelining stuff, so I wasn't quite sure how to code the instruction cycles.

If I run the cpu slower, but keep the IRQ the same, the output is distorted, probably since (i'm guessing) the cpu cannot fill the output buffer fast enough.

> you might be runnning too many instructions anyway, cpu's with data/instruction
> caches can't always run full speed as they have to wait for ram accesses.
> clocking the cpu down but running the timer at the right speed might be enough.
>
> It sounds like your cpu core could do with being optimised a bit though.
>
> smf
>

> ie, are you saying my instructions need to eat
> more cycles?

Possibly, it's something to bare in mind.

> To be honest, I'm a bit confused in general about the timing on the
> Arm7 especially with all the pipelining stuff, so I wasn't quite sure how to
> code the instruction cycles.

Timing is always a bitch, it's difficult to know how accurate you need to be until you try something and it's not accurate enough. Accuracy tends to cost in terms of speed.

> If I run the cpu slower, but keep the IRQ the same, the output is distorted,
> probably since (i'm guessing) the cpu cannot fill the output buffer fast enough.

You need to know why. It might be that running the CPU faster than it needs to is just working round another issue. In fact it might be anything, you can only find out by doing the ground work.

smf