Home Page Forums Other Emulator Message Boards Audio Overload AO SDK release 1.0 available

SDK 1.4.0 (non-alpha!) has been posted to sync everything up, including the MADRS fix.

Neill's stuff is pretty good. Not only he got the actual AICA LUT values behind LFO times (took me a day to reverse engineer this) but AEG too. Not to mention I found "lpoff" bit but never even considered looking for one to disable AEG processing (AFAIR not used anyway).
Still, there are things in this file that don't sit well with me... I can always try to test that again I guess.

Neill reverse-engineered the unknown parameters of the SPC700 and PSX SPU, so in general I trust his stuff. Obviously he didn't finish working with the AICA though

Yeah, too bad. His approach to logarithmic volumes makes sense and gives a bit different values than my own (even if corrected for obvious roundings in AICA docs). I always had this feeling my AICA is a bit too loud at times, so I'm going to see if this helps any.

On a side note: EVA_6 tune in AO is not as bad as I had belived. That sound I mentioned is being produced by DC too - just the hardware plays it decaying (and not so loud overall) whereas AO just keeps same volume level and then cuts it completly. And that's why I noticed it as a bit odd.

This is what I'm talking about: http://rapidshare.com/files/97976789/srtalpha_MB_EVA_6-test.7z.html

Pay no attention to obvious limitations of my player

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?

KS, any comments on this? I really have no idea how the DSP is meant to work, I just know that if I mute all the direct sends I get something that sounds right

It is vestigial code (used in FM processing) left over from the SCSP-->AICA conversion.


Yeah, looks like a bug to me. Since it was only occurring with negative denormals, it didn't have much of an effect on the quality of the DSP output.

Here's a patch that should fix it:



I believe ADRS_REG is handled correctly in AO. The Saturn dAsms User's Manual (page 18) indicates that ADRS_REG is derived from INPUTS in 3 out of the 4 different store modes and I wouldn't expect the AICA DSP to be any different. Also, note that in the current ADRS_REG handling, when SHIFT==3, SHIFTED is cleanly split at the bit-level into integer and fractional parts (ADRS_REG and FRC_REG). It wouldn't make any sense at all to require two different SHIFT values, and hence require 2 DSP instructions instead of 1, to do this.

Now that you mention it... 12:12 accumulator split does make more sense. Say, you wouldn't happen to know why is INPUTS being overwritten when IRA == IWA on IWT? Does it mean MEMS write happens first? Could be, but there's nothing on it in AICA docs (or Neill's). Something found in Saturn specs?

Um... silly question: Why can't I edit/update my previous post now?

I just wanted to add that AO still cuts some notes way too early and I suspect it's related to AEG readout. There's a good test case for that, namely "srtalpha_MB_G83_0.dsf". This is opening tune for Gundam 0083, the trumpet there (first 15 seconds or so) is way shorter compared to original OST. My player seems to get this right (well, for once) and I still need to do DC test but I suspect it'll be the same.
If anyone wants to dig into this I can provide reference source.