Previous Thread
Next Thread
Print Thread
Page 26 of 55 1 2 24 25 26 27 28 54 55
Joined: Mar 2001
Posts: 16,757
Likes: 29
R
Very Senior Member
OP Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,757
Likes: 29
SDK 1.4.0 (non-alpha!) has been posted to sync everything up, including the MADRS fix.

Joined: Feb 2008
Posts: 107
D
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.

Joined: Mar 2001
Posts: 16,757
Likes: 29
R
Very Senior Member
OP Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,757
Likes: 29
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

Joined: Feb 2008
Posts: 107
D
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.

Joined: Feb 2008
Posts: 107
D
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

Joined: Feb 2008
Posts: 107
D
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?

Joined: Mar 2001
Posts: 16,757
Likes: 29
R
Very Senior Member
OP Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,757
Likes: 29
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

Joined: Sep 2007
Posts: 56
K
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.

Joined: Feb 2008
Posts: 107
D
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?

Joined: Feb 2008
Posts: 107
D
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 

Link Copied to Clipboard
Who's Online Now
2 members (exidyboy, B2K24), 33 guests, and 3 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,943
Posts117,563
Members4,994
Most Online890
Jan 17th, 2020
Forum Host
These forums are hosted by www.retrogamesformac.com
Forum hosted by www.retrogamesformac.com