Comparing my own DSP to AO I found several pieces of code that raised my eyebrow. Might be a bug, might be designed to be like that so don't get all worked up. Just checking.

- dead code
What is RBUFDST=AICA->RINGBUF+AICA->BUFPTR; in aica.c doing exactly?

- bug
PACK generates malformed (or is it supposed to be that way?) codes. Test case: 0xfffff800.
My encoder packs it to 0xe000, yours to 0xf800. This is already a special case, as there are >12 same bits in front.
As for decoder, mine will resolve both codes to 0xfffff800, yours to 0xfffff000. I'm not so sure my version is the good one though.

- observation
DSP->DEC counter in aicadsp.c is never assigned a start value. It's basically freewheeling anyway but since it has to do with ring buffer addressing maybe it should be set to zero when buffer size/address changes?
Quite frankly AICA doc says it's being reloaded with RBL value on zero (so it's pre-decremented?) but since it's always power of 2 it shouldn't ever matter. I reload it with RBL-1 on 0 to -1 because I'm post-decrementing just like AO.

- observation
TEMP, MEMS and MIXS registers hold their values in a strange way (first word has bit 7:0 valid and the second has 23:8). This isn't a problem when only DSP reads and writes those, but that is also possible from SH4 side on Dreamcast/Naomi. _Might_ be a problem in future. FYI I'm not doing this properly either and Makaron to runs fine.

- bug
if(ADRL)
{
if(SHIFT==3)
ADRS_REG=(SHIFTED>>12)&0xFFF;
else
ADRS_REG=(INPUTS>>16);
}
Neill's doc suggests this should be exactly the opposite? Also, why not always mask ADRS_REG here to 0xfff and not in address computation?