Previous Thread
Next Thread
Print Thread
Page 26 of 55 1 2 24 25 26 27 28 54 55
Re: AO SDK release 1.4.0 available [Re: R. Belmont] #39199 03/08/08 03:29 AM
Joined: Mar 2001
Posts: 16,590
R
R. Belmont Offline OP
Very Senior Member
OP Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,590
SDK 1.4.0 (non-alpha!) has been posted to sync everything up, including the MADRS fix.

Re: AO SDK release 1.4.0 available [Re: R. Belmont] #39203 03/08/08 11:24 AM
Joined: Feb 2008
Posts: 107
D
Deunan Knute Offline
Senior Member
Offline
Senior Member
D
Joined: Feb 2008
Posts: 107
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.

Re: AO SDK release 1.4.0 available [Re: Deunan Knute] #39204 03/08/08 12:24 PM
Joined: Mar 2001
Posts: 16,590
R
R. Belmont Offline OP
Very Senior Member
OP Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,590
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 smile

Re: AO SDK release 1.4.0 available [Re: R. Belmont] #39205 03/08/08 01:26 PM
Joined: Feb 2008
Posts: 107
D
Deunan Knute Offline
Senior Member
Offline
Senior Member
D
Joined: Feb 2008
Posts: 107
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.

Re: AO SDK release 1.4.0 available [Re: Deunan Knute] #39207 03/08/08 02:40 PM
Joined: Feb 2008
Posts: 107
D
Deunan Knute Offline
Senior Member
Offline
Senior Member
D
Joined: Feb 2008
Posts: 107
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 smile

Re: AO SDK release 1.4.0 available [Re: Deunan Knute] #39231 03/09/08 09:01 PM
Joined: Feb 2008
Posts: 107
D
Deunan Knute Offline
Senior Member
Offline
Senior Member
D
Joined: Feb 2008
Posts: 107
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?

Re: AO SDK release 1.4.0 available [Re: Deunan Knute] #39339 03/13/08 04:18 PM
Joined: Mar 2001
Posts: 16,590
R
R. Belmont Offline OP
Very Senior Member
OP Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,590
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 smile

Re: AO SDK release 1.4.0 available [Re: Deunan Knute] #39361 03/14/08 04:29 AM
Joined: Sep 2007
Posts: 56
K
kingshriek Offline
Member
Offline
Member
K
Joined: Sep 2007
Posts: 56
Originally Posted By Deunan Knute
- dead code
What is RBUFDST=AICA->RINGBUF+AICA->BUFPTR; in aica.c doing exactly?


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

Originally Posted By Deunan Knute
- 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.


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:

Code:
diff -Nru aosdk_base/eng_dsf/aicadsp.c aosdk/eng_dsf/aicadsp.c
--- aosdk_base/eng_dsf/aicadsp.c	2008-03-07 22:20:20.000000000 -0800
+++ aosdk/eng_dsf/aicadsp.c	2008-03-13 21:04:49.000000000 -0700
@@ -25,6 +25,7 @@
 	else
 		val <<= 11;
 	val >>= 11;
+	val &= 0x7FF;
 	val |= sign << 15;
 	val |= exponent << 11;
 
@@ -41,7 +42,10 @@
 	mantissa = val & 0x7FF;
 	uval = mantissa << 11;
 	if (exponent > 11)
+	{
 		exponent = 11;
+		uval |= sign << 22;
+	}
 	else
 		uval |= (sign ^ 1) << 22;
 	uval |= sign << 23;



Originally Posted By Deunan Knute
- 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?


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.

Re: AO SDK release 1.4.0 available [Re: kingshriek] #39383 03/14/08 06:10 PM
Joined: Feb 2008
Posts: 107
D
Deunan Knute Offline
Senior Member
Offline
Senior Member
D
Joined: Feb 2008
Posts: 107
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?

Re: AO SDK release 1.4.0 available [Re: Deunan Knute] #39391 03/15/08 01:41 AM
Joined: Feb 2008
Posts: 107
D
Deunan Knute Offline
Senior Member
Offline
Senior Member
D
Joined: Feb 2008
Posts: 107
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.

Page 26 of 55 1 2 24 25 26 27 28 54 55

Moderated by  R. Belmont, Richard Bannister 

Who's Online Now
1 registered members (Pernod), 70 guests, and 2 spiders.
Key: Admin, Global Mod, Mod
ShoutChat Box
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,818
Posts116,091
Members4,915
Most Online890
Jan 17th, 2020
Powered by UBB.threads™ PHP Forum Software 7.7.3