dreamcast armc cpu uses?

[chao2]

There was this guy on youtube trying to use the dreamcast arm 7 cpu do some processing but he ran into some problems. He is trying to find some other uses for the dreamcast arm7 cpu? here is the link http://www.youtube.com/watch?v=seAkCLxDw_8

[chao2]

could you guys help him?

[Ayla]

The DC's arm7 runs at ~2.8 MHz, so the only use it could have is as a module player, or as a controller for the ~5MHz DSP.

[RyoDC]

such a slow. it's so bad we can't utilize it for mp3 playback.

[Ayla]

MP3 (or rather OGG) playback might be possible to offload to the DSP, but this component has never been used in any homebrew before, there's little info about it, and no tools (no compiler etc).

[PH3NOM]

There was this guy on youtube trying to use the dreamcast arm 7 cpu do some processing but he ran into some problems. He is trying to find some other uses for the dreamcast arm7 cpu? here is the link http://www.youtube.com/watch?v=seAkCLxDw_8

This sure seemed like an interesting feature when I first starting programing on the DC, having a 2nd ARM cpu available.

There seems to be a lot of confusion about the actual speed of the ARM cpu, a lot of people think it is 45mhz.
I believe the AICA is 45mhz, but the ARM is half that, so only 22.5 mhz.

I remember doing some tests with executing some simple code on the ARM and waiting for it to finish on the SH4, and the amount of time that it took was stupid slow, to the point it defeated the purpose of using the 2nd cpu to begin with.
I guess the problem is not really clock speed of the ARM, so much as the overall interface of how the SH4 and ARM are integrated.

I am curious what the frame-rate is in that video, even though I can tell it is slow.

[PH3NOM]

MP3 (or rather OGG) playback might be possible to offload to the DSP, but this component has never been used in any homebrew before, there's little info about it, and no tools (no compiler etc).

MultiMedia Mike had sent me an email in the past regarding using the AICA's DSP to offload some of the later stages of MP3 decoding.

Mike, can you offer any thoughts on the subject?

[GyroVorbis]

This is a pretty sweet ancient DCEmu topic with some good information given by Rand Linden:
viewtopic.php?p=241423

From what I've seen, one of the biggest drawbacks is the fact that it has no cache.

[Multimedia Mike]

MP3 (or rather OGG) playback might be possible to offload to the DSP, but this component has never been used in any homebrew before, there's little info about it, and no tools (no compiler etc).

MultiMedia Mike had sent me an email in the past regarding using the AICA's DSP to offload some of the later stages of MP3 decoding.

Mike, can you offer any thoughts on the subject?

That was just a theory / brainstorm I came up with a long time but I never got a chance to try it. Per my recollection, I believe people tried porting full perceptual audio decoders (e.g., MP3, Vorbis) to run on the AICA coprocessor only to find that it lacked the muscle to do the entire task. I hypothesized that it might be possible to do some of the decoding on the SH-4 and then shuttle the remaining data to the ARM for the remainder of the processing. Do a Google image search for "mp3 decode flowchart" to see the different pieces of the process.

Obviously, I never got the opportunity to try it out or learn if it could relieve the SH-4 of a significant amount of the decode burden.

[Ayla]

All the tries on audio decoding were done using only the weak ARM, that is nowhere near capable enough to do something like this. Making use of the DSP would already be a better idea.

[Multimedia Mike]

All the tries on audio decoding were done using only the weak ARM, that is nowhere near capable enough to do something like this. Making use of the DSP would already be a better idea.

What do you think it means to "make use of the DSP"? Do you think it can handle the entire decoding load?

[TapamN]

The AICA DSP is not a general purpose DSP like the one in the Saturn SCU or Virtua Racing SVP. You can see implementations of the AICA DSP in MAME and nullDC, and from what I can tell, it executes a 128 instruction program once for each sample output by the AICA. It doesn't support branches, subroutines, or conditional statements. It just runs the 128 instruction program from start to finish, in a fixed order, 44100 times per second. It looks like it can read and write to sound RAM (probably for generating echoes), but only on even numbered instructions, it seems. The DSP mainly just preforms a bunch of adds, shifts, and multiplies with groups of sound channels. It's probably better to think of it as a final stage filter/mixer microcode than a "real" program.

I guess it might be able to do (some of?) the MDCT (I don't really know the resources required), but it would be tricky to get the DSP to help decode anything other than 44100 Hz streams because of how it executes its program.

[Ayla]

I heard about that issue. Still, the DSP could be used to offload some parts of mp3 decoding, like dequantization, although I doubt we can offload enough on the DSP to allow the ARM to follow.

[Multimedia Mike]

I heard about that issue. Still, the DSP could be used to offload some parts of mp3 decoding, like dequantization, although I doubt we can offload enough on the DSP to allow the ARM to follow.

Do you have any solid information about how this would work? I.e., are the exact specs and programming info for the AICA available? Or are you extrapolating from general DSP theory?

[RyoDC]

I think the main problem is that we ain't got no documentation on this. Nor DSP, nor AICA, nor sound system at all.
I think it's hard, or even impossible to do something when you don't have any (less or more) comprehensive docs.

[Ayla]

We have plenty of documentation. NullDC and MAME have a working AICA emulator, that's a source of documentation.
Since 2007 I'm slowly working on an OS for the ARM to ease development of the AICA. I've been reading a lot, and testing a lot (that's why I can affirm the running speed of the ARM and DSP as written previously). I'm more and more certain that we can't use both processors for anything useful, but I'm not loosing hope.

[RyoDC]

Yeah, source code is good, But official documentation may have features, that was not implemented by the code writer.

[Ayla]

No, unfortunately official documentation doesn't

[Neoblast]

What about of the official SDK documentation?
That could have something related...

Did the official libraries made any use of it anyway?

EDIT: It seems it did...

Code: Select all

GD-DA In this method, the AICA CPU decodes PCM from the GD-ROM to produce sound.
PCM Stream In this method, Ring Buffer is secured in the AICA memory, then PCM or ADPCM is loaded to produce sound.
One Shot This method loads One Shot Bank into the AICA memory, then the main CPU performs a request to produce sound.
MIDI This method loads MIDI Program Bank and MIDI Sequence Bank into the AICA memory, then the main CPU performs a sequence
start to produce sound.

[PH3NOM]

What about of the official SDK documentation?
That could have something related...

Did the official libraries made any use of it anyway?

EDIT: It seems it did...

Code: Select all

GD-DA In this method, the AICA CPU decodes PCM from the GD-ROM to produce sound.
PCM Stream In this method, Ring Buffer is secured in the AICA memory, then PCM or ADPCM is loaded to produce sound.
One Shot This method loads One Shot Bank into the AICA memory, then the main CPU performs a request to produce sound.
MIDI This method loads MIDI Program Bank and MIDI Sequence Bank into the AICA memory, then the main CPU performs a sequence
start to produce sound.

Lol, all that is well known and can be done with KOS rather easily.

Obviously the official SDK utilizes the AICA, there is no other way to output sound on the DC

Problem is, IIRC when I looked at the official SDK, most of the kernel was released as object code, not source code.
I dont remember the SDK containing any specific manuals on the AICA, although I will admit when I looked at it that was not something I was looking for.