Welcome, Guest!

Here are some links you may find helpful

Dreamcast Weird DMA woes

Sifting

Well-known member
Original poster
Registered
Aug 23, 2019
51
130
33
I've been working on some stuff for AICA + KOS, and it's coming along well except for this strange issue with DMA. In short, I have no issues with DMA from SH4 to ARM, -except- when I want to use the DMA to copy the ARM driver. It seems I'm stuck using PIO mode for that, and it makes me sad. So my question is, what am I missing here? From what I understand it should be possible to do this, but it appears to not be the case. It's almost as if the ARM needs to be running for it work, but that doesn't seem right.

From the KOS side a few notes - I made sure to call spu_dma_init -before- snd_init. I'm also using spu_dma_transfer to transfer data SH4 -> ARM, which itself just wraps g2_dma_transfer and writes to a destination relative to 0x00800000. The driver itself is unmodified from the KOS source. It fails when I try to play a sound, at snd_sh4_to_aica, at line 96 -

Code:
assert_msg(g2_read_32(qa + offsetof(aica_queue_t, valid)), "Queue is not yet valid");

The queues are initialised in the ARM driver, so it really seems like the driver is just not being copied/run at at all!
 
Last edited:

TapamN

New member
Sep 21, 2019
1
1
3
AGName
TapamN
AG Join Date
Sep 16, 2005
I did some stuff working on sound DMA a few months ago. At first, I wasn't able to get any sound DMA to work at all then due to a bug in KOS. I'm not sure if it helps, but I posted about what I did here:


But it sounds like non-code DMA is working for you, and I wasn't trying to DMA code. If the problem is only when loading the driver, using the CPU to copy it
doesn't seem like a big deal, since it's (generally) only done once at start up. DMA is more important for avoiding CPU overhead from streaming sound during gameplay.
 
  • Like
Reactions: Sifting

Sifting

Well-known member
Original poster
Registered
Aug 23, 2019
51
130
33
Hey, great thread! It's interesting that we're trying to do the same thing, more or less.

So, I've examined the driver code and it's not setting any registers. I've tried DMA'ing a string then reading it back with PIO and it comes up nothing. I noticed the SPU does spin up the ARM with a default program that just loops in place. The only thing I haven't tried at this point is to use the DMA while it's running with the default program. You're right that being stuck with PIO to load the driver is no big loss, but it's just kind infuriating because there's no good reason for it as far as I understand, you know?

Some notes on your thread - it's vital to use ADPCM where ever possible, for the reasons you've noted: the bandwidth is quite terrible, and so is the memory capacity. Instead of using vorbis and mp3s, it would be better to split lengthy audio into multiple ADPCM streams, then DMA them into AICA memory and use the ARM interrupts to schedule them. This is what the old ADX sdk was doing back in the day, I do believe.

Also, the 32 byte memory accesses are really not so bad once you know the tricks. You can get GCC to align variables by suffxing __attribute__(aligned((32))) to their declarations. For dynamic memory alignments, then you should be using memalign. With these two together make for a happy hacker, believe me!

I think it should be possible to further reduce the SH4's audio responsibilities to just computing spatialisation parameters and some light managerial stuff, but as is, great job on what you've done so far. I was quite upset at the state of streaming audio myself!

P.S.: As you noted too, actually using all of AICA's channels is probably a terrible idea. I feel like it's best to treat the AICA as having 32 'logical' stereo channels, instead letting people use all 64 mono as they see fit. Even if it's wasting a channel for most sounds, it cuts down on the amount of work the poor chip has to do. That is, of course, unless some masochist decides to play 32 stereo sounds all at once!
 
Last edited:

Make a donation