Home Page

AO SDK release 1.0 available

Posted By: R. Belmont

AO SDK release 1.0 available - 10/28/07 04:16 AM

At my new page.

This release 1.0 includes:
- The actual QSF and SSF engines from Audio Overload
- A small commandline test app which demonstrates how to drive the engines
- A makefile for Linux and MinGW (it autodetects which)

More formats can be made available in future SDKs, please request which ones and I'll do what I can, licenses permitting.
Posted By: kingshriek

Re: AO SDK release 1.0 available - 10/28/07 05:37 AM

Excellent! I know I'll have a lot of fun tinkering around with the SSF engine.

Here's a patch I came up with to handle the 16-bit PCM problem I mentioned in another thread:

Code:
diff -Nru aosdk/eng_ssf/scsp.c aosdk_new/eng_ssf/scsp.c
--- aosdk/eng_ssf/scsp.c	2007-10-26 19:43:32.000000000 -0700
+++ aosdk_new/eng_ssf/scsp.c	2007-10-27 22:23:38.000000000 -0700
@@ -400,7 +400,8 @@
 {
 	slot->active=1;
 	slot->Backwards=0;
-	slot->base=SCSP->SCSPRAM+SA(slot);
+	UINT32 start_offset = PCM8B(slot) ? SA(slot) : SA(slot) & 0x7FFFE;
+	slot->base=SCSP->SCSPRAM + start_offset;
 	slot->cur_addr=0;
 	slot->step=SCSP_Step(slot);
 	Compute_EG(SCSP,slot);



Example ssf which the patch affects ---> http://h1.ripway.com/kingshriek/sakutai2_47.zip
Posted By: R. Belmont

Re: AO SDK release 1.0 available - 10/28/07 05:42 AM

Fantastic. I was hoping you'd have some fun with that smile
Posted By: kingshriek

Re: AO SDK release 1.0 available - 10/28/07 09:59 AM

And here's a patch for ssf_gen.c for loading multiple ssflibs (necessary for Shining the Holy Ark):

Code:
diff -Nru aosdk/eng_ssf/eng_ssf.c aosdk_new/eng_ssf/eng_ssf.c
--- aosdk/eng_ssf/eng_ssf.c	2007-10-27 16:24:22.000000000 -0700
+++ aosdk_new/eng_ssf/eng_ssf.c	2007-10-28 02:53:01.000000000 -0700
@@ -48,6 +48,7 @@
 	uint32 offset, plength;
 	uint64 file_len, lib_len, lib_raw_length;
 	corlett_t *lib;
+	char *libfile;
 	int i;
 
 	// clear Saturn work RAM before we start scribbling in it
@@ -64,34 +65,37 @@
 	#endif
 
 	// Get the library file, if any
-	if (c->lib[0] != 0)
-	{
-		uint64 tmp_length;
-	
-		#if DEBUG_LOADER	
-		printf("Loading library: %s\n", c->lib);
-		#endif
-		if (ao_get_lib(c->lib, &lib_raw_file, &tmp_length) != AO_SUCCESS)
+	for (i=0; i<9; i++) {
+		libfile = i ? c->libaux[i-1] : c->lib;
+		if (libfile[0] != 0)
 		{
-			return AO_FAIL;
-		}
-		lib_raw_length = tmp_length;
+			uint64 tmp_length;
+	
+			#if DEBUG_LOADER	
+			printf("Loading library: %s\n", c->lib);
+			#endif
+			if (ao_get_lib(libfile, &lib_raw_file, &tmp_length) != AO_SUCCESS)
+			{
+				return AO_FAIL;
+			}
+			lib_raw_length = tmp_length;
 		
-		if (corlett_decode(lib_raw_file, lib_raw_length, &lib_decoded, &lib_len, &lib) != AO_SUCCESS)
-		{
-			free(lib_raw_file);
-			return AO_FAIL;
-		}
+			if (corlett_decode(lib_raw_file, lib_raw_length, &lib_decoded, &lib_len, &lib) != AO_SUCCESS)
+			{
+				free(lib_raw_file);
+				return AO_FAIL;
+			}
 				
-		// Free up raw file
-		free(lib_raw_file);
+			// Free up raw file
+			free(lib_raw_file);
 
-		// patch the file into ram
-		offset = lib_decoded[0] | lib_decoded[1]<<8 | lib_decoded[2]<<16 | lib_decoded[3]<<24;
-		memcpy(&sat_ram[offset], lib_decoded+4, lib_len-4);
+			// patch the file into ram
+			offset = lib_decoded[0] | lib_decoded[1]<<8 | lib_decoded[2]<<16 | lib_decoded[3]<<24;
+			memcpy(&sat_ram[offset], lib_decoded+4, lib_len-4);
 
-		// Dispose the corlett structure for the lib - we don't use it
-		free(lib);
+			// Dispose the corlett structure for the lib - we don't use it
+			free(lib);
+		}
 	}
 
 	// now patch the file into RAM over the libraries
@@ -104,7 +108,6 @@
 	strcpy(psfby, "n/a");
 	if (c)
 	{
-		int i;
 		for (i = 0; i < MAX_UNKNOWN_TAGS; i++)
 		{
 			if (!strcasecmp(c->tag_name[i], "psfby"))
Posted By: R. Belmont

Re: AO SDK release 1.0 available - 10/29/07 04:14 AM

Thanks, I've applied both patches.
Posted By: R. Belmont

Re: AO SDK release 1.1 available - 11/06/07 04:59 AM

Release 1.1 is now available.

This includes the 2 SSF patches above and 3 new engines: .PSF, .PSF2, and .SPU. Plus known good sample songs are now included.
Posted By: KBeazley

Re: AO SDK release 1.1 available - 11/07/07 08:06 AM

Interesting.. So this is the source code (or part of it) for the current version of AO ?..
Posted By: kingshriek

Re: AO SDK release 1.1 available - 11/15/07 04:59 AM

Well, I investigated the SCSP envelope processing a bit, and I found a bug in the SCSP emulation that's causing the envelope state machine to immediately exit the DECAY1 state upon entering - the comparison operator in the ATTACK-->DECAY1 step is backwards!

I have another patch that incorporates this fix as well as some others. I added (or at least attempted to add) support for LPSLNK and SBCTL. I also fixed a minor panning bug (now both left- and right- stereo channels are fully attenuated when the four least significant bits are set) and put in something more reasonable when key-rate scaling isn't used (it only makes sense to add in bit 9 of FNS when OCT is there as well).

Here's the patch (against AOSDK 1.1):

Code:
--- aosdk_base\eng_ssf\scsp.c	2007-11-05 23:43:58.000000000 -0800
+++ aosdk\eng_ssf\scsp.c	2007-11-14 20:57:03.000000000 -0800
@@ -316,7 +316,7 @@
 	if(KRS(slot)!=0xf)
 		rate=2*(octave+KRS(slot))+((FNS(slot)>>9)&1);
 	else
-		rate=((FNS(slot)>>9)&1);
+		rate=0; //rate=((FNS(slot)>>9)&1);
 
 	slot->EG.volume=0;
 	slot->EG.AR=Get_AR(SCSP,rate,AR(slot));
@@ -337,9 +337,12 @@
 			slot->EG.volume+=slot->EG.AR;
 			if(slot->EG.volume>=(0x3ff<<EG_SHIFT))
 			{
-				slot->EG.state=DECAY1;
-				if(slot->EG.D1R>=(1024<<EG_SHIFT)) //Skip DECAY1, go directly to DECAY2
-					slot->EG.state=DECAY2;
+				if (!LPSLNK(slot)) 
+				{
+					slot->EG.state=DECAY1;
+					if(slot->EG.D1R>=(1024<<EG_SHIFT)) //Skip DECAY1, go directly to DECAY2
+						slot->EG.state=DECAY2;
+				}
 				slot->EG.volume=0x3ff<<EG_SHIFT;
 			}
 			if(slot->EG.EGHOLD)
@@ -347,7 +350,7 @@
 			break;
 		case DECAY1:
 			slot->EG.volume-=slot->EG.D1R;
-			if(slot->EG.volume>>(EG_SHIFT+5)>=slot->EG.DL)
+			if(slot->EG.volume>>(EG_SHIFT+5)<=slot->EG.DL)
 				slot->EG.state=DECAY2;
 			break;
 		case DECAY2:
@@ -412,6 +415,7 @@
 	Compute_LFO(slot);
 
 //	printf("StartSlot: SA %x PCM8B %x LPCTL %x ALFOS %x STWINH %x TL %x EFSDL %x\n", SA(slot), PCM8B(slot), LPCTL(slot), ALFOS(slot), STWINH(slot), TL(slot), EFSDL(slot));
+//	printf("           AR %x D1R %x D2R %x RR %x DL %x KRS %x EGHOLD %x LPSLNK %x\n", AR(slot), D1R(slot), D2R(slot), RR(slot), DL(slot), KRS(slot), EGHOLD(slot), LPSLNK(slot));
 }
 
 static void SCSP_StopSlot(struct _SLOT *slot,int keyoff)
@@ -498,7 +502,7 @@
 		if(iPAN&0x4) SegaDB-=12;
 		if(iPAN&0x8) SegaDB-=24;
 
-		if(iPAN==0xf) PAN=0.0;
+		if(iPAN&0xf==0xf) PAN=0.0;
 		else PAN=pow(10.0,SegaDB/20.0);
 
 		if(iPAN<0x10)
@@ -1104,6 +1108,12 @@
 			addr&=0x7ffff;
 	}
 
+	if(addr==LSA(slot))
+	{
+		if(LPSLNK(slot) && slot->EG.state==ATTACK)
+			slot->EG.state = DECAY1;
+	}
+
 	if(PCM8B(slot))	//8 bit signed
 	{
 		INT8 *p=(signed char *) (slot->base+(addr));
@@ -1115,6 +1125,11 @@
 		sample=LE16(p[0]);
 	}
 
+	if(SBCTL(slot)&0x1)
+		sample ^= 0x7FFF;
+	if(SBCTL(slot)&0x2)
+		sample = (INT16)(sample^0x8000);
+
 	if(slot->Backwards)
 		slot->cur_addr-=step;
 	else

Posted By: R. Belmont

Re: AO SDK release 1.1 available - 11/15/07 05:06 AM

KB: Yes, this is the actual file-format engine code from AO with a stripped down frontend I wrote from scratch.

kingshriek: thank you very much!
Posted By: R. Belmont

Re: AO SDK release 1.1.1 available - 12/01/07 02:21 PM

Version 1.1.1 of the SDK has been posted. This includes the latest SCSP and SSF fixes from kingshriek.
Posted By: kingshriek

Re: AO SDK release 1.1.1 available - 12/02/07 06:39 AM

I've been attacking the envelope problems a bit more, mostly targeting problems with Radiant Silvergun, and I've came up with some more fixes. One problem I discovered is that if a slot was already in the release state, keying it off stopped it cold - this shouldn't be happening.

Patch against AO SDK release 1.1.1:
Code:
--- aosdk_base\eng_ssf\scsp.c	2007-12-01 09:11:48.000000000 -0800
+++ aosdk\eng_ssf\scsp.c	2007-12-01 22:09:28.000000000 -0800
@@ -306,7 +306,7 @@
 	int Rate=base+(R<<1);
 	if(Rate>63)	Rate=63;
 	if(Rate<0) Rate=0;
-	return SCSP->ARTABLE[63-Rate];
+	return SCSP->DRTABLE[Rate];
 }
 
 static void Compute_EG(struct _SCSP *SCSP,struct _SLOT *slot)
@@ -366,9 +366,10 @@
 			slot->EG.volume-=slot->EG.RR;
 			if(slot->EG.volume<=0)
 			{
+				slot->EG.volume=0;
 				SCSP_StopSlot(slot,0);
-				slot->EG.volume=0x17F<<EG_SHIFT;
-				slot->EG.state=ATTACK;
+				//slot->EG.volume=0x17F<<EG_SHIFT;
+				//slot->EG.state=ATTACK;
 			}
 			break;
 		default:
@@ -421,7 +422,7 @@
 
 static void SCSP_StopSlot(struct _SLOT *slot,int keyoff)
 {
-	if(keyoff && slot->EG.state!=RELEASE)
+	if(keyoff /*&& slot->EG.state!=RELEASE*/)
 	{
 		slot->EG.state=RELEASE;
 	}
@@ -429,7 +430,6 @@
 	{
 		slot->active=0;
 	}
-
 	slot->udata.data[0]&=~0x800;
 }
 
@@ -559,7 +559,6 @@
 	{
 		SCSP->Slots[i].slot=i;
 		SCSP->Slots[i].active=0;
-		SCSP->Slots[i].active=0;
 		SCSP->Slots[i].base=NULL;
 	}
 
@@ -591,11 +590,11 @@
 				{
 					struct _SLOT *s2=SCSP->Slots+sl;
 					{
-						if(KEYONB(s2) && !s2->active)
+						if(KEYONB(s2) && s2->EG.state==RELEASE/*&& !s2->active*/)
 						{
 							SCSP_StartSlot(SCSP, s2);
 						}
-						if(!KEYONB(s2) && s2->active)
+						if(!KEYONB(s2) /*&& s2->active*/)
 						{
 							SCSP_StopSlot(s2,1);
 						}
@@ -1188,7 +1187,10 @@
 	if(!STWINH(slot))
 		*RBUFDST=sample;
 
-	sample=(sample*EG_TABLE[EG_Update(slot)>>(SHIFT-10)])>>SHIFT;
+	if(slot->EG.state==ATTACK)
+		sample=(sample*EG_Update(slot))>>SHIFT;
+	else
+		sample=(sample*EG_TABLE[EG_Update(slot)>>(SHIFT-10)])>>SHIFT;
 
 	return sample;
 }


Changes:
-Prevented keyoffs from killing slots when already in the release state
-Envelope steps in the attack state are apparently exponential. To account for this, I change the envelope output to linear for attacks.
-Change the release rate calculation to use the decay table instead of the attack one.



Also, I noticed in the MAME scsp.c source that the 16-bit PCM sample fix I posted earlier in this thread didn't get put in. Radiant Silvergun will need it for correct sound playback.

Here's the fix again, slightly modified so that it compiles without warnings in MAME (strict C90 compliance):

Code:
--- mame_base\src\emu\sound\scsp.c	2007-11-18 15:54:28.000000000 -0800
+++ mame\src\emu\sound\scsp.c	2007-12-01 15:28:06.000000000 -0800
@@ -461,13 +461,15 @@
 
 static void SCSP_StartSlot(struct _SCSP *SCSP, struct _SLOT *slot)
 {
+	UINT32 start_offset;
 	slot->active=1;
-	slot->base=SCSP->SCSPRAM+SA(slot);
+	start_offset = PCM8B(slot) ? SA(slot) : SA(slot) & 0x7FFFE;
+	slot->base=SCSP->SCSPRAM + start_offset;
 	slot->cur_addr=0;
 	slot->step=SCSP_Step(slot);
 	Compute_EG(SCSP,slot);


Patch is against the most recent, unmodified scsp.c in MAME source.
Posted By: R. Belmont

Re: AO SDK release 1.1.1 available - 12/02/07 03:30 PM

Ok, that's definitely much better. The drums at the start of Sakura Taisen #20 don't cut off immediately now, and Radient Silvergun is indeed quite improved. The 16-bit fix also corrects a few errant sound effects in Shienryu (one of the most underrated shmups ever, IMO).
Posted By: R. Belmont

Re: AO SDK release 1.1.2 available - 12/02/07 03:45 PM

At the page.

Just syncs up the SCSP with the latest patches again.

BTW, these patches greatly improved NiGHTS also, except nights-2a has a weird pitch problem on the flute. Any ideas on that?
Posted By: R. Belmont

Re: AO SDK release 1.1.2 available - 12/02/07 05:56 PM

I've launched my rip page. First up: a full SSF set of Radiant Silvergun from the ST-V version, fully tagged and timed. Plus a rarity that fell into my hands: a Qsound demo for the Saturn that was given away free to developers and made by game music legend Brian Schmidt. RSG will play quite nicely in the next AO test version (hopefully later today), but the QSound demo only works properly in kingshriek's KBmedia plugin for now.
Posted By: Richard Bannister

Re: AO SDK release 1.1.2 available - 12/02/07 07:42 PM

Can you fire me over a code drop when you have a minute and I'll try to do a Mac version of this test too.
Posted By: Stiletto

Re: AO SDK release 1.1.2 available - 12/03/07 07:44 AM

"Plus a rarity that fell into my hands: a Qsound demo for the Saturn that was given away free to developers and made by game music legend Brian Schmidt."

Amazing how things like that happen to turn up...

- Stiletto
Posted By: kingshriek

Re: AO SDK release 1.1.2 available - 12/09/07 12:30 PM

With the SCSP EG in pretty good shape, I have turned to fix some of the remaining issues in the DSP. The main fix I put in was support for the input effect mixer which fixes many of the dry/wet balance issues. I put in floating point support as well for ring-buffer read/writes. This fixes popping issues when the DSP initially reads from the ring-buffer, which most driver versions initialize to 0x6000 (the DSP floating-point representation of zero).

I also noticed that the EG_Update() function can possibly return a negative value in the DECAY1 state, which would potentially cause a segfault when later used as an index for table lookup (and if it doesn't, the output from it would probably sound very bad). I fixed this by adding a clamp to zero in the DECAY1 state.

I also took a brief look at LFO code and noticed that the saw PLFO was mistakenly set to a triangle waveform, so I fixed that too.

Patch against AO SDK 1.1.2:

Code:
diff -Nru aosdk_base/eng_ssf/scsp.c aosdk/eng_ssf/scsp.c
--- aosdk_base/eng_ssf/scsp.c	2007-12-02 10:27:02.000000000 -0800
+++ aosdk/eng_ssf/scsp.c	2007-12-09 04:09:59.000000000 -0800
@@ -351,6 +351,8 @@
 			break;
 		case DECAY1:
 			slot->EG.volume-=slot->EG.D1R;
+			if(slot->EG.volume<=0)
+				slot->EG.volume=0;
 			if(slot->EG.volume>>(EG_SHIFT+5)<slot->EG.DL)
 				slot->EG.state=DECAY2;
 			break;
@@ -1222,12 +1224,13 @@
 				++SCSP->BUFPTR;
 				SCSP->BUFPTR&=63;
 #ifdef USEDSP
-				SCSPDSP_SetSample(&SCSP->DSP,sample>>SHIFT,ISEL(slot),IMXL(slot));
+				Enc=((TL(slot))<<0x0)|((IMXL(slot))<<0xd);
+				SCSPDSP_SetSample(&SCSP->DSP,(sample*SCSP->LPANTABLE[Enc])>>SHIFT,ISEL(slot),IMXL(slot));
 #endif
 				Enc=((TL(slot))<<0x0)|((DIPAN(slot))<<0x8)|((DISDL(slot))<<0xd);
 				{
-					smpl+=(sample*SCSP->LPANTABLE[Enc])>>(SHIFT-1);
-					smpr+=(sample*SCSP->RPANTABLE[Enc])>>(SHIFT-1);
+					smpl+=(sample*SCSP->LPANTABLE[Enc])>>SHIFT;
+					smpr+=(sample*SCSP->RPANTABLE[Enc])>>SHIFT;
 				}
 			}
 
@@ -1240,14 +1243,14 @@
 			struct _SLOT *slot=SCSP->Slots+i;
 			if(EFSDL(slot))
 			{
-				unsigned short Enc=(TL(slot))|((EFPAN(slot))<<0x8)|((EFSDL(slot))<<0xd);
-				smpl+=(SCSP->DSP.EFREG[i]*SCSP->LPANTABLE[Enc])>>(SHIFT-4);
-				smpr+=(SCSP->DSP.EFREG[i]*SCSP->RPANTABLE[Enc])>>(SHIFT-4);
+				unsigned short Enc=((EFPAN(slot))<<0x8)|((EFSDL(slot))<<0xd);
+				smpl+=(SCSP->DSP.EFREG[i]*SCSP->LPANTABLE[Enc])>>SHIFT;
+				smpr+=(SCSP->DSP.EFREG[i]*SCSP->RPANTABLE[Enc])>>SHIFT;
 			}
 		}
 
-		*bufl++ = ICLIP16(smpl>>3);
-		*bufr++ = ICLIP16(smpr>>3);
+		*bufl++ = ICLIP16(smpl>>2);
+		*bufr++ = ICLIP16(smpr>>2);
 
 		SCSP_TimersAddTicks(SCSP, 1);
 		CheckPendingIRQ(SCSP);
diff -Nru aosdk_base/eng_ssf/scspdsp.c aosdk/eng_ssf/scspdsp.c
--- aosdk_base/eng_ssf/scspdsp.c	2007-10-26 19:43:40.000000000 -0700
+++ aosdk/eng_ssf/scspdsp.c	2007-12-09 03:58:38.000000000 -0800
@@ -7,19 +7,49 @@
 
 static UINT16 PACK(INT32 val)
 {
-	//cut to 16 bits
-	INT32 f=((UINT32 ) val)>>8;
-	return f;
+	UINT32 temp;
+	int sign,exponent,k;
+
+	sign = (val >> 23) & 0x1;
+	temp = (val ^ (val << 1)) & 0xFFFFFF;
+	exponent = 0;
+	for (k=0; k<12; k++)
+	{
+		if (temp & 0x800000)
+			break;
+		temp <<= 1;
+		exponent += 1;
+	}
+	if (exponent < 12)
+		val = (val << exponent) & 0x3FFFFF;
+	else
+		val <<= 11;
+	val >>= 11;
+	val |= sign << 15;
+	val |= exponent << 11;
+
+	return (UINT16)val;
 }
 
 static INT32 UNPACK(UINT16 val)
 {
-	INT32 r=val<<8;
-	r<<=8;
-	r>>=8;
-	//if(r&0x00800000)
-	//  r|=0xFF000000;
-	return r;
+	int sign,exponent,mantissa;
+	INT32 uval;
+
+	sign = (val >> 15) & 0x1;
+	exponent = (val >> 11) & 0xF;
+	mantissa = val & 0x7FF;
+	uval = mantissa << 11;
+	if (exponent > 11)
+		exponent = 11;
+	else
+		uval |= (sign ^ 1) << 22;
+	uval |= sign << 23;
+	uval <<= 8;
+	uval >>= 8;
+	uval >>= exponent;
+
+	return uval;
 }
 
 void SCSPDSP_Init(struct _SCSPDSP *DSP)
@@ -126,7 +156,7 @@
 		if(IRA<=0x1f)
 			INPUTS=DSP->MEMS[IRA];
 		else if(IRA<=0x2F)
-			INPUTS=DSP->MIXS[IRA-0x20]<<8;	//MIXS is 16 bit
+			INPUTS=DSP->MIXS[IRA-0x20]<<4;	//MIXS is 20 bit
 		else if(IRA<=0x31)
 			INPUTS=0;
 
@@ -298,7 +328,7 @@
 void SCSPDSP_SetSample(struct _SCSPDSP *DSP,INT32 sample,int SEL,int MXL)
 {
 	//DSP->MIXS[SEL]+=sample<<(MXL+1)/*7*/;
-	DSP->MIXS[SEL]+=sample<<7;
+	DSP->MIXS[SEL]+=sample;
 //  if(MXL)
 //      int a=1;
 }
diff -Nru aosdk_base/eng_ssf/scsplfo.c aosdk/eng_ssf/scsplfo.c
--- aosdk_base/eng_ssf/scsplfo.c	2007-10-26 19:43:36.000000000 -0700
+++ aosdk/eng_ssf/scsplfo.c	2007-12-08 07:01:00.000000000 -0800
@@ -47,7 +47,7 @@
 		if(i<128)
 			p=i;
 		else
-			p=255-i;    
+			p=i-256;    
 		ALFO_SAW[i]=a;
 		PLFO_SAW[i]=p;
 	


Changes:
- Added effect in mixer
- Added DSP floating-point support
- Added bounds check to the DECAY1 EG output
- Fixed the saw PLFO waveform
Posted By: R. Belmont

Re: AO SDK release 1.1.2 available - 12/09/07 04:33 PM

Wow, that fixes a lot of problems! Thanks again! smile
Posted By: R. Belmont

Re: AO SDK release 1.1.3 available - 12/09/07 04:45 PM

These new fixes are now in version 1.1.3 of the SDK, for those playing along at home.
Posted By: belegdol

Re: AO SDK release 1.1.3 available - 12/09/07 05:05 PM

Is that expected that make OSTYPE=linux is required for Linux build?
Posted By: R. Belmont

Re: AO SDK release 1.1.3 available - 12/09/07 05:06 PM

That's defined by the system for me on F8, and I thought it was fairly standard.
Posted By: belegdol

Re: AO SDK release 1.1.3 available - 12/09/07 05:07 PM

That's weird. I am running F8 as well, x86_64 if that matters.
Posted By: R. Belmont

Re: AO SDK release 1.1.3 available - 12/09/07 05:08 PM

Yeah, x86_64 here too. I use tcsh instead of bash, maybe that's the difference.
Posted By: belegdol

Re: AO SDK release 1.1.3 available - 12/09/07 05:10 PM

Yeah, that's it.
Posted By: kingshriek

Re: AO SDK release 1.1.2 available - 12/10/07 12:53 PM

Originally Posted By R. Belmont

BTW, these patches greatly improved NiGHTS also, except nights-2a has a weird pitch problem on the flute. Any ideas on that?


I discovered the main culprit causing this problem. The sampler should loop upon reaching LEA (loop end address), not afterwards. This caused the reading of one sample too many for each loop, lowering the pitch (especially noticeable when the loop segment is very small - see Desire example below).

Patch against AOSDK 1.1.3 (just changed some ">"s to ">="s):

Code:
diff -Nru aosdk_base/eng_ssf/scsp.c aosdk/eng_ssf/scsp.c
--- aosdk_base/eng_ssf/scsp.c	2007-12-09 11:07:38.000000000 -0800
+++ aosdk/eng_ssf/scsp.c	2007-12-10 01:07:56.000000000 -0800
@@ -1147,18 +1147,18 @@
 	switch(LPCTL(slot))
 	{
 	case 0:	//no loop
-		if(addr>LEA(slot))
+		if(addr>=LEA(slot))
 		{
 			//slot->active=0;
 			SCSP_StopSlot(slot,0);
 		}
 		break;
 	case 1: //normal loop
-		if(addr>LEA(slot))
+		if(addr>=LEA(slot))
 			slot->cur_addr=LSA(slot)<<SHIFT;
 		break;
 	case 2:	//reverse loop
-		if(addr>LEA(slot))
+		if(addr>=LEA(slot))
 		{
 			slot->cur_addr=LEA(slot)<<SHIFT;
 			slot->Backwards=1;
@@ -1167,7 +1167,7 @@
 			slot->cur_addr=LEA(slot)<<SHIFT;
 		break;
 	case 3: //ping-pong
-		if(addr>LEA(slot)) //reached end, reverse till start
+		if(addr>=LEA(slot)) //reached end, reverse till start
 		{
 			slot->cur_addr=LEA(slot)<<SHIFT;
 			slot->Backwards=1;



The problem affected Desire much worse than NiGHTS. Try playing desire_09.minissf before and after the patch for comparison.

BTW, I put up rips of Guardian Force and Marica on my page (http://snesmusic.org/hoot/kingshriek/ssf/) if anyone is interested.

Posted By: etabeta78

Re: AO SDK release 1.1.2 available - 12/10/07 02:00 PM

great work kingshriek!

is there any other known problem with saturn/stv audio emulation now that both radiant silvergun and nights have a fix?
Posted By: R. Belmont

Re: AO SDK release 1.1.2 available - 12/10/07 02:01 PM

Oh, wow. That's a major improvement, thanks again! That fixes some longstanding pitch issues with "Hanagumi Taisen Columns: Sakura Wars" in MAME as well - now it sounds so good I think I'll rip it next smile
Posted By: R. Belmont

Re: AO SDK release 1.1.2 available - 12/10/07 02:09 PM

BTW, updated DLLs here:

http://rbelmont.mameworld.info/aoDec10_w32.zip (Win32)
http://rbelmont.mameworld.info/aoDec10_w32.zip (Win64)

Do try that desire_09 before and after, it's quite striking smile

eta: SCSP is basically feature-complete now except for FM, and that's mostly because I haven't seen any Saturn or STV games that use it. (Well, that and it's not the most understandable part of the docs).

The better news for the future is that the AICA is essentially a straight superset of the SCSP, so if someone started making DSF rips for real (a working open-source DC emulator would help) it wouldn't be the end of the world to get them going.
Posted By: Knurek

Re: AO SDK release 1.1.2 available - 12/10/07 04:08 PM

Ahem, about that FM thingy, notes for Shining the Holy Ark rip from kingshriek's site: "Some of the tracks (battle ones mainly) actually use the SCSP's FM capabilities, which are not emulated in any of the current players (and probably won't be for some time)."

Are there even DC games that use sequenced music? I mean, except for Ikaruga and Skies of Arkadia, both of which have been ripped.
Most of them use ADX from what I've seen.
Posted By: R. Belmont

Re: AO SDK release 1.1.2 available - 12/10/07 04:22 PM

Ahh, that's interesting. ElSemi says that a few Model 3 games seem to use FM as well, so maybe we can get something going there.

I wouldn't expect a lot of DC games to use sequenced music, but then I didn't expect PS2 games to use it either and it turns out to have been rather popular :-) Also, the Skies of Arcadia test rip is just 1 song. As one of the 15 people who bought and loved that game I'd really like a full soundtrack rip.
Posted By: Knurek

Re: AO SDK release 1.1.2 available - 12/10/07 04:25 PM

No, no, kingshriek did a full rip later.
ftp://ftp.modland.com/pub/modules/Dreamcast%20Sound%20Format/-%20unknown/Skies%20Of%20Arcadia/

PS2 had a whole slew of 'budget' releases, all those Visual Novel ports and the general assorted Japanese crud. Dreamcast is mostly arcade games (Model 3 ports obviously). I think KID did port of of their Visual Novels to it though, that's one thing to look at. smile
Posted By: R. Belmont

Re: AO SDK release 1.1.2 available - 12/10/07 04:38 PM

Oh, nice! Hell, if there's a full rip of SOA I might do a DSF engine just for that reason :-)

Also, plenty of non-budget PS2 games used sequenced music, although it was much more popular with Japanese devs than US/European ones.
Posted By: nZero

Re: AO SDK release 1.1.2 available - 12/10/07 11:49 PM

Would a DSF engine be extensible to NAOMI?

Seconding the desire for SoA/EA, the soundtrack CD was too few discs for too much music and suffered as a result frown
Posted By: R. Belmont

Re: AO SDK release 1.1.2 available - 12/11/07 12:54 AM

Yes. I would assume that pre-GDROM Naomi games are probably a good hunting ground for sequenced music, as well.

Incidentally, the Hikaru board has 2 AICAs and 2 blocks of RAM. (And since the AICA integrates an ARM7TDMI, it's got two of those too).
Posted By: R. Belmont

Re: AO SDK release 1.1.4 available - 12/11/07 02:04 PM

AOSDK's been updated with the latest.
Posted By: kingshriek

Re: AO SDK release 1.1.4 available - 12/12/07 11:49 AM

I have some more SCSP fixes - these ones are AO specific.

The main AO fix relates to a problem I noticed in the 8-bit sampler in that it didn't account for sound memory being byte-swapped, making the 8-bit samples come out distorted. While I was at it, I also put in the interpolation code from MAME into the sampler.

Also I noticed that in the panning fix I put in awhile back, I screwed up the operator precedence, so I fixed that (someone else had already noticed this and fixed it for the MAME update).

Patch against AO SDK 1.1.4:

Code:
diff -Nru aosdk_base/eng_ssf/scsp.c aosdk/eng_ssf/scsp.c
--- aosdk_base/eng_ssf/scsp.c	2007-12-11 08:52:18.000000000 -0800
+++ aosdk/eng_ssf/scsp.c	2007-12-12 04:00:20.000000000 -0800
@@ -512,7 +512,7 @@
 		if(iPAN&0x4) SegaDB-=12;
 		if(iPAN&0x8) SegaDB-=24;
 
-		if(iPAN&0xf==0xf) PAN=0.0;
+		if((iPAN&0xf)==0xf) PAN=0.0;
 		else PAN=pow(10.0,SegaDB/20.0);
 
 		if(iPAN<0x10)
@@ -1125,13 +1125,23 @@
 
 	if(PCM8B(slot))	//8 bit signed
 	{
-		INT8 *p=(signed char *) (slot->base+(addr));
-		sample=(p[0])<<8;
+		INT8 *p=(signed char *) (SCSP->SCSPRAM+((SA(slot)+addr)^1));
+		//sample=(p[0])<<8;
+		INT32 s;
+		INT32 fpart=slot->cur_addr&((1<<SHIFT)-1);
+		s=(int) (p[0]<<8)*((1<<SHIFT)-fpart)+(int) slot->Prev*fpart;
+		sample=(s>>SHIFT);
+		slot->Prev=p[0]<<8;
 	}
 	else	//16 bit signed (endianness?)
 	{
 		INT16 *p=(signed short *) (slot->base+addr);
-		sample=LE16(p[0]);
+		//sample=LE16(p[0]);
+		INT32 s;
+		INT32 fpart=slot->cur_addr&((1<<SHIFT)-1);
+		s=(int) LE16(p[0])*((1<<SHIFT)-fpart)+(int) slot->Prev*fpart;
+		sample=(s>>SHIFT);
+		slot->Prev=LE16(p[0]);
 	}
 
 	if(SBCTL(slot)&0x1)



Changes (AO-specific):
-Fixed 8-bit sampler to handle byte-swapped RAM
-Added in interpolation code from MAME
-Fixed an error in the panning calculation
Posted By: R. Belmont

Re: AO SDK release 1.1.5 available - 12/12/07 02:47 PM

Nice. That fixes the hard-panned cymbals in Black Matrix that shouldn't have been, and the interpolation does smooth out the sound a bit.

The AOSDK version's been bumped again to include this new stuff.
Posted By: kingshriek

Re: AO SDK release 1.1.5 available - 12/14/07 12:16 PM

Well, I've been investigating sound quality issues some more and found that the interpolation wasn't really doing what was intended (an initial spectral analysis didn't show any significant rise in SNR). The sampler was interpolating over the previous and current sample but using a fractional address that corresponds to the current and next sample instead. After fixing the interpolation to use the current and next sample, I ended up with an SNR gain of 10 dB - much more along the lines of what I would have expected from it. This translates to a much improved playback quality.

Along the way, I fixed many issues. I tweaked the key-rate scaling calculation a bit to fix some problems in sakutai_07.ssf where some samples were getting cut off too early. Also, I noticed some non-looping samples actually had LEA (loop end address) set to 0, causing the samples not to be played at all (sakutai_02.ssf being an example). To handle this, I just check that the current address is greater than both LSA (loop start address) and LEA before stopping the slot. I also fixed the backwards loop mode so that it initially samples forwards before first hitting LSA (Soukyugurentai and Panzer Dragoon Saga use this loop mode).

Patch against AO SDK 1.1.5:
Code:
diff -Nru aosdk_base/eng_ssf/scsp.c aosdk/eng_ssf/scsp.c
--- aosdk_base/eng_ssf/scsp.c	2007-12-12 09:36:00.000000000 -0800
+++ aosdk/eng_ssf/scsp.c	2007-12-14 04:28:31.000000000 -0800
@@ -134,6 +134,7 @@
 	UINT8 active;	//this slot is currently playing
 	UINT8 *base;		//samples base address
 	UINT32 cur_addr;	//current play address (24.8)
+	UINT32 nxt_addr;	//next play address
 	UINT32 step;		//pitch step (24.8)
 	UINT8 Backwards;	//the wave is playing backwards
 	struct _EG EG;			//Envelope
@@ -315,7 +316,7 @@
 	int rate;
 	if(octave&8) octave=octave-16;
 	if(KRS(slot)!=0xf)
-		rate=2*(octave+KRS(slot))+((FNS(slot)>>9)&1);
+		rate=octave+2*KRS(slot)+((FNS(slot)>>9)&1);
 	else
 		rate=0; //rate=((FNS(slot)>>9)&1);
 
@@ -383,7 +384,7 @@
 static UINT32 SCSP_Step(struct _SLOT *slot)
 {
 	int octave=OCT(slot);
-	int Fn;
+	UINT32 Fn;
 
 	Fn=(FNS_Table[FNS(slot)]);	//24.8
 	if(octave&8)
@@ -408,7 +409,7 @@
 	UINT32 start_offset;
 	slot->active=1;
 	slot->Backwards=0;
-	slot->cur_addr=0;
+	slot->cur_addr=0; slot->nxt_addr=1<<SHIFT;
 	start_offset = PCM8B(slot) ? SA(slot) : SA(slot) & 0x7FFFE;
 	slot->base=SCSP->SCSPRAM + start_offset;
 	slot->step=SCSP_Step(slot);
@@ -1089,7 +1090,9 @@
 {
 	INT32 sample;
 	int step=slot->step;
-	UINT32 addr;
+	UINT32 addr1,addr2,addr_select;                                   // current and next sample addresses
+	UINT32 *addr[2]      = {&addr1, &addr2};                          // used for linear interpolation
+	UINT32 *slot_addr[2] = {&(slot->cur_addr), &(slot->nxt_addr)};    //
 
 	if(SSCTL(slot)!=0)	//no FM or noise yet
 		return 0;
@@ -1101,23 +1104,33 @@
 	}
 
 	if(PCM8B(slot))
-		addr=slot->cur_addr>>SHIFT;
+	{
+		addr1=slot->cur_addr>>SHIFT;
+		addr2=slot->nxt_addr>>SHIFT;
+	}
 	else
-		addr=(slot->cur_addr>>(SHIFT-1))&0x7fffe;
+	{
+		addr1=(slot->cur_addr>>(SHIFT-1))&0x7fffe;
+		addr2=(slot->nxt_addr>>(SHIFT-1))&0x7fffe;
+	}
 
 	if(MDL(slot)!=0 || MDXSL(slot)!=0 || MDYSL(slot)!=0)
 	{
 		INT32 smp=(SCSP->RINGBUF[(SCSP->BUFPTR+MDXSL(slot))&63]+SCSP->RINGBUF[(SCSP->BUFPTR+MDYSL(slot))&63])/2;
 
 		smp>>=11;
-		addr+=smp;
+		addr1+=smp; addr2+=smp;
 		if(!PCM8B(slot))
-			addr&=0x7fffe;
+		{
+			addr1&=0x7fffe; addr2&=0x7fffe;
+		}
 		else
-			addr&=0x7ffff;
+		{
+			addr1&=0x7ffff; addr2&=0x7ffff;
+		}
 	}
 
-	if(addr==LSA(slot))
+	if(addr1==LSA(slot))
 	{
 		if(LPSLNK(slot) && slot->EG.state==ATTACK)
 			slot->EG.state = DECAY1;
@@ -1125,23 +1138,23 @@
 
 	if(PCM8B(slot))	//8 bit signed
 	{
-		INT8 *p=(signed char *) (SCSP->SCSPRAM+((SA(slot)+addr)^1));
+		INT8 *p1=(signed char *) (SCSP->SCSPRAM+((SA(slot)+addr1)^1));
+		INT8 *p2=(signed char *) (SCSP->SCSPRAM+((SA(slot)+addr2)^1));
 		//sample=(p[0])<<8;
 		INT32 s;
 		INT32 fpart=slot->cur_addr&((1<<SHIFT)-1);
-		s=(int) (p[0]<<8)*((1<<SHIFT)-fpart)+(int) slot->Prev*fpart;
+		s=(int) (p1[0]<<8)*((1<<SHIFT)-fpart)+(int) (p2[0]<<8)*fpart;
 		sample=(s>>SHIFT);
-		slot->Prev=p[0]<<8;
 	}
 	else	//16 bit signed (endianness?)
 	{
-		INT16 *p=(signed short *) (slot->base+addr);
+		INT16 *p1=(signed short *) (slot->base+addr1);
+		INT16 *p2=(signed short *) (slot->base+addr2);
 		//sample=LE16(p[0]);
 		INT32 s;
 		INT32 fpart=slot->cur_addr&((1<<SHIFT)-1);
-		s=(int) LE16(p[0])*((1<<SHIFT)-fpart)+(int) slot->Prev*fpart;
+		s=(int) LE16(p1[0])*((1<<SHIFT)-fpart)+(int) LE16(p2[0])*fpart;
 		sample=(s>>SHIFT);
-		slot->Prev=LE16(p[0]);
 	}
 
 	if(SBCTL(slot)&0x1)
@@ -1153,41 +1166,48 @@
 		slot->cur_addr-=step;
 	else
 		slot->cur_addr+=step;
-	addr=slot->cur_addr>>SHIFT;
-	switch(LPCTL(slot))
+	slot->nxt_addr=slot->cur_addr+(1<<SHIFT);
+	
+	addr1=slot->cur_addr>>SHIFT;
+	addr2=slot->nxt_addr>>SHIFT;
+	
+	for (addr_select=0;addr_select<2;addr_select++)
 	{
-	case 0:	//no loop
-		if(addr>=LEA(slot))
+		switch(LPCTL(slot))
 		{
+		case 0:	//no loop
+			if(*addr[addr_select]>=LSA(slot) && *addr[addr_select]>=LEA(slot))
+			{
 			//slot->active=0;
 			SCSP_StopSlot(slot,0);
+			}
+			break;
+		case 1: //normal loop
+			if(*addr[addr_select]>=LEA(slot))
+				*slot_addr[addr_select]=LSA(slot)<<SHIFT;
+			break;
+		case 2:	//reverse loop
+			if((*addr[addr_select]>=LSA(slot)) && !(slot->Backwards))
+			{
+				*slot_addr[addr_select]=LEA(slot)<<SHIFT;
+				slot->Backwards=1;
+			}
+			if((*addr[addr_select]<=LSA(slot) || (*slot_addr[addr_select]&0x80000000)) && slot->Backwards)
+				*slot_addr[addr_select]=LEA(slot)<<SHIFT;
+			break;
+		case 3: //ping-pong
+			if(*addr[addr_select]>=LEA(slot)) //reached end, reverse till start
+			{
+				*slot_addr[addr_select]=LEA(slot)<<SHIFT;
+				slot->Backwards=1;
+			}
+			if((*addr[addr_select]<=LSA(slot) || (*slot_addr[addr_select]&0x80000000)) && slot->Backwards)//reached start or negative
+			{
+				*slot_addr[addr_select]=LSA(slot)<<SHIFT;
+				slot->Backwards=0;
+			}
+			break;
 		}
-		break;
-	case 1: //normal loop
-		if(addr>=LEA(slot))
-			slot->cur_addr=LSA(slot)<<SHIFT;
-		break;
-	case 2:	//reverse loop
-		if(addr>=LEA(slot))
-		{
-			slot->cur_addr=LEA(slot)<<SHIFT;
-			slot->Backwards=1;
-		}
-		if(addr<LSA(slot) || (addr&0x80000000))
-			slot->cur_addr=LEA(slot)<<SHIFT;
-		break;
-	case 3: //ping-pong
-		if(addr>=LEA(slot)) //reached end, reverse till start
-		{
-			slot->cur_addr=LEA(slot)<<SHIFT;
-			slot->Backwards=1;
-		}
-		if((addr<LSA(slot) || (addr&0x80000000)) && slot->Backwards)//reached start or negative
-		{
-			slot->cur_addr=LSA(slot)<<SHIFT;
-			slot->Backwards=0;
-		}
-		break;
 	}
 
 	if(ALFOS(slot)!=0)



Changes:
-Rewrote much of the interpolation code
-Improved key-rate scaling calculation
-Fixed playback of non-looping samples with a zero loop-end address
-Fixed backwards looping mode so that it initially reads forward until encountering the loop-start address
Posted By: R. Belmont

Re: AO SDK release 1.1.6 available - 12/14/07 02:19 PM

Ok, that's a fantastic improvement in both the overall noise floor and the "smoothness" of some samples (e.g. the trumpet that comes in during sakutai_11 no longer sounds terribly rough).

Updated 1.1.6 SDK is posted.
Posted By: kingshriek

Re: AO SDK release 1.1.6 available - 12/16/07 02:40 PM

While working with Assault Suit Leynos 2, I've discovered that it makes a very good test case for properly emulating the SCSP's FM synthesis capabilities. Quite a few tracks use it with clearly defined carrier and modulator layers.

Here's a patch against AO SDK 1.1.6 with my interpretation of the SCSP manual's overly confusing FM section:

Patch currently withdrawn, see EDIT
Code:


The patch will definitely need testing against actual Saturn output (I myself haven't yet played enough of Leynos 2 to get to any stages that use FM-synth). Here's a test track from Leynos 2 that uses FM: http://h1.ripway.com/kingshriek/leynos2_modulation_test.zip. In the archive are two ssfs - one is the full track and the other is the FM voice only (a full modulation level of MDL=0xF is used).

Also in the patch is a small fix to the sampler step calculation. High OCT values (such as in pdz_11.ssf) were causing the calculation to roll over, so I changed UINT32 to UINT64.

Changes:
-Updated modulation code, taking into account MDL (needs testing against actual hardware output)
-Changed frequency-step calculation to use UINT64 to fix rollover problems caused by large OCT values
Posted By: R. Belmont

Re: AO SDK release 1.1.6 available - 12/16/07 05:28 PM

Heh, well, the patch is already in the final release binaries of AO 2.0b9 (which Richard should be posting in the next few hours), but since no rips using FM are released yet that shouldn't be a problem :-) (Although that ASL2 track you posted sounds fine). I'll keep AOSDK at 1.1.6 though.
Posted By: kingshriek

Re: AO SDK release 1.1.6 available - 12/17/07 03:28 PM

Well, that will change when I release Shinobi X (if/when I decide to do so). Still doesn't make much of a difference since the FM handling didn't really get worse than what was there before, it just does it wrong in a different way.

I've examined FM a bit more while working with Shinobi X, and while I wasn't able to make any significant progress on getting it to sound correct, I was able to get MDXSL and MDYSL working properly. I've verified that these are correct by comparing their values with the fm_layer and fm_gen values given by ssfinfo and they are consistent with the tables in the SCSP manual. To achieve this, I changed the FM ring buffer pointer to decrement rather than increment as well as making it update regardless of whether a slot is active or not.

While investigating FM issues, I uncovered a few more (relatively minor) problems. I fixed a small LPSLNK problem (wasn't handling this quite correctly before). Also, I made a change to the DSP input mix level, which improves the effect balance. Previously, DSP output was a bit quiet compared to the direct output. I resolved this by shifting left what was the previous input by 2. I believe this is correct since the LPANTABLE/RPANTABLE calculations contain a multiplier of 4.0, and an additional left shift of 2 is in line with the fact that the MIXS input is 20 bits.

Below is a upgraded patch to AOSDK 1.1.6. I've commented out the FM-synth stuff because it isn't correct yet and right now Shinobi X sounds better with it disabled.

Code:
diff -Nru aosdk_base/eng_ssf/scsp.c aosdk/eng_ssf/scsp.c
--- aosdk_base/eng_ssf/scsp.c	2007-12-14 09:09:20.000000000 -0800
+++ aosdk/eng_ssf/scsp.c	2007-12-17 07:09:39.000000000 -0800
@@ -73,7 +73,7 @@
 #define SDIR(slot)		((slot->udata.data[0x6]>>0x0)&0x0100)
 #define TL(slot)		((slot->udata.data[0x6]>>0x0)&0x00FF)
 
-#define MDL(slot)		((slot->udata.data[0x7]>>0xB)&0x0007)
+#define MDL(slot)		((slot->udata.data[0x7]>>0xC)&0x000F)
 #define MDXSL(slot)		((slot->udata.data[0x7]>>0x6)&0x003F)
 #define MDYSL(slot)		((slot->udata.data[0x7]>>0x0)&0x003F)
 
@@ -384,7 +384,7 @@
 static UINT32 SCSP_Step(struct _SLOT *slot)
 {
 	int octave=OCT(slot);
-	UINT32 Fn;
+	UINT64 Fn;
 
 	Fn=(FNS_Table[FNS(slot)]);	//24.8
 	if(octave&8)
@@ -1114,11 +1114,16 @@
 		addr2=(slot->nxt_addr>>(SHIFT-1))&0x7fffe;
 	}
 
-	if(MDL(slot)!=0 || MDXSL(slot)!=0 || MDYSL(slot)!=0)
+	/*if(MDL(slot)!=0 || MDXSL(slot)!=0 || MDYSL(slot)!=0)
 	{
 		INT32 smp=(SCSP->RINGBUF[(SCSP->BUFPTR+MDXSL(slot))&63]+SCSP->RINGBUF[(SCSP->BUFPTR+MDYSL(slot))&63])/2;
+		INT32 cycle=LEA(slot)-LSA(slot); // cycle corresponds to 2 pi
 
-		smp>>=11;
+		smp*=cycle; // associate cycle with full 16-bit sample range
+		smp>>=0x1A-MDL(slot); // ex. for MDL=0xF, sample range corresponds to +/- 64 pi (32=2^5 cycles) so shift by 11 (16-5 == 0x1A-0xF)
+		while(smp<0) smp+=cycle; smp%=cycle; // keep modulation sampler within a single cycle
+		if(!PCM8B(slot)) smp<<=1;
+		
 		addr1+=smp; addr2+=smp;
 		if(!PCM8B(slot))
 		{
@@ -1128,13 +1133,7 @@
 		{
 			addr1&=0x7ffff; addr2&=0x7ffff;
 		}
-	}
-
-	if(addr1==LSA(slot))
-	{
-		if(LPSLNK(slot) && slot->EG.state==ATTACK)
-			slot->EG.state = DECAY1;
-	}
+	}*/
 
 	if(PCM8B(slot))	//8 bit signed
 	{
@@ -1171,6 +1170,12 @@
 	addr1=slot->cur_addr>>SHIFT;
 	addr2=slot->nxt_addr>>SHIFT;
 	
+	if(addr1>=LSA(slot) && !(slot->Backwards))
+	{
+		if(LPSLNK(slot) && slot->EG.state==ATTACK)
+			slot->EG.state = DECAY1;
+	}
+	
 	for (addr_select=0;addr_select<2;addr_select++)
 	{
 		switch(LPCTL(slot))
@@ -1216,14 +1221,14 @@
 		sample>>=SHIFT;
 	}
 
-	if(!STWINH(slot))
-		*RBUFDST=sample;
-
 	if(slot->EG.state==ATTACK)
 		sample=(sample*EG_Update(slot))>>SHIFT;
 	else
 		sample=(sample*EG_TABLE[EG_Update(slot)>>(SHIFT-10)])>>SHIFT;
 
+	if(!STWINH(slot))
+		*RBUFDST=sample;
+		
 	return sample;
 }
 
@@ -1243,19 +1248,18 @@
 
 		for(sl=0;sl<32;++sl)
 		{
+			RBUFDST=SCSP->RINGBUF+SCSP->BUFPTR;
 			if(SCSP->Slots[sl].active)
 			{
 				struct _SLOT *slot=SCSP->Slots+sl;
 				unsigned short Enc;
 				signed int sample;
 
-				RBUFDST=SCSP->RINGBUF+SCSP->BUFPTR;
 				sample=SCSP_UpdateSlot(SCSP, slot);
-				++SCSP->BUFPTR;
-				SCSP->BUFPTR&=63;
+
 #ifdef USEDSP
 				Enc=((TL(slot))<<0x0)|((IMXL(slot))<<0xd);
-				SCSPDSP_SetSample(&SCSP->DSP,(sample*SCSP->LPANTABLE[Enc])>>SHIFT,ISEL(slot),IMXL(slot));
+				SCSPDSP_SetSample(&SCSP->DSP,(sample*SCSP->LPANTABLE[Enc])>>(SHIFT-2),ISEL(slot),IMXL(slot));
 #endif
 				Enc=((TL(slot))<<0x0)|((DIPAN(slot))<<0x8)|((DISDL(slot))<<0xd);
 				{
@@ -1263,7 +1267,8 @@
 					smpr+=(sample*SCSP->RPANTABLE[Enc])>>SHIFT;
 				}
 			}
-
+			--SCSP->BUFPTR;
+			SCSP->BUFPTR&=63;
 		}
 
 		SCSPDSP_Step(&SCSP->DSP);



Changes:
-Corrected handling of the FM ring-buffer pointer - MDXSL and MDYSL now handled correctly
-Incorporated MDL into modulation code (not yet handled correctly, but it's something to start with)
-Changed frequency-step calculation to use UINT64 to fix rollover problems caused by large OCT values
-Improved DSP mix (I believe it's correct now)
-Fixed a minor LPSLNK problem
Posted By: R. Belmont

Re: AO SDK release 1.1.7 available - 12/17/07 06:04 PM

As per the above patch.

Sounds nice, but it's definitely a more subtle improvement than previous changes smile
Posted By: R. Belmont

Re: AO SDK release 1.2.0 available - 12/21/07 01:03 AM

On the homepage.

This time, kingshriek was not involved ;-) It's just the PSF2 improvments from AO 2.0b10 test 1.
Posted By: kingshriek

Re: AO SDK release 1.2.0 available - 01/05/08 07:53 AM

Alright, I think I have the SCSP's FM-synthesis working reasonably well. Shinobi X and NiGHTS sound a bit better now for the most part.

Patch against AO SDK 1.2.0:
Code:
diff -Nru aosdk_base/eng_ssf/scsp.c aosdk/eng_ssf/scsp.c
--- aosdk_base/eng_ssf/scsp.c	2007-12-17 12:45:26.000000000 -0800
+++ aosdk/eng_ssf/scsp.c	2008-01-04 19:39:51.000000000 -0800
@@ -36,6 +36,7 @@
 
 
 #define EG_SHIFT	16
+#define FM_DELAY    4    // delay in number of slots processed before samples are written to the FM ring buffer
 
 // include the LFO handling code
 #include "scsplfo.c"
@@ -181,6 +182,10 @@
 	struct _SLOT Slots[32];
 	signed short RINGBUF[64];
 	unsigned char BUFPTR;
+#if FM_DELAY
+	signed short DELAYBUF[FM_DELAY];
+	unsigned char DELAYPTR;
+#endif
 	unsigned char *SCSPRAM;
 	UINT32 SCSPRAM_LENGTH;
 	char Master;
@@ -1114,31 +1119,23 @@
 		addr2=(slot->nxt_addr>>(SHIFT-1))&0x7fffe;
 	}
 
-	/*if(MDL(slot)!=0 || MDXSL(slot)!=0 || MDYSL(slot)!=0)
+	if(MDL(slot)!=0 || MDXSL(slot)!=0 || MDYSL(slot)!=0)
 	{
 		INT32 smp=(SCSP->RINGBUF[(SCSP->BUFPTR+MDXSL(slot))&63]+SCSP->RINGBUF[(SCSP->BUFPTR+MDYSL(slot))&63])/2;
 		INT32 cycle=LEA(slot)-LSA(slot); // cycle corresponds to 2 pi
 
-		smp*=cycle; // associate cycle with full 16-bit sample range
+		smp<<=0xA; // associate cycle with 1024
 		smp>>=0x1A-MDL(slot); // ex. for MDL=0xF, sample range corresponds to +/- 64 pi (32=2^5 cycles) so shift by 11 (16-5 == 0x1A-0xF)
 		while(smp<0) smp+=cycle; smp%=cycle; // keep modulation sampler within a single cycle
 		if(!PCM8B(slot)) smp<<=1;
 		
 		addr1+=smp; addr2+=smp;
-		if(!PCM8B(slot))
-		{
-			addr1&=0x7fffe; addr2&=0x7fffe;
-		}
-		else
-		{
-			addr1&=0x7ffff; addr2&=0x7ffff;
-		}
-	}*/
+	}
 
 	if(PCM8B(slot))	//8 bit signed
 	{
-		INT8 *p1=(signed char *) (SCSP->SCSPRAM+((SA(slot)+addr1)^1));
-		INT8 *p2=(signed char *) (SCSP->SCSPRAM+((SA(slot)+addr2)^1));
+		INT8 *p1=(signed char *) (SCSP->SCSPRAM+(((SA(slot)+addr1)^1)&0x7FFFF));
+		INT8 *p2=(signed char *) (SCSP->SCSPRAM+(((SA(slot)+addr2)^1)&0x7FFFF));
 		//sample=(p[0])<<8;
 		INT32 s;
 		INT32 fpart=slot->cur_addr&((1<<SHIFT)-1);
@@ -1147,8 +1144,8 @@
 	}
 	else	//16 bit signed (endianness?)
 	{
-		INT16 *p1=(signed short *) (slot->base+addr1);
-		INT16 *p2=(signed short *) (slot->base+addr2);
+		INT16 *p1=(signed short *) (SCSP->SCSPRAM+((SA(slot)+addr1)&0x7FFFE));
+		INT16 *p2=(signed short *) (SCSP->SCSPRAM+((SA(slot)+addr2)&0x7FFFE));
 		//sample=LE16(p[0]);
 		INT32 s;
 		INT32 fpart=slot->cur_addr&((1<<SHIFT)-1);
@@ -1248,7 +1245,11 @@
 
 		for(sl=0;sl<32;++sl)
 		{
+#if FM_DELAY
+			RBUFDST=SCSP->DELAYBUF+SCSP->DELAYPTR;
+#else
 			RBUFDST=SCSP->RINGBUF+SCSP->BUFPTR;
+#endif
 			if(SCSP->Slots[sl].active)
 			{
 				struct _SLOT *slot=SCSP->Slots+sl;
@@ -1267,8 +1268,16 @@
 					smpr+=(sample*SCSP->RPANTABLE[Enc])>>SHIFT;
 				}
 			}
-			--SCSP->BUFPTR;
+			
+#if FM_DELAY
+			SCSP->RINGBUF[(SCSP->BUFPTR+64-(FM_DELAY-1))&63] = SCSP->DELAYBUF[(SCSP->DELAYPTR+FM_DELAY-(FM_DELAY-1))%FM_DELAY];
+#endif
+			++SCSP->BUFPTR;
 			SCSP->BUFPTR&=63;
+#if FM_DELAY
+			++SCSP->DELAYPTR;
+			if(SCSP->DELAYPTR>FM_DELAY-1) SCSP->DELAYPTR=0;
+#endif
 		}
 
 		SCSPDSP_Step(&SCSP->DSP);



Changes:
-Improved/enabled FM-synthesis emulation.

Also, I believe the endian XOR in the 8-bit sampler should use BYTE_XOR_BE when incorporating into MAME (I think a simple "^1" is ok for AO since SCSP RAM appears to always be organized in a byte-swapped manner). At least scsp.c before the last MAME SCSP update used BYTE_XOR_BE.
Posted By: R. Belmont

Re: AO SDK release 1.2.0 available - 01/05/08 07:36 PM

Nice. Any suggested test tracks in NiGHTS?
Posted By: R. Belmont

Re: AO SDK release 1.2.1 available - 01/05/08 09:22 PM

SDK's updated with these changes. Thanks again!
Posted By: kingshriek

Re: AO SDK release 1.2.0 available - 01/05/08 11:21 PM

Originally Posted By R. Belmont
Nice. Any suggested test tracks in NiGHTS?


nights_2b.minissf and nights_5d.minissf among others. The bass channels in these are FM-synthesized. For Shinobi X, shinobix_18.minissf and shinobix_19.minissf (bass channel in these is practically inaudible without FM-synth implemented).
Posted By: R. Belmont

Re: AO SDK release 1.2.0 available - 01/06/08 12:52 AM

Ahh. Good old FM bass smile

I didn't realize Shinobi X had been released - I sort of lost track of SSF over the holidays. Nice.
Posted By: belegdol

Re: AO SDK release 1.2.0 available - 01/06/08 09:48 AM

Is it just me, or did rsg01.ssf started to sound much worse, among others? Try Shining Force 3 Main Theme (the beginning of it), for instance. Same goes for AO 2.0b9.
Posted By: R. Belmont

Re: AO SDK release 1.2.0 available - 01/06/08 06:42 PM

I don't hear anything wrong with either of those songs compared to the Windows reference player.
Posted By: belegdol

Re: AO SDK release 1.2.0 available - 01/06/08 09:09 PM

Ahh, right. Something really bad happened to my headphones...
Posted By: kingshriek

Re: AO SDK release 1.2.1 available - 01/13/08 09:00 AM

I just discovered two lines that aren't necessary in the FM code. More importantly, removing these two lines fixes some problems resulting from me not sanity-checking the cycle length (I don't advise playing Guardian Force in the 0.122u5 version of MAME - it has a tendency to enter an infinite loop after pressing start on the title screen).

Patch:
Code:
diff -Nru aosdk_base/eng_ssf/scsp.c aosdk/eng_ssf/scsp.c
--- aosdk_base/eng_ssf/scsp.c	2008-01-13 00:54:50.000000000 -0800
+++ aosdk/eng_ssf/scsp.c	2008-01-13 00:54:35.000000000 -0800
@@ -1122,11 +1122,9 @@
 	if(MDL(slot)!=0 || MDXSL(slot)!=0 || MDYSL(slot)!=0)
 	{
 		INT32 smp=(SCSP->RINGBUF[(SCSP->BUFPTR+MDXSL(slot))&63]+SCSP->RINGBUF[(SCSP->BUFPTR+MDYSL(slot))&63])/2;
-		INT32 cycle=LEA(slot)-LSA(slot); // cycle corresponds to 2 pi
 
 		smp<<=0xA; // associate cycle with 1024
 		smp>>=0x1A-MDL(slot); // ex. for MDL=0xF, sample range corresponds to +/- 64 pi (32=2^5 cycles) so shift by 11 (16-5 == 0x1A-0xF)
-		while(smp<0) smp+=cycle; smp%=cycle; // keep modulation sampler within a single cycle
 		if(!PCM8B(slot)) smp<<=1;
 		
 		addr1+=smp; addr2+=smp;



Sorry about that.
Posted By: R. Belmont

Re: AO SDK release 1.2.1 available - 01/13/08 04:09 PM

Thanks, submitted.
Posted By: R. Belmont

Re: AO SDK release 1.3 available - 01/13/08 10:07 PM

The SDK is updated again.

This has the latest SCSP stuff plus time and fade tag support for SSF files.
Posted By: MooglyGuy

Re: AO SDK release 1.3 available - 01/13/08 11:59 PM

Wahey, still can't view the page, redirected to Google regardless of copy/pasting the link.
Posted By: kingshriek

Re: AO SDK release 1.3 available - 01/19/08 11:47 AM

I've finally resolved most of the remaining pitch issues in the SCSP emulation. What was happening was that the remaining fractional play position was not being carried over upon crossing over LSA/LEA resulting in an overall lower pitch for looped samples.

Patch against AOSDK 1.3:

Code:
diff -Nru aosdk_base/eng_ssf/scsp.c aosdk/eng_ssf/scsp.c
--- aosdk_base/eng_ssf/scsp.c	2008-01-13 15:33:54.000000000 -0800
+++ aosdk/eng_ssf/scsp.c	2008-01-19 03:45:38.000000000 -0800
@@ -36,7 +36,7 @@
 
 
 #define EG_SHIFT	16
-#define FM_DELAY    4    // delay in number of slots processed before samples are written to the FM ring buffer
+#define FM_DELAY    0   // delay in number of slots processed before samples are written to the FM ring buffer
 
 // include the LFO handling code
 #include "scsplfo.c"
@@ -939,6 +939,7 @@
 	
 	for (addr_select=0;addr_select<2;addr_select++)
 	{
+		INT32 rem_addr;
 		switch(LPCTL(slot))
 		{
 		case 0:	//no loop
@@ -950,26 +951,35 @@
 			break;
 		case 1: //normal loop
 			if(*addr[addr_select]>=LEA(slot))
-				*slot_addr[addr_select]=LSA(slot)<<SHIFT;
+			{
+				rem_addr = *slot_addr[addr_select] - (LEA(slot)<<SHIFT);
+				*slot_addr[addr_select]=(LSA(slot)<<SHIFT) + rem_addr;
+			}
 			break;
 		case 2:	//reverse loop
 			if((*addr[addr_select]>=LSA(slot)) && !(slot->Backwards))
 			{
-				*slot_addr[addr_select]=LEA(slot)<<SHIFT;
+				rem_addr = *slot_addr[addr_select] - (LSA(slot)<<SHIFT);
+				*slot_addr[addr_select]=(LEA(slot)<<SHIFT) - rem_addr;
 				slot->Backwards=1;
 			}
-			if((*addr[addr_select]<=LSA(slot) || (*slot_addr[addr_select]&0x80000000)) && slot->Backwards)
-				*slot_addr[addr_select]=LEA(slot)<<SHIFT;
+			else if((*addr[addr_select]<LSA(slot) || (*slot_addr[addr_select]&0x80000000)) && slot->Backwards)
+			{
+				rem_addr = (LSA(slot)<<SHIFT) - *slot_addr[addr_select];
+				*slot_addr[addr_select]=(LEA(slot)<<SHIFT) - rem_addr;
+			}
 			break;
 		case 3: //ping-pong
 			if(*addr[addr_select]>=LEA(slot)) //reached end, reverse till start
 			{
-				*slot_addr[addr_select]=LEA(slot)<<SHIFT;
+				rem_addr = *slot_addr[addr_select] - (LEA(slot)<<SHIFT); 
+				*slot_addr[addr_select]=(LEA(slot)<<SHIFT) - rem_addr;
 				slot->Backwards=1;
 			}
-			if((*addr[addr_select]<=LSA(slot) || (*slot_addr[addr_select]&0x80000000)) && slot->Backwards)//reached start or negative
+			else if((*addr[addr_select]<LSA(slot) || (*slot_addr[addr_select]&0x80000000)) && slot->Backwards)//reached start or negative
 			{
-				*slot_addr[addr_select]=LSA(slot)<<SHIFT;
+				rem_addr = (LSA(slot)<<SHIFT) - *slot_addr[addr_select];
+				*slot_addr[addr_select]=(LSA(slot)<<SHIFT) + rem_addr;
 				slot->Backwards=0;
 			}
 			break;
Posted By: R. Belmont

Re: AO SDK release 1.3 available - 01/19/08 02:32 PM

Ahh, that makes sense. Did you intend to turn off FM_DELAY too?
Posted By: kingshriek

Re: AO SDK release 1.3 available - 01/19/08 04:08 PM

Oh yeah, I did since the FM sounds better with it off. Turning the delay up causes distortion in some of the FM samples, which is strange because the driver swaps intermediate MDXSL/MDYSL values of 0x1C-0x1F with 0x3C-0x3F, indicating a delay of 4 slots.
Posted By: R. Belmont

Re: AO SDK release 1.3 available - 01/19/08 04:44 PM

Weird. Ok, thanks!
Posted By: R. Belmont

Re: AO SDK release 1.3.1 available - 01/20/08 01:11 AM

The SDK is updated with the patch above.
Posted By: R. Belmont

Re: AO SDK release 1.3.1 available - 01/22/08 03:33 PM

BTW, ks, is the FM "a/b" thing you posted on HCS's board included or what? smile
Posted By: kingshriek

Re: AO SDK release 1.3.1 available - 01/23/08 02:51 PM

Not yet. If you'd like to include it, here it is:

Code:
diff -Nru aosdk_base/eng_ssf/scsp.c aosdk/eng_ssf/scsp.c
--- aosdk_base/eng_ssf/scsp.c	2008-01-19 20:04:40.000000000 -0800
+++ aosdk/eng_ssf/scsp.c	2008-01-23 06:48:29.000000000 -0800
@@ -998,7 +998,10 @@
 		sample=(sample*EG_TABLE[EG_Update(slot)>>(SHIFT-10)])>>SHIFT;
 
 	if(!STWINH(slot))
-		*RBUFDST=sample;
+	{
+		unsigned short Enc=((TL(slot))<<0x0)|(0x7<<0xd);
+		*RBUFDST=(sample*SCSP->LPANTABLE[Enc])>>(SHIFT+1);
+	}
 		
 	return sample;
 }


Posted By: R. Belmont

Re: AO SDK release 1.3.1 available - 01/27/08 08:31 PM

Hmmmmm.

AO Debug CLI 1.0.1
File 1 (soa-299-02-00.minidsf) Song 1
W32 0 @ 802800
W32 0 @ 802800
W32 8000 @ 800000
W32 1f @ 800014
W32 8000 @ 800080
W32 1f @ 800094
W32 8000 @ 800100
W32 1f @ 800114
W32 8000 @ 800180
W32 1f @ 800194
W32 8000 @ 800200
W32 1f @ 800214
W32 8000 @ 800280
[...]
Posted By: Richard Bannister

Re: AO SDK release 1.3.1 available - 01/27/08 10:39 PM

Here we go again... smile
Posted By: R. Belmont

Re: AO SDK release 1.3.1 available - 01/28/08 05:06 AM

Heh. The replacement GSF driver's started playing stuff too, but the "sappy" driver used in about 95% of games doesn't work at the moment so there are problems :-)

The good news is it looks like Blargg's code is modular enough that I can run the old GB sound channels through that and magically have decent accuracy.
Posted By: Knurek

Re: AO SDK release 1.3.1 available - 01/28/08 06:17 AM

Originally Posted By R. Belmont
the "sappy" driver used in about 95% of games doesn't work at the moment so there are problems :-)


Ech, if only. This isn't DS, I'd say about 40% of the games (most of them Japanese budget releases) use it.
Posted By: R. Belmont

Re: AO SDK release 1.3.1 available - 01/28/08 01:25 PM

Well, either a large majority of games use the same driver or they all stole code from one, because they all fail with identical traces.
Posted By: Knurek

Re: AO SDK release 1.3.1 available - 01/28/08 04:42 PM

Well, most of the available GSF rips use Sappy. Simply because there's an automated ripper for the driver.
The few that use other drivers had to be manually hacked, and this isn't really something anyone can do 'out of the box' (and the people who can generally don't have time to dawdle on some 2005 American game, etc).
Posted By: R. Belmont

Re: AO SDK release 1.3.1 available - 01/28/08 04:51 PM

Is anyone actively doing GSF ripping now? Caitsith2's GSF page is starting to collect dust smile
Posted By: Knurek

Re: AO SDK release 1.3.1 available - 01/28/08 06:26 PM

I did that Saptapper GSF pack a while ago (posted here IIRC).
Caitsith2 seems to have lost interest (or rather, is busy with automatic song timer based on blargg's GME and/or SNSF).
Unknownfile is busy with the new 2SF format (zero points for guessing which system it covers).
There were a few rips done by Labmaster a while ago, but after that silence.
The current rippers are more interested in other formats (Sega 32bit for kingshriek, GBS for ugetab).

I'd love to have at least rips for Manfred Linzner games, but alas, doesn't seem like it's gonna happen soon.
Posted By: R. Belmont

Re: AO SDK release 1.3.1 available - 01/28/08 08:37 PM

Yeah, 2SF concerns me. Ideally *SF formats decompose into self-booting executable images like NSF or SID (not that Neill himself kept that story straight with PSF2). USF and 2SF are both just save states for specific emulators, which is irritating when that emulator is strongly OS-specific or licensed in a way that doesn't work for you.
Posted By: Knurek

Re: AO SDK release 1.3.1 available - 01/28/08 08:51 PM

Actually ROM + Savestate + Memory patches.

I guess this was done to ease writing the emulation a little (UF mentioned something about DS bootup process being scary).

I understand you though, but the only thing end users care about is if the thing works (or, well, don't work if you can't implement it in the player that's runable in their OS).

Posted By: R. Belmont

Re: AO SDK release 1.3.1 available - 01/28/08 09:01 PM

The full ROM is included, or just the sound data? And I would assume given the wide variety of DS homebrew that the boot process isn't *that* scary. Oh well.
Posted By: Knurek

Re: AO SDK release 1.3.1 available - 01/28/08 09:45 PM

Full ROM with the unused data changed to 0x00 to compress better.
Of course the tracer that identifies unused data does so after loading the savestate, so all bootup data is most probably gone.

Dunno, if you want to help UF with the thing, better do so fast, before the ripped games number is below 50.
Posted By: R. Belmont

Re: AO SDK release 1.3.1 available - 01/28/08 09:52 PM

That's actually not too bad. I don't have the bandwidth to adult-supervise UF, so just keep in mind you may be ripping for a Windows audience only.
Posted By: Knurek

Re: AO SDK release 1.3.1 available - 01/28/08 10:05 PM

I'm ripping for myself mostly, other people are just a nice side effect. smile
There's always Wine and co (though to my understanding the UF's plugin doesn't work there, not sure about the Japanese one). If that doesn't pan out, there's always wavewriting (hey, there was a usenet group releasing crappy VGMTransed oneloop mp3s, so I'm pretty sure the proper ones will get done too).
And I'm pretty sure the savestate is changed from the Desmume one to SR64 (Project 64 one?).
Posted By: R. Belmont

Re: AO SDK release 1.3.1 available - 01/28/08 10:40 PM

What's SR64? An N64 savestate is not compatible with the DS, even a little bit smile

Also, there's a second plugin that plays them?
Posted By: Knurek

Re: AO SDK release 1.3.1 available - 01/29/08 03:04 PM

Yea, the guy that was doing those AOSDK ssf plugins released it on Sunday IIRC.
Here's the link to the latest version, fixing a very annoying memory leak: http://pc11.2ch.net/test/read.cgi/dtm/1191788775/629
Posted By: R. Belmont

Re: AO SDK release 1.3.1 available - 01/29/08 03:35 PM

Looks like people like the "FM-B" patch that he put in the AOSSF plugin, so I guess I'll include it officially smile
Posted By: R. Belmont

Re: AO SDK release 1.3.1 available - 01/29/08 05:06 PM

Hahahahahahaha, they found UF's "DISREGARD THAT I SUCK C*CKS" post. Time to start copy/pasting posts into a translator.
Posted By: MooglyGuy

Re: AO SDK release 1.3.1 available - 01/29/08 05:32 PM

Originally Posted By R. Belmont
Hahahahahahaha, they found UF's "DISREGARD THAT I SUCK C*CKS" post. Time to start copy/pasting posts into a translator.


Oh, what a lovely tea party!
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 01/29/08 09:32 PM

As before, but with kingshriek's FM patch since people seem to like it in the various plugins.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 01/30/08 04:11 AM

For people wanting to help with it, here is SDK 1.4.0a1 with preliminary DSF support. THIS IS NOT FOR END-USERS AND YOUR EARS WILL BLEED IF YOU TRY AND PLAY ANYTHING WITH THIS!

http://rbelmont.mameworld.info/aosdk_140a1.zip

The AICA is there as a baseline. Registers, timers, IRQs, envelopes, and 8 and 16 bit samples work, all adapted from the current SCSP. I tried to port ADPCM from Chankast's AICA (which was forked from MAME's SCSP 2 years ago) but it's not working properly. The DSP's disabled at the moment, and the filter and filter envelope are not present.
Posted By: kingshriek

Re: AO SDK release 1.3.2 available - 01/30/08 08:41 AM

Nice! Here's a first pass attempt at some improvements:

Code:
diff -Nru aosdk_base/eng_dsf/aica.c aosdk/eng_dsf/aica.c
--- aosdk_base/eng_dsf/aica.c	2008-01-29 22:57:08.000000000 -0800
+++ aosdk/eng_dsf/aica.c	2008-01-30 01:05:44.000000000 -0800
@@ -59,7 +59,7 @@
 #define DL(slot)		((slot->udata.data[0x14/2]>>0x5)&0x001F)
 #define RR(slot)		((slot->udata.data[0x14/2]>>0x0)&0x001F)
 
-#define TL(slot)		((slot->udata.data[0x20/2]>>0x0)&0x00FF)
+#define TL(slot)		((slot->udata.data[0x28/2]>>0x8)&0x00FF)
 
 #define OCT(slot)		((slot->udata.data[0x18/2]>>0xB)&0x000F)
 #define FNS(slot)		((slot->udata.data[0x18/2]>>0x0)&0x03FF)
@@ -71,10 +71,10 @@
 #define ALFOWS(slot)		((slot->udata.data[0x1c/2]>>0x3)&0x0003)
 #define ALFOS(slot)		((slot->udata.data[0x1c/2]>>0x0)&0x0007)
 
-#define ISEL(slot)		((slot->udata.data[0x20/2]>>0x3)&0x000F)
-#define IMXL(slot)		((slot->udata.data[0x24/2]>>12)&0x0007)
+#define ISEL(slot)		((slot->udata.data[0x20/2]>>0x4)&0x000F)
+#define IMXL(slot)		((slot->udata.data[0x20/2]>>0x0)&0x000F)
 
-#define DISDL(slot)		((slot->udata.data[0x24/2]>>0x8)&0x0007)
+#define DISDL(slot)		((slot->udata.data[0x24/2]>>0x8)&0x000F)
 #define DIPAN(slot)		((slot->udata.data[0x24/2]>>0x0)&0x001F)
 
 #define EFSDL(slot)		((AICA->EFSPAN[slot/2]>>8)&0x000f)
@@ -113,8 +113,8 @@
 {
 	union
 	{
-		UINT16 data[0x10];	//only 0x1a bytes used
-		UINT8 datab[0x20];
+		UINT16 data[0x40];	//only 0x1a bytes used
+		UINT8 datab[0x80];
 	} udata;
 	UINT8 active;	//this slot is currently playing
 	UINT8 *base;		//samples base address
@@ -126,11 +126,11 @@
 	struct _LFO PLFO;		//Phase LFO
 	struct _LFO ALFO;		//Amplitude LFO
 	int slot;
-	signed short Prev, PPrev; // Previous ADPCM sample (for interpolation)
-	int PrevQuant;
-	int PrevSignal;
-	unsigned int LastDecAddr;	//Last decoded address for ADPCM
-	unsigned int ADStep;
+	int cur_sample;    //current ADPCM sample
+	int nxt_sample;    //next ADPCM sample
+	int cur_quant;     //current ADPCM step
+	int nxt_quant;     //next ADPCM step
+	int do_adpcm;      //do ADPCM decoding
 };
 
 
@@ -185,8 +185,8 @@
 	UINT8 MidiStack[16];
 	UINT8 MidiW,MidiR;
 
-	int LPANTABLE[0x10000];
-	int RPANTABLE[0x10000];
+	int LPANTABLE[0x20000];
+	int RPANTABLE[0x20000];
 
 	int TimPris[3];
 	int TimCnt[3];
@@ -203,7 +203,7 @@
 
 static struct _AICA *AllocedAICA;
 
-static const float SDLT[8]={-1000000.0,-36.0,-30.0,-24.0,-18.0,-12.0,-6.0,0.0};
+static const float SDLT[16]={-1000000.0,-39.0,-36.0,-33.0,-30.0,-27.0,-24.0,-21.0,-18.0,-15.0,-12.0,-9.0,-6.0,-3.0,0.0};
 
 static INT16 *bufferl;
 static INT16 *bufferr;
@@ -428,14 +428,13 @@
 
 	if (PCMS(slot) >= 2)
 	{
-		InitADPCM(&slot->PrevSignal, &slot->PrevQuant);
-		slot->LastDecAddr = slot->cur_addr>>SHIFT;
-		slot->ADStep = 0;
-		slot->Prev = slot->PPrev = 0;
+		slot->do_adpcm=1;
+		InitADPCM(&(slot->cur_sample), &(slot->cur_quant));
+		InitADPCM(&(slot->nxt_sample), &(slot->nxt_quant));
 	}
 
-	printf("StartSlot: SA %x PCMS %x LPCTL %x ALFOS %x TL %x\n", SA(slot), PCMS(slot), LPCTL(slot), ALFOS(slot), TL(slot));
-	printf("           AR %x D1R %x D2R %x RR %x DL %x KRS %x EGHOLD %x LPSLNK %x\n", AR(slot), D1R(slot), D2R(slot), RR(slot), DL(slot), KRS(slot), EGHOLD(slot), LPSLNK(slot));
+	//printf("StartSlot: SA %x PCMS %x LPCTL %x ALFOS %x TL %x\n", SA(slot), PCMS(slot), LPCTL(slot), ALFOS(slot), TL(slot));
+	//printf("           AR %x D1R %x D2R %x RR %x DL %x KRS %x EGHOLD %x LPSLNK %x\n", AR(slot), D1R(slot), D2R(slot), RR(slot), DL(slot), KRS(slot), EGHOLD(slot), LPSLNK(slot));
 }
 
 static void AICA_StopSlot(struct _SLOT *slot,int keyoff)
@@ -497,11 +496,11 @@
 		EG_TABLE[i]=(INT32)(pow(10.0,envDB/20.0)*scale);
 	}
 
-	for(i=0;i<0x10000;++i)
+	for(i=0;i<0x20000;++i)
 	{
 		int iTL =(i>>0x0)&0xff;
 		int iPAN=(i>>0x8)&0x1f;
-		int iSDL=(i>>0xD)&0x07;
+		int iSDL=(i>>0xD)&0x0F;
 		float TL=1.0;
 		float SegaDB=0;
 		float fSDL=1.0;
@@ -575,6 +574,7 @@
 		AICA->Slots[i].slot=i;
 		AICA->Slots[i].active=0;
 		AICA->Slots[i].base=NULL;
+		AICA->Slots[i].EG.state=RELEASE;
 	}
 
 	AICALFO_Init();
@@ -605,9 +605,17 @@
 				{
 					struct _SLOT *s2=AICA->Slots+sl;
 					{
-						if(KEYONB(s2)) // && s2->EG.state==RELEASE/*&& !s2->active*/)
+						if(KEYONB(s2) && s2->EG.state==RELEASE/*&& !s2->active*/)
 						{
 							AICA_StartSlot(AICA, s2);
+							
+							printf("StartSlot[%02X]:   SSCTL %01X SA %06X LSA %04X LEA %04X PCMS %01X LPCTL %01X\n",sl,SSCTL(s2),SA(s2),LSA(s2),LEA(s2),PCMS(s2),LPCTL(s2));
+							printf("                 EGHOLD %01X AR %02X D1R %02X D2R %02X RR %02X DL %02X KRS %01X LPSLNK %01X\n",EGHOLD(s2)>>5,AR(s2),D1R(s2),D2R(s2),RR(s2),DL(s2),KRS(s2),LPSLNK(s2)>>14);
+							printf("                 TL %02X OCT %01X FNS %03X\n",TL(s2),OCT(s2),FNS(s2));
+							printf("                 LFORE %01X LFOF %02X ALFOWS %01X ALFOS %01X PLFOWS %01X PLFOS %01X\n",LFORE(s2),LFOF(s2),ALFOWS(s2),ALFOS(s2),PLFOWS(s2),PLFOS(s2));
+							printf("                 IMXL %01X ISEL %01X DISDL %01X DIPAN %02X\n",IMXL(s2),ISEL(s2),DISDL(s2),DIPAN(s2));
+							printf("\n");
+							fflush(stdout);
 						}
 						if(!KEYONB(s2) /*&& s2->active*/)
 						{
@@ -954,55 +962,38 @@
 		s=(int) LE16(p1[0])*((1<<SHIFT)-fpart)+(int) LE16(p2[0])*fpart;
 		sample=(s>>SHIFT);
 	}
-	else	// ADPCM
+	else	// 4-bit ADPCM
 	{
-		slot->ADStep+=step;
-		if(slot->ADStep>>SHIFT)
+		UINT8 *p1=(unsigned char *) (AICA->AICARAM+((SA(slot)+(addr1>>1))&0x1fffff));
+		UINT8 *p2=(unsigned char *) (AICA->AICARAM+((SA(slot)+(addr2>>1))&0x1fffff));
+		INT32 s;
+		INT32 fpart=slot->cur_addr&((1<<SHIFT)-1);
+		if (slot->do_adpcm)
 		{
-			int hl=(slot->cur_addr>>SHIFT)&1;
-			INT8 *p=(signed char *) (AICA->AICARAM+(((SA(slot)+addr1))&0x1fffff));
-			int ca=slot->cur_addr>>SHIFT;
-			int steps=slot->ADStep>>SHIFT;
-			
-			slot->PPrev=slot->Prev;
-			if(!steps)
-				steps=1;
-			slot->ADStep&=(1<<SHIFT)-1;
-			while(steps--)
-			{
-				slot->Prev=DecodeADPCM(&slot->PrevSignal, (p[0]>>(4*hl))&0xF, &slot->PrevQuant);
-				hl^=1;
-				if(!hl)
-				{
-					++ca;
-					if(ca>=LEA(slot))
-					{
-						ca=LSA(slot);
-						hl=ca&1;
-						p=(unsigned char *) (slot->base+(ca>>1));
-					}
-					else
-						++p;
-				}
-			}
-			slot->LastDecAddr=slot->cur_addr>>SHIFT;
+			int shift1 = 4*((addr1&1)^1);
+			int shift2 = 4*((addr2&1)^1);
+			int delta1 = (*p1>>shift1)&0xF;
+			int delta2 = (*p2>>shift2)&0xF;
+			DecodeADPCM(&(slot->cur_sample),delta1,&(slot->cur_quant));
+			slot->nxt_sample=slot->cur_sample;
+			slot->nxt_quant=slot->cur_quant;
+			DecodeADPCM(&(slot->nxt_sample),delta2,&(slot->nxt_quant));
 		}
-		int s;
-		signed int fpart=slot->ADStep&((1<<SHIFT)-1);
-		s=(int) slot->PPrev*((1<<SHIFT)-fpart)+(int) slot->Prev*fpart;
-		sample=CHOOSE(s>>SHIFT,slot->Prev);
+		s=(slot->cur_sample)*((1<<SHIFT)-fpart)+(slot->nxt_sample)*fpart;
+		sample=(s>>SHIFT);
 	}
 
-	if(slot->Backwards)
-		slot->cur_addr-=step;
-	else
-		slot->cur_addr+=step;
+	// Only do an ADPCM decode when crossing a whole-address boundary
+	if(((slot->cur_addr+step)>>SHIFT)>((slot->cur_addr)>>SHIFT)) slot->do_adpcm=1;
+	else slot->do_adpcm=0;
+	
+	slot->cur_addr+=step;
 	slot->nxt_addr=slot->cur_addr+(1<<SHIFT);
 	
 	addr1=slot->cur_addr>>SHIFT;
 	addr2=slot->nxt_addr>>SHIFT;
 	
-	if(addr1>=LSA(slot) && !(slot->Backwards))
+	if(addr1>=LSA(slot))
 	{
 		if(LPSLNK(slot) && slot->EG.state==ATTACK)
 			slot->EG.state = DECAY1;
@@ -1027,33 +1018,6 @@
 				*slot_addr[addr_select]=(LSA(slot)<<SHIFT) + rem_addr;
 			}
 			break;
-		case 2:	//reverse loop
-			if((*addr[addr_select]>=LSA(slot)) && !(slot->Backwards))
-			{
-				rem_addr = *slot_addr[addr_select] - (LSA(slot)<<SHIFT);
-				*slot_addr[addr_select]=(LEA(slot)<<SHIFT) - rem_addr;
-				slot->Backwards=1;
-			}
-			else if((*addr[addr_select]<LSA(slot) || (*slot_addr[addr_select]&0x80000000)) && slot->Backwards)
-			{
-				rem_addr = (LSA(slot)<<SHIFT) - *slot_addr[addr_select];
-				*slot_addr[addr_select]=(LEA(slot)<<SHIFT) - rem_addr;
-			}
-			break;
-		case 3: //ping-pong
-			if(*addr[addr_select]>=LEA(slot)) //reached end, reverse till start
-			{
-				rem_addr = *slot_addr[addr_select] - (LEA(slot)<<SHIFT); 
-				*slot_addr[addr_select]=(LEA(slot)<<SHIFT) - rem_addr;
-				slot->Backwards=1;
-			}
-			else if((*addr[addr_select]<LSA(slot) || (*slot_addr[addr_select]&0x80000000)) && slot->Backwards)//reached start or negative
-			{
-				rem_addr = (LSA(slot)<<SHIFT) - *slot_addr[addr_select];
-				*slot_addr[addr_select]=(LSA(slot)<<SHIFT) + rem_addr;
-				slot->Backwards=0;
-			}
-			break;
 		}
 	}
 
@@ -1098,7 +1062,8 @@
 
 //				Enc=((TL(slot))<<0x0)|((IMXL(slot))<<0xd);
 //				AICADSP_SetSample(&AICA->DSP,(sample*AICA->LPANTABLE[Enc])>>(SHIFT-2),ISEL(slot),IMXL(slot));
-				Enc=((TL(slot))<<0x0)|((DIPAN(slot))<<0x8)|((DISDL(slot))<<0xd);
+//				Enc=((TL(slot))<<0x0)|((DIPAN(slot))<<0x8)|((DISDL(slot))<<0xd);
+				Enc=((TL(slot))<<0x0)|(0x0<<0x8)|(0x0F<<0xd); // DISDL,DIPAN not being set correctly for sequences so ignore them for now (OSB data is OK, though)
 				{
 					smpl+=(sample*AICA->LPANTABLE[Enc])>>SHIFT;
 					smpr+=(sample*AICA->RPANTABLE[Enc])>>SHIFT;



Changes:
-Corrected some slot register addresses/sizes
-Expanded slot udata arrays to avoid buffer overruns (for me, it was clobbering over the EG state values, preventing slots from starting properly)
-Expanded LPANTABLE/RPANTABLE to 0x20000 values. On the AICA, DISDL/IMXL/EFSDL have more resolution (range?) (0x0-0xF) than on the SCSP (0x0-0x7)
-Redid the ADPCM sampler in an attempt to make it work better
-Removed the backwards sample looping code (not used on AICA)

Problems/issues I've noticed so far:
-Playback of sakutai3_01.dsf causes a crash (I haven't looked into this yet)
-For sequenced music, it seems that DISDL and DIPAN aren't being written correctly (I get a lot of zeros for DISDL). This problem doesn't seem to occur when I give it OSB data instead (basically samples without any sequence data attached).
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 01/30/08 01:37 PM

Ok, test SDK is updated with that patch (same filename since this is a dev version). The crash I'm seeing is that LFO->table is NULL, which I assume means it's getting stomped.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 01/30/08 02:15 PM

Fixed it. AICA_UpdateSlotReg had wrong offsets, so the LFO wasn't being set up when it was written after key-on (ditto pitch, so pitchbend was busted). Re-uploaded, same filename.

ETA: one more small update towards enabling the DSP (it's still off by default though). Also, 16-bit samples are staticy and I'm not sure why - maybe endian trouble?

ETA2: for years the entire internet has thought the ARM7 is 45 MHz, which is an odd number. The AICA's only clock input is 33.868 MHz (which the savvy will identify as 44100*768, and the same as the CPU and SPU clocks on the PSX), so I'm calling that that's actually how fast the ARM is. On a Naomi board I have here, that's indeed the speed of the oscillator connected to the AICA.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 01/31/08 05:29 PM

The DISDL/DIPAN thing is likely an ARM7 core bug, probably when it combines the sequence pan/volume with the patch since playing raw patches works fine. I guess the good news is that manatee.drv is pretty small and uses only ARM-mode code, so it shouldn't be *too* hard to track down.
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/01/08 08:14 PM

AICA has several clock inputs. The primary one is 33.8688MHz coming from GD-ROM. It gets multiplied by *2 PLL for SPU SDRAM (connected trough 16-bit wide bus).

There's another PLL loop doing 2/3 on that clock so it ends up as
22579200Hz. This is AICA CORE clock and is not to be confused with 25MHz that AICA receives as the G2 bus clock (which BTW is 16-bit wide and that sums up to 50MB/s, however due to FIFO restrictions it can do 40 at most on real hardware).
There is yet another clock from GD, about 2MHz, it carries CD-DA data. Not really important. And lets not forget the 32768Hz crystal being reference for RTC - and well, nothing else.

I guess I should also mention one more PLL doing 22579200/2 = 11289600 clock that goes to DAC. And that's exactly 256 * 44100, should anyone care.

AICA ARM7 speed is limited by it's ability to access memory. It can do so only once per 8 cycles of AICA CORE clock, as DAC and DSP take the rest. Guess it saves a bunch of transistors on the memory controller. ARM has no cache and must fetch opcode for every instruction as it goes, so it limits at 2822400 IPS. Now, every LDR/STR instruction does another read/write, and that slows it down even more. Same goes for block register reads/stores.

You could either go for cycle-exact (defining cycle as memory access) as Makaron does now, or try a mean of 1.4-1.6 MIPS because that's approximately how fast a typical code would run.

I suppose some of us "cookbook chefs" actually do come up with recipes of our own... Luckily this isn't in MAME yet so I don't have to prove I've ripped someone else's preciuos code.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/01/08 09:14 PM

That all makes good sense (the SCSP worked quite similarly), and it makes the 45 MHz quote even stranger. That's double the core clock, and there is no way you could make even a cached ARM achieve that speed.

For playing DSFs, the important part is making the CPU as slow as possible without hurting the emulated program, so it works on a wide range of CPU speeds. It looks like that won't be a problem here since the ARM's effectively running slower than the GBA's.

As far as the rest, I don't know how much clearer I can make it that doing stuff from manuals is not an insult and doesn't mean you didn't put tons of hard work into your emulator. Nobody's accusing anything of being "ripped", and I could care less who discovered something first as long as the information gets shared. Posting info publically like this is certainly very welcome, especially for stuff that isn't open-source. Similarly the nullDC guys did use ElSemi's info, and they also credited him immediately without any prompting. It's all good.
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/01/08 10:42 PM

My point is NOTHING about AICA is well (or at all) documented. It's not SH4 with beautiful doc from Hitach that basically delivers C-like emulator code for the core. Actually the bits of information that are available (including some SEGA manuals I happened to find) are often plain wrong or misleading. I've spent much of my free time doing reasearch on that - reading, coding and finally probing the hardware. So please think twice next time you want to say this is "doing stuff from manuals".

Having said that, I don't really know that much about DSFs. We all did our MOD-players at some point but this is where I stopped (touching a bit of Adlib FM on the way). I can't help you with that but if you have any AICA specific questions I might be of some assistance. To point out few things:

+#define ISEL(slot) ((slot->udata.data[0x20/2]>>0x4)&0x000F)
+#define IMXL(slot) ((slot->udata.data[0x20/2]>>0x0)&0x000F)

This is wrong, I mean the ISEL is bits 0:3 and IMXL is 4:7. At least that's how I have it.
Also after a few tests I've came to conclusion that you cannot re-start the channel to play by setting Key-on to one if it has not been set to zero earlier. Even if it stopped on it's own. Not much point in checking if the AEG is in release phase when turning it on. Slot's KON bit is NOT being reset to zero by hardware at any time. Never ever. All this AEG code needs some reworking, including the co-efficient calculations. But good news is it should still work as it is now - for the time being smile
DSFs will most likely not need it but there are feedback registers on AICA that tell you at what point given channel AE/FE generator is, what phase, and at what sample address. This is mostly used for looping long streams properly. If there is code that reads back AEG status - beware. It's very tricky, actually overflows over zero for long times (> ca. 7sec). Quite frankly there are TONS of those quirks all over AICA (like interrupt priorities) but fortunately no or very little code ever uses that stuff. You will need to sort some of those out for MESS though.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/01/08 11:04 PM

Well, the nice thing with DSFs is that they decode into a RAM image that you just boot on an ARM attached to an AICA and they play, no intervention necessary. I can post a decoded bin if you want to give it a shot in your own code smile

As far as feedback the manatee.drv reads every slot's LP bit all the time but it doesn't seem like it's used for the sequenced music in DSFs (I imagine that's more useful for streaming stuff off the disc into the AICA's RAM - the SCSP had a similar mechanism used for that reason).

BTW, if I may ask, the Dreamcast BIOS in MESS currently hits a SLEEP instruction almost right away, and I didn't notice any obvious interrupt sources being enabled before then. Is it crashing to indicate it's displeasure or am I just missing something? smile
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/02/08 12:24 AM

If you get that, that is 10: SLEEP; 20: GOTO 10 stuff then most likely you've got some hardware registers wrong. There are several that keep magic values like HW revision - DC BIOS (except DEV maybe) will refuse to boot if it doesn't like what it sees. I can't go through MESS sources right now (but maybe during weekend?) so check if you have:

/** System bus revision number (R). */
#define HOLLY_SB_SBREV 0x005F689C
/** G2 bus version (R). */
#define HOLLY_SB_G2ID 0x005F7880
/** Device ID (R). */
#define HOLLY_ID 0x005F8000
/** Revision number (R). */
#define HOLLY_REVISION 0x005F8004

HOLLY_REJ (HOLLY_SB_SBREV) = 0x0000000b;
HOLLY_REJ (HOLLY_SB_G2ID) = 0x00000012;
HOLLY_REJ (HOLLY_ID) = 0x17fd11db;
HOLLY_REJ (HOLLY_REVISION) = 0x00000011;

All of these are read-only and if memory serves me right BIOS will (on purpose?) try to write to one of those - so make sure you don't let that happen. Those just say "Hello I'm HOLLY chip, rev. 2.42" - that's Dreamcast and newest DEV boxes.

This is not immediately required but since we are here, set:

/** System mode (R). */
#define HOLLY_SB_G1SYSM 0x005F74B0

HOLLY_REJ (HOLLY_SB_G1SYSM) = 0x00002000; // USA
HOLLY_REJ (HOLLY_SB_G1SYSM) = 0x00000800; // JP
HOLLY_REJ (HOLLY_SB_G1SYSM) = 0x00006000; // EU

Read-only as well, this is being latched from external HOLLY pins during power-on reset. Just pick one to match BIOS if you don't want game booting troubles in future.

/** TA FIFO remaining amount (R). */
#define HOLLY_SB_TFREM 0x005F6880

HOLLY_REJ (HOLLY_SB_TFREM) = 0x00000008;

Make it R/O and forget it exists as no code ever bothers to check that anyway - and it still works... smile

Now for connected video-cable - oh, this is fun. Part of the code below is kinda redundant as BIOS will read one (?) place and write the rest, but I can't quite remember the correct order so get all 3 places covered to be sure:

/** Sync pulse generator control. */
#define HOLLY_SPG_CONTROL 0x005F80D0

HOLLY_REJ (HOLLY_SPG_CONTROL) |= (g_kabel << 6); // video-cable code

Use 0 for VGA, 2 for RGB EURO/SCART, 3 for composite/UHF modulator (some docs say 1 is valid too, can't remember for what now).

// This is AICA-visible address space! Add 0x00700000 on SH4 side
#define AICA_AV_CTRL 0x00002c00

AICA_REJ (AICA_AV_CTRL) = (g_kabel << 8) | 0x0001; // same code as above

You'll also (and this I think is the most important place to get it right) need to set it up so that SH4 direct I/O ports will read the same video-cable code. Now this is... tricky. You can try to emulate the I/O and internal pullups and stuff or make a hack. Your choice.

Port A is 16-bits wide and BIOS expects to see ((g_kabel << 8) | 0x0003). Now the tricky part is the lowest 2 bits are some sort of cable connector being plugged detection (or something) and need to behave. BIOS will zero each bit then read back the port register - and expect both of them to be down. In other words, setting 3 - reads out as 3. Setting 1 or 2 (or 0 of course) reads out as zero. This took me day or so, here's my code for reading back (quick translation):

uint32_t w = 0;
(...)

// PDTRA:16
case 12:
// pull-ups not exactly supported
for (int i = 0; i < 16; i++)
{
// in/out bit (every 2nd bit)
if (SH4.PCTRA & (1 << (i << 1)))
w |= SH4.PDTRA & (1 << i);
else
w |= SH4.portA & (1 << i);
}
#ifdef SH4_DREAMCAST
if ((w & 0x0003) != 0x0003)
w &= ~0x0003;
#endif
break;

(...)
return w;

"SH4.portA" is a variable that pretends being Port A input. This is the thing I set with ((g_kabel << 8) | 0x0003).

That reminds me - there's a register SH4 has that is not covered in the manual (actually it seems there are more of those, but that's not important now). It's "Cache and TLB controller" region, register 12 (0xff000030). Add it, make it always return 0x00000080 and BIOS will skip some weird code trying to setup watchdog and some other stuff a retail console is not supposed to have. WEIRD. I strongly suggest you do this if BIOS gives you trouble.
More importantly BSC.RFCR _has_ to be either incremented per read or set to some big enough value (I increment it by 0x20). This is SDRAM refresh counter. Checked only during POST as far as I can tell. This is a must though.

This should get you past POST, though you might experience 10s or so delay if GD-ROM isn't detected (in our case - emulated). I think ARM might be broken but AICA timers must advance - and you will see the logo animation. Assuming you have TA+PVR2 covered, as BIOS uses 3D only (and heavily) and relies on the order-independant transparency much. Hopefully next thing to stop you will be time/date setup screen, which is "almost there" phase.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/02/08 12:59 AM

Awesome, thank you very very much! That will take a while to digest, but at least it gives me plenty to look at smile

Back in DSF-land the code from 14e4 to 1574 calculates the DISDL/DIPAN values (in manatee.drv 2.50, taken from kingshriek's full Skies of Arcadia rip). I don't see anything wrong ARM-emulation-wise there, but I'll have to see if I can rig it to use VBA's ARM or something instead so I can have comparison values smile
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/02/08 10:44 AM

Haven't looked into MAME ARM code recently but I remember it being somewhat... rough around the edges. Not that I blame anyone, the docs are really lacking. Also most (?) of the devices using that CPU actually have it Thumb-enabled and work mostly in that mode. AICA core has ARM7DI, not TDMI, and (possibly due to compiler?) I've never seen any DC code use Multiply Long instructions, halfwords (16-bit in ARM language) accesses, swaps, software interrupts, or BX jumps. Coprocessor is never used too but that's normal since there isn't one. There are special cases for block transfers where ARM would switch from priviledged mode to user mode but that's also never used (and this is probably still badly broken in MAME).

The rest, especially data processing, must be in top-shape though. Programs will expect correct R15/PC prefetch offsets being added when it's accessed and special cases of barrel shifter operation to be flawless. Be also sure you covered cases where ARM would read/modify/write a single byte in a 16-bit AICA register. In this case AICA will preserve the other byte intact.

Do you still have 16-bit samples wrong? I take it you upload them to SPU RAM by yourself, it's not SH4 doing that?
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/02/08 03:32 PM

It's known that there are data processing gremlins somewhere in our ARM7 core because there are definite CPU-related cockups in some Game Boy Advance games in MESS (in several games it takes the form of the software-mixed sound channels being distorted, and a few actually crash). It's just been a matter of finding simple test cases.

The Sega sound driver points software interrupts to the same "crash/do nothing" routine as the various ARM faults, so clearly they aren't using them. They're BIOS calls on the GBA though and very very heavily used there so I'm sure we emulate them properly anyway.

I haven't looked into the 16-bit samples yet, but as I said earlier DSFs once decoded are simply an image of the 2MB of AICA RAM at 0x00000000. You boot the ARM and it automatically starts playing, so there's no possibility of CPU transfer problems.
Posted By: MooglyGuy

Re: AO SDK release 1.3.2 available - 02/02/08 05:55 PM

Originally Posted By R. Belmont
It's known that there are data processing gremlins somewhere in our ARM7 core because there are definite CPU-related cockups in some Game Boy Advance games in MESS (in several games it takes the form of the software-mixed sound channels being distorted, and a few actually crash). It's just been a matter of finding simple test cases.


And in other games - in fact, most of them - it manifests itself in horrifically corrupted tile graphics.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/02/08 06:13 PM

I'm not convinced that isn't a graphics draw problem in some of the cases.
Posted By: MooglyGuy

Re: AO SDK release 1.3.2 available - 02/03/08 03:18 AM

Originally Posted By R. Belmont
I'm not convinced that isn't a graphics draw problem in some of the cases.


Possibly.

In my opinion, someone at some point needs to bring MAME / MESS's cycle-counting for the ARM7TDMI and GBA driver in general in line with that of VBA's. It'd make comparing traces a lot easier.
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/03/08 12:11 PM

I peeked into arm7core.c but this coding style is so incompatible with me. I tried to look for several problematic cases I had problems with, alas those seem to be taken care of properly.

I do have few suggestions:
- As far as I know TST-class (TST,TEQ,CMP,CMN) instructions never write to Rd, so HandleALU doesn't need to have "else" clause for that. Doesn't matter if Rd is being coded as PC in that case.
- I'm not 100% convinced that the immediate operand shift (I bit = 1) produces new carry value as output. Modify line 1241 to be "sc = GET_CPSR & C_MASK;" and see what happens. This is how I have it, seems to work?
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/03/08 03:57 PM

Hmm. That modification doesn't seem to have any effect that I can notice - ARMWrestler still passes and everything that was broken before still is.
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/03/08 06:57 PM

I don't really see anything odd in DP instructions. There are several other obscurities that don't look right, no sane compiler would make use of them but perhaps some hand-crafted assembly?
- Block transfer will always load the new value from memory over any base writeback. Easiest way to fix this is to modify lines 1638 & 1665 to check for presence of rb in bit mask. If it's there, the writeback should not happen.
- Block transfer store does indeed add +12 to stored R15. There's a log to catch that in the code but no actual addition takes place?
- Block transfer store with base writeback will store either unmodified base, if it's the very first register on the list, or fully modified in any other case. That by the way means you need to check the mask in correct order - and that is R0 first, R15 last. Decrementing transfers actually happen bottom to top beacuse of that.
- I'm quite puzzled as to how PSR Transfer is supposed to work. There are tons of variables in that procedure, named "newval", actualy holding the old value, then being refreshed, and then not used? Lines 1202 & 1205 - is this correct?
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/03/08 07:13 PM

The problem we're going to have here is that I didn't write most of the ARM-mode code so I don't understand it either. ARM7 started as a fork of MAME's ARM6 core written for PinMAME. I adapted it to normal MAME/MESS and MG and I added the Thumb support and did a ton of bugfixing (we started off with 1 GBA game running and now almost the entire Good* set at least boots).

PSR Transfer is correct in all cases I've encountered it, but it's rarely used.

Block transfer store is not my code, but I see R15 getting +12 at line 1623. I don't quite understand the rest of what you're trying to say regarding the base writeback.
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/03/08 07:37 PM

Right. There is +12/-12 pair in the function above... Again, not exactly my coding style.
PSR transfers are rare, true, and this is exactly why it needs to be re-checked. Any frequently used instruction being wrong would crash the emu right away. I'm browsing .122 sources w/o patches of any kind, and I have code that looks like this:

(...)

if (insn & 0x00010000)
{
newval = (newval & 0xffffff00) | (val & 0xff);
}
if (insn & 0x00020000)
{
newval = (newval & 0xffff00ff) | (val & 0xff00);
}


(...)

// force valid mode
newval |= 0x10;

//Update the Register
SET_REGISTER(reg, val);

//Switch to new mode if changed
if( (val & MODE_FLAG) != oldmode)
SwitchMode(GET_MODE);

I belive it's supposed to be newval in that SET_REGISTER, ane the line below.

As for base writebacks in block transfer - as I said, this doesn't look right but should not be happening in any sane code.
The problem is when you store the base register too and writeback is specified. If the base is on the list it needs to be stored already modified by writeback. Unless it's the first register on the list, then it's stored as-is.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/03/08 07:46 PM

Good catch on the PSR transfer, that was definitely wrong.

The two instances of "R15 -= 4; // SJE: I forget why I did this" looked suspect - I commented them out and Buffy for the GBA no longer reboots when you press START, but the Sega DSF sound driver goes berzerk and crashes so I guess there's a matching bug someplace else.

I don't suppose you could just send me your ARM emulator and I could hook it up and run parallel traces? I've used private source from a number of people for reference on various projects and not leaked or misused any of it.
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/03/08 08:21 PM

Well... I suppose. How good is your Polish? Because I code for myself and I don't name variables, procedures or make comments in English unless the source is to be open from start smile And trust me, it's not very feasible to translate all that now.

Please also keep in mind this is my second attempt at ARM - the first one got so messed up I just started again clean with more DC and less general emulation in mind. In other words: I never got to implement opcodes that aren't part of DC programs. Not much point in doing so as it's better to catch missing/unemulated instruction than write a procedure and never get to test it.
In that aspect it will be quite a task to get my code working with anything MAME-related. It could be used as some point of reference but not much more I'm afraid.

Still interested?

EDIT: That -4 code probably makes up for prefetch offset on R15. You need to have it correct on both write and read. My code is constructed in a bit different way - I add +4 to PC the moment I fetch another opcode. All other code accounts for it. This is actually pretty elegant solution, almost like the hardware does it. I don't correct reads, rather my writes/jumps/interrupts transfer are all aware of the fact that R15 is ahead of the code.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/03/08 08:28 PM

I ported a large GUI app with comments entirely in Japanese once, so this oughta be easy. Also, it wouldn't be targetting MAME, I'd just want to hook it up in AO/AOSDK. And the lack of support for opcodes Sega doesn't use actually makes it simpler (less code to deal with).

Oh, and ZiNc has a fair amount of Polish variables and comments and I've handled it OK :-) PM me and we can set something up.
Posted By: Richard Bannister

Re: AO SDK release 1.3.2 available - 02/03/08 08:47 PM

You didn't mention that you ported the god-awful code that is/was Audio Overload once too... though having said that, I never sent you the AO1.x code. Now that was truly something to behold.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/03/08 09:00 PM

AO's not as bad as you think. I've dealt with far worse :-)
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/05/08 04:48 AM

Just so people know we haven't completely stalled out, I was able to successfully compile AO's DSF support using Makaron's ARM7 interpreter (Deunan writes gorgeous code, it was no trouble at all to work with even with Polish function names) and to probably nobody's surprise it's sending correct DISDL/DIPAN values to the AICA. So we'll see what we can see now :-)
Posted By: Stiletto

Re: AO SDK release 1.3.2 available - 02/05/08 05:08 AM

Originally Posted By R. Belmont
Deunan writes gorgeous code


I've been lovin' his blog, too. A fun read, and I'm much happier with the more frequent English posts, too.
http://dknute.livejournal.com/
smile
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/08/08 02:54 AM

New developer-only SDK 1.4.0a2:

http://rbelmont.mameworld.info/aosdk_140a2.zip

- Using Deunan Knute's ARM7 so DISDL/DIPAN are written properly
- Reenabled use of DISDL/DIPAN
- Tried to fix 16-bit samples. Failed smirk

Reminder: do not download this if you want to just listen to music - this is for folks who want to contribute to the AICA emulation only right now.
Posted By: kingshriek

Re: AO SDK release 1.3.2 available - 02/08/08 04:54 AM

And here are my latest updates:

Code:
diff -Nru aosdk_base/eng_dsf/aica.c aosdk/eng_dsf/aica.c
--- aosdk_base/eng_dsf/aica.c	2008-02-07 21:46:42.000000000 -0800
+++ aosdk/eng_dsf/aica.c	2008-02-07 20:41:31.000000000 -0800
@@ -69,14 +69,14 @@
 #define ALFOWS(slot)		((slot->udata.data[0x1c/2]>>0x3)&0x0003)
 #define ALFOS(slot)		((slot->udata.data[0x1c/2]>>0x0)&0x0007)
 
-#define ISEL(slot)		((slot->udata.data[0x20/2]>>0x4)&0x000F)
-#define IMXL(slot)		((slot->udata.data[0x20/2]>>0x0)&0x000F)
+#define ISEL(slot)		((slot->udata.data[0x20/2]>>0x0)&0x000F)
+#define IMXL(slot)		((slot->udata.data[0x20/2]>>0x4)&0x000F)
 
 #define DISDL(slot)		((slot->udata.data[0x24/2]>>0x8)&0x000F)
 #define DIPAN(slot)		((slot->udata.data[0x24/2]>>0x0)&0x001F)
 
-#define EFSDL(slot)		((AICA->EFSPAN[slot/2]>>8)&0x000f)
-#define EFPAN(slot)		((AICA->EFSPAN[slot/2]>>0)&0x001f) 
+#define EFSDL(slot)		((AICA->EFSPAN[slot*4]>>8)&0x000f)
+#define EFPAN(slot)		((AICA->EFSPAN[slot*4]>>0)&0x001f) 
 
 //Envelope times in ms
 static const double ARTimes[64]={100000/*infinity*/,100000/*infinity*/,8100.0,6900.0,6000.0,4800.0,4000.0,3400.0,3000.0,2400.0,2000.0,1700.0,1500.0,
@@ -116,6 +116,7 @@
 	} udata;
 	UINT8 active;	//this slot is currently playing
 	UINT8 *base;		//samples base address
+	UINT32 prv_addr;    // previous play address (for ADPCM)
 	UINT32 cur_addr;	//current play address (24.8)
 	UINT32 nxt_addr;	//next play address
 	UINT32 step;		//pitch step (24.8)
@@ -124,18 +125,21 @@
 	struct _LFO PLFO;		//Phase LFO
 	struct _LFO ALFO;		//Amplitude LFO
 	int slot;
-	int cur_sample;    //current ADPCM sample
-	int nxt_sample;    //next ADPCM sample
-	int cur_quant;     //current ADPCM step
-	int nxt_quant;     //next ADPCM step
-	int do_adpcm;      //do ADPCM decoding
+	int cur_sample;       //current ADPCM sample
+	int nxt_sample;       //next ADPCM sample
+	int cur_quant;        //current ADPCM step
+	int nxt_quant;        //next ADPCM step
+	int sample_lsa;       // current ADPCM sample at loop start
+	int quant_lsa;        // current ADPCM step at loop start
+	int do_adpcm;         // do ADPCM decoding - number of iterations
+	int loop_adpcm;       // ADPCM sampler has passed LSA
 };
 
 
 #define MEM4B(aica)		((aica->udata.data[0]>>0x0)&0x0200)
 #define DAC18B(aica)		((aica->udata.data[0]>>0x0)&0x0100)
 #define MVOL(aica)		((aica->udata.data[0]>>0x0)&0x000F)
-#define RBL(aica)		((aica->udata.data[2]>>0x13)&0x0003)
+#define RBL(aica)		((aica->udata.data[2]>>0xD)&0x0003)
 #define RBP(aica)		((aica->udata.data[2]>>0x0)&0x0fff)
 #define MOFULL(aica)   		((aica->udata.data[4]>>0x0)&0x1000)
 #define MOEMPTY(aica)		((aica->udata.data[4]>>0x0)&0x0800)
@@ -415,7 +419,7 @@
 
 	slot->active=1;
 	slot->Backwards=0;
-	slot->cur_addr=0; slot->nxt_addr=1<<SHIFT;
+	slot->cur_addr=0; slot->nxt_addr=1<<SHIFT; slot->prv_addr=-1;
 	start_offset = SA(slot);	// AICA can play 16-bit samples from any boundry
 	slot->base=&AICA->AICARAM[start_offset];
 	slot->step=AICA_Step(slot);
@@ -427,6 +431,7 @@
 	if (PCMS(slot) >= 2)
 	{
 		slot->do_adpcm=1;
+		slot->loop_adpcm=0;
 		InitADPCM(&(slot->cur_sample), &(slot->cur_quant));
 		InitADPCM(&(slot->nxt_sample), &(slot->nxt_quant));
 	}
@@ -445,7 +450,7 @@
 	{
 		slot->active=0;
 	}
-	slot->udata.data[0]&=~0x800;
+	slot->udata.data[0]&=~0x4000;
 }
 
 #define log_base_2(n) (log((float) n)/log((float) 2))
@@ -622,7 +627,7 @@
 						}
 					}
 				}
-				slot->udata.data[0]&=~0x1000;
+				slot->udata.data[0]&=~0x8000;
 			}
 			break;
 		case 0x18:
@@ -657,9 +662,9 @@
 					AICA->DSP.RBL=8*1024;
 				else if(v==1)
 					AICA->DSP.RBL=16*1024;
-				if(v==2)
+				else if(v==2)
 					AICA->DSP.RBL=32*1024;
-				if(v==3)
+				else if(v==3)
 					AICA->DSP.RBL=64*1024;
 			}
 			break;
@@ -857,7 +862,11 @@
 	}
 	else if(addr<0x3000)
 	{
-		if (addr < 0x28be)
+		if (addr <= 0x2044)
+		{
+			v = AICA->EFSPAN[addr&0x7f];
+		}
+		else if (addr < 0x28be)
 		{
 			AICA_UpdateRegR(AICA, addr&0xff);
 			v= *((unsigned short *) (AICA->udata.datab+((addr&0xff))));
@@ -925,6 +934,8 @@
 	UINT32 addr1,addr2,addr_select;                                   // current and next sample addresses
 	UINT32 *addr[2]      = {&addr1, &addr2};                          // used for linear interpolation
 	UINT32 *slot_addr[2] = {&(slot->cur_addr), &(slot->nxt_addr)};    //
+	int    *adpcm_sample[2] = {&(slot->cur_sample), &(slot->nxt_sample)};
+	int    *adpcm_quant[2]  = {&(slot->cur_quant), &(slot->nxt_quant)};
 
 	if(SSCTL(slot)!=0)	//no FM or noise yet
 		return 0;
@@ -942,8 +953,8 @@
 	}
 	else if(PCMS(slot) == 0) 
 	{
-		addr1=(slot->cur_addr>>(SHIFT-1));
-		addr2=(slot->nxt_addr>>(SHIFT-1));
+		addr1=(slot->cur_addr>>(SHIFT-1))&0x1ffffe;
+		addr2=(slot->nxt_addr>>(SHIFT-1))&0x1ffffe;
 	}
 	else
 	{
@@ -963,11 +974,11 @@
 	}
 	else if (PCMS(slot) == 0)	//16 bit signed
 	{
-		UINT8 *p1=(UINT8 *) (AICA->AICARAM+((SA(slot)+addr1)&0x1fffff));
-		UINT8 *p2=(UINT8 *) (AICA->AICARAM+((SA(slot)+addr2)&0x1fffff));
+		INT16 *p1=(signed short *) (AICA->AICARAM+((SA(slot)+addr1)&0x1fffff));
+		INT16 *p2=(signed short *) (AICA->AICARAM+((SA(slot)+addr2)&0x1fffff));
 		INT32 s;
 		INT32 fpart=slot->cur_addr&((1<<SHIFT)-1);
-		s=(int) ((INT16)(p1[1] | (p1[0]<<8)))*((1<<SHIFT)-fpart)+(int) ((INT16)(p2[1] | (p2[0]<<8)))*fpart;
+		s=(int) LE16(p1[0])*((1<<SHIFT)-fpart)+(int) LE16(p2[0])*fpart;
 		sample=(s>>SHIFT);
 	}
 	else	// 4-bit ADPCM
@@ -976,13 +987,19 @@
 		UINT8 *p2=(unsigned char *) (AICA->AICARAM+((SA(slot)+(addr2>>1))&0x1fffff));
 		INT32 s;
 		INT32 fpart=slot->cur_addr&((1<<SHIFT)-1);
-		if (slot->do_adpcm)
+		UINT32 addr=slot->prv_addr>>SHIFT;
+		while (slot->do_adpcm--)
+		{
+			int shift1,delta1;
+			addr += 1;
+			shift1 = 4*((addr&1)^1);
+			delta1 = (*p1>>shift1)&0xF;
+//			printf("DEBUG: addr %04X sample %+06d delta %01X quant %05d\n",addr,slot->cur_sample,delta1,slot->cur_quant);
+			DecodeADPCM(&(slot->cur_sample),delta1,&(slot->cur_quant));
+		}
 		{
-			int shift1 = 4*((addr1&1)^1);
 			int shift2 = 4*((addr2&1)^1);
-			int delta1 = (*p1>>shift1)&0xF;
 			int delta2 = (*p2>>shift2)&0xF;
-			DecodeADPCM(&(slot->cur_sample),delta1,&(slot->cur_quant));
 			slot->nxt_sample=slot->cur_sample;
 			slot->nxt_quant=slot->cur_quant;
 			DecodeADPCM(&(slot->nxt_sample),delta2,&(slot->nxt_quant));
@@ -992,21 +1009,27 @@
 	}
 
 	// Only do an ADPCM decode when crossing a whole-address boundary
-	if(((slot->cur_addr+step)>>SHIFT)>((slot->cur_addr)>>SHIFT)) slot->do_adpcm=1;
-	else slot->do_adpcm=0;
+	slot->do_adpcm = ((slot->cur_addr+step)>>SHIFT)-((slot->cur_addr)>>SHIFT);
 	
+	slot->prv_addr=slot->cur_addr;
 	slot->cur_addr+=step;
 	slot->nxt_addr=slot->cur_addr+(1<<SHIFT);
-	
+
 	addr1=slot->cur_addr>>SHIFT;
 	addr2=slot->nxt_addr>>SHIFT;
-	
+
 	if(addr1>=LSA(slot))
 	{
 		if(LPSLNK(slot) && slot->EG.state==ATTACK)
 			slot->EG.state = DECAY1;
+		if(PCMS(slot)==2 && !(slot->loop_adpcm))
+		{
+			slot->sample_lsa = slot->cur_sample;
+			slot->quant_lsa = slot->cur_quant;
+			slot->loop_adpcm = 1;
+		}
 	}
-	
+
 	for (addr_select=0;addr_select<2;addr_select++)
 	{
 		INT32 rem_addr;
@@ -1024,6 +1047,11 @@
 			{
 				rem_addr = *slot_addr[addr_select] - (LEA(slot)<<SHIFT);
 				*slot_addr[addr_select]=(LSA(slot)<<SHIFT) + rem_addr;
+				if(PCMS(slot)==2 && addr_select==0)
+				{
+					*adpcm_sample[addr_select] = slot->sample_lsa;
+					*adpcm_quant[addr_select] = slot->quant_lsa;
+				}
 			}
 			break;
 		}
@@ -1047,7 +1075,6 @@
 {
 	INT16 *bufr,*bufl;
 	int sl, s, i;
-	struct _SLOT *s2 = &AICA->Slots[39];
 
 	bufr=bufferr;
 	bufl=bufferl;
@@ -1064,7 +1091,7 @@
 			if(AICA->Slots[sl].active)
 			{
 				struct _SLOT *slot=AICA->Slots+sl;
-				unsigned short Enc;
+				unsigned int Enc;
 				signed int sample;
 
 				sample=AICA_UpdateSlot(AICA, slot);
@@ -1081,14 +1108,14 @@
 			AICA->BUFPTR&=63;
 		}
 
-#if 0 	// actually works somewhat, but not yet
+#if 1
 		AICADSP_Step(&AICA->DSP);
 
 		for(i=0;i<16;++i)
 		{
 			if(EFSDL(i))
 			{
-				unsigned short Enc=((EFPAN(i))<<0x8)|((EFSDL(i))<<0xd);
+				unsigned int Enc=((EFPAN(i))<<0x8)|((EFSDL(i))<<0xd);
 				smpl+=(AICA->DSP.EFREG[i]*AICA->LPANTABLE[Enc])>>SHIFT;
 				smpr+=(AICA->DSP.EFREG[i]*AICA->RPANTABLE[Enc])>>SHIFT;
 			}
diff -Nru aosdk_base/eng_dsf/aicadsp.c aosdk/eng_dsf/aicadsp.c
--- aosdk_base/eng_dsf/aicadsp.c	2008-02-07 21:44:10.000000000 -0800
+++ aosdk/eng_dsf/aicadsp.c	2008-02-07 20:37:30.000000000 -0800
@@ -86,41 +86,41 @@
 #endif
 	for(step=0;step</*128*/DSP->LastStep;++step)
 	{
-		UINT16 *IPtr=DSP->MPRO+step*4;
-
+		UINT16 *IPtr=DSP->MPRO+step*8;
+				
 //      if(IPtr[0]==0 && IPtr[1]==0 && IPtr[2]==0 && IPtr[3]==0)
 //          break;
 
-		UINT32 TRA=(IPtr[0]>>8)&0x7F;
-		UINT32 TWT=(IPtr[0]>>7)&0x01;
-		UINT32 TWA=(IPtr[0]>>0)&0x7F;
-
-		UINT32 XSEL=(IPtr[1]>>15)&0x01;
-		UINT32 YSEL=(IPtr[1]>>13)&0x03;
-		UINT32 IRA=(IPtr[1]>>6)&0x3F;
-		UINT32 IWT=(IPtr[1]>>5)&0x01;
-		UINT32 IWA=(IPtr[1]>>0)&0x1F;
-
-		UINT32 TABLE=(IPtr[2]>>15)&0x01;
-		UINT32 MWT=(IPtr[2]>>14)&0x01;
-		UINT32 MRD=(IPtr[2]>>13)&0x01;
-		UINT32 EWT=(IPtr[2]>>12)&0x01;
-		UINT32 EWA=(IPtr[2]>>8)&0x0F;
-		UINT32 ADRL=(IPtr[2]>>7)&0x01;
-		UINT32 FRCL=(IPtr[2]>>6)&0x01;
-		UINT32 SHIFT=(IPtr[2]>>4)&0x03;
-		UINT32 YRL=(IPtr[2]>>3)&0x01;
-		UINT32 NEGB=(IPtr[2]>>2)&0x01;
-		UINT32 ZERO=(IPtr[2]>>1)&0x01;
-		UINT32 BSEL=(IPtr[2]>>0)&0x01;
-
-		UINT32 NOFL=(IPtr[3]>>15)&1;		//????
-		UINT32 COEF=(IPtr[3]>>9)&0x3f;
-
-		UINT32 MASA=(IPtr[3]>>2)&0x1f;	//???
-		UINT32 ADREB=(IPtr[3]>>1)&0x1;
-		UINT32 NXADR=(IPtr[3]>>0)&0x1;
-
+		UINT32 TRA=(IPtr[0]>>9)&0x7F;
+		UINT32 TWT=(IPtr[0]>>8)&0x01;
+		UINT32 TWA=(IPtr[0]>>1)&0x7F;
+
+		UINT32 XSEL=(IPtr[2]>>15)&0x01;
+		UINT32 YSEL=(IPtr[2]>>13)&0x03;
+		UINT32 IRA=(IPtr[2]>>7)&0x3F;
+		UINT32 IWT=(IPtr[2]>>6)&0x01;
+		UINT32 IWA=(IPtr[2]>>1)&0x1F;
+
+		UINT32 TABLE=(IPtr[4]>>15)&0x01;
+		UINT32 MWT=(IPtr[4]>>14)&0x01;
+		UINT32 MRD=(IPtr[4]>>13)&0x01;
+		UINT32 EWT=(IPtr[4]>>12)&0x01;
+		UINT32 EWA=(IPtr[4]>>8)&0x0F;
+		UINT32 ADRL=(IPtr[4]>>7)&0x01;
+		UINT32 FRCL=(IPtr[4]>>6)&0x01;
+		UINT32 SHIFT=(IPtr[4]>>4)&0x03;
+		UINT32 YRL=(IPtr[4]>>3)&0x01;
+		UINT32 NEGB=(IPtr[4]>>2)&0x01;
+		UINT32 ZERO=(IPtr[4]>>1)&0x01;
+		UINT32 BSEL=(IPtr[4]>>0)&0x01;
+
+		UINT32 NOFL=(IPtr[6]>>15)&1;		//????
+		UINT32 COEF=step;
+
+		UINT32 MASA=(IPtr[6]>>9)&0x1f;	//???
+		UINT32 ADREB=(IPtr[6]>>8)&0x1;
+		UINT32 NXADR=(IPtr[6]>>7)&0x1;
+		
 		INT64 v;
 
 		//operations are done at 24 bit precision
@@ -208,7 +208,7 @@
 		if(YSEL==0)
 			Y=FRC_REG;
 		else if(YSEL==1)
-			Y=DSP->COEF[COEF]>>3;	//COEF is 16 bits
+			Y=DSP->COEF[COEF<<1]>>3;	//COEF is 16 bits
 		else if(YSEL==2)
 			Y=(Y_REG>>11)&0x1FFF;
 		else if(YSEL==3)
@@ -276,7 +276,7 @@
 		if(MRD || MWT)
 		//if(0)
 		{
-			ADDR=DSP->MADRS[MASA];
+			ADDR=DSP->MADRS[MASA<<1];
 			if(!TABLE)
 				ADDR+=DSP->DEC;
 			if(ADREB)
@@ -290,7 +290,7 @@
 			//ADDR<<=1;
 			//ADDR+=DSP->RBP<<13;
 			//MEMVAL=DSP->AICARAM[ADDR>>1];
-			ADDR+=DSP->RBP<<12;
+			ADDR+=DSP->RBP<<10;
 			if(MRD && (step&1))	//memory only allowed on odd? DoA inserts NOPs on even
 			{
 				if(NOFL)
@@ -339,9 +339,9 @@
 	DSP->Stopped=0;
 	for(i=127;i>=0;--i)
 	{
-		UINT16 *IPtr=DSP->MPRO+i*4;
+		UINT16 *IPtr=DSP->MPRO+i*8;
 
-		if(IPtr[0]!=0 || IPtr[1]!=0 || IPtr[2]!=0 || IPtr[3]!=0)
+		if(IPtr[0]!=0 || IPtr[2]!=0 || IPtr[4]!=0 || IPtr[6]!=0)
 			break;
 	}
 	DSP->LastStep=i+1;
diff -Nru aosdk_base/eng_dsf/aicadsp.h aosdk/eng_dsf/aicadsp.h
--- aosdk_base/eng_dsf/aicadsp.h	2008-02-07 21:44:10.000000000 -0800
+++ aosdk/eng_dsf/aicadsp.h	2008-02-07 20:37:52.000000000 -0800
@@ -12,9 +12,9 @@
 
 //context
 
-	INT16 COEF[128];		//16 bit signed
-	UINT16 MADRS[64];	//offsets (in words), 16 bit
-	UINT16 MPRO[128*4*2];	//128 steps 64 bit
+	INT16 COEF[128*2];		//16 bit signed
+	UINT16 MADRS[64*2];	//offsets (in words), 16 bit
+	UINT16 MPRO[128*4*2*2];	//128 steps 64 bit
 	INT32 TEMP[128];	//TEMP regs,24 bit signed
 	INT32 MEMS[32];	//MEMS regs,24 bit signed
 	UINT32 DEC;


- Fixed 16-bit samples smile
- Swapped IMXL/ISEL (thanks Deunan!)
- Made all of the necessary changes (or so I think) to get the DSP working
- Changed LPANTABLE/RPANTABLE lookup to use int instead of short (since we're dealing with 0x20000 values now).
- Changed the ADPCM decoding loop so that it always operates a single step at a time. ADPCM still saturates far too much - still some work to be done here.
Posted By: Richard Bannister

Re: AO SDK release 1.3.2 available - 02/08/08 07:58 AM

Yegads. Deunan's code really is nice. I assume Makaron is DirectX based? If not I'd love to do a Mac port...
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/08/08 09:41 AM

If I may have a suggestion: AICA should be addressing samples, not bytes. Change it and most of your code will become universal - as only the actual fetch from memory will have to convert sample number to data address.

As for ADPCM - this approach will never work. It might for non-looped samples when the sound pitch matches the sound's own, but that's about it. I'm not so sure current skipping is correct for 16-bit cases as well. Things to note:
- ADPCM always starts with lowest nible, then moves to high, then to next byte
- If the sound pitch is changed, the step will not be one. ADPCM decoder still needs to refresh it's internal state for _every_ sample on it's way to current one. That also means you need to implement proper skipping for step < 1 - this will be easier if you follow my first suggestion.
- I understand you're doing interpolation between two consecutive samples. Be careful with that on ADPCM. I'd disable it for now for those samples.
- And there's the loop processing smile But one thing at a time.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/08/08 05:35 PM

1.4.0a3 (still developer only):

http://rbelmont.mameworld.info/aosdk_140a3.zip

Includes kingshriek's patch above plus I rewrote ADPCM (including Deunan's hint that the samples go 10 32 54 76 instead of 01 23 45 67). Things still get crunchy due to DC offset drift (it's quite noticeable in AO with the 'scope) so it may be our actual decode constants aren't quite right, but in general it sounds far better.

For end users following along at home, you can hear the current code playing Sakura Taisen 4 here:

http://rbelmont.mameworld.info/sakutai4.mp3
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/08/08 08:09 PM

Out of curiosity, where did you get that tune? And is it the one that runs on the "Press START" screen?
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/08/08 08:28 PM

It's from kingshriek's rip page. I don't know where in game it plays, but it's the same song as the title screen tune on "Hanagumi Taisen Columns - Sakura Wars" in MAME. The metadata says it's "Declaration! Imperial Floral Assault Group - Final Chapter (Imperial Castle Version)", which doesn't sound very title-screen-y to me.
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/08/08 08:48 PM

Ha! What a small world we live in smile
Anyway, the new ADPCM looks so much better. But if I read this right it'll still misbehave on the very last sample. In case there's a loop it will try to fetch one more byte over LEA rather then look at the first one again. I still say ADPCM + interpolation = tricky. And that's just one of the caveats.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/08/08 09:03 PM

Well, it's not trying to interpolate ADPCM at the moment anyway, although I didn't pay a lot of attention to the looping. Is our basic ADPCM decode correct to your knowledge? I got it from ElSemi but I have no real way to validate it smile
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/08/08 09:56 PM

There's apparently a rumor that all of kingshriek's patches for the SCSP in MAME/AOSDK were simply Neill Corlett's Highly Experimental code. I'm sorry I even have to address something this mindbogglingly stupid, but here goes:

1) I was aware that KS had the HE code and I did keep an eye on the patches accordingly.

2) Anyone with decent C/C++ experience would agree that ElSemi's SCSP code in MAME has a pretty distinctive style and general way of doing things. Everything KS submitted fit that style and didn't attempt to make any major changes to how things worked, even when that would have been a good idea :-)

3) Some of the bugs fixed in MAME were also present in HE, so the fix had to have been independently derived.

4) FM mode doesn't exist in HE (at all, to my knowledge), so it was clearly all original engineering.

And the trump card:

5) Lord Nightmare asked Neill about this on IRC and Neill looked at the code and said there was no copying.
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/08/08 10:05 PM

It's good stuff - I would know, I found it in SCSP sources few months ago and it replaced my own floating-point based decoder smile
Truth be told all you need is quantization width data and the clipping values (127 & 24576) - it's all in docs. What isn't there is how this works on loops smile
As for those loops - I've just had a very nice idea, need to test it. Keep your fingers crossed, if this solves my little mystery it will also benefit your ADPCM code.
Posted By: Stiletto

Re: AO SDK release 1.3.2 available - 02/09/08 06:38 AM

Originally Posted By R. Belmont
There's apparently a rumor that all of kingshriek's patches for the SCSP in MAME/AOSDK were simply Neill Corlett's Highly Experimental code.


WTF - anyone could have told that it wasn't copied. _I_ can tell that, and I don't even have the HE code. n00bs! kiddiez! OMGWTFBBQ gaahhh...

- Stiletto
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/09/08 08:22 AM

I think it's an extension of the popular opinion that MAMEdevs are all really stupid and we've sort of "duh"ed ourselves through ~7000 romsets by some combination of theft and pure luck. Especially that Aaron guy. wink
Posted By: Knurek

Re: AO SDK release 1.3.2 available - 02/09/08 09:40 AM

Could happen, I guess, monkeys and Shakespeare... :P
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/09/08 11:42 AM

My test was rather inconclusive.

The real problem with ADPCM is how exactly it behaves on loop return. Let's assume AICA does interpolation as some soures claim. Does that mean it also interpolates ADPCM sounds? If so, how does it fetch pos+1 sample, is decoder state preserved or modified - because if it is modified then it's always +1 ahead of actual play position. Is there really always one more valid sample after LEA to allow for interpolation?

Hell, I don't even know what's the correct loop end point, because docs says it goes 0, 1, 2, ..., LEA (inclusive) -> LSA+1, LSA+2, ... My own observations (though all I can do in that matter is closely monitor sample position counter) show this to be incorrect, it's 0, 1, 2, ..., LEA-1 -> LSA, LSA+1, ...

I got my own code to work in almost all cases. Almost, with one exception named "Soul Reaver" - which still distorts in-game dialogues from time to time.
Well, it's back to the drawing board for me smile I will help you with ADPCM but I suggest you try to discover things on your own as I'm clearly overlooking something again and again. On the bright side, I now know what it was that caused hissing when I tried to interpolate ADPCM and that was a silly mistake on my part.
Posted By: etabeta78

Re: AO SDK release 1.3.2 available - 02/09/08 12:17 PM

Originally Posted By R. Belmont
I think it's an extension of the popular opinion that MAMEdevs are all really stupid and we've sort of "duh"ed ourselves through ~7000 romsets by some combination of theft and pure luck. Especially that Aaron guy. wink


as well as the atari/midway hardwares no one else tried to emulate, cps2 encryption and neogeo rewritten emulation (with all the flickering hardware originally had and other emus never showed)

there will always be people which do not believe to the facts, so don't bother

more on topic, I really like these progresses on DSF... kudos to all of you involved smile
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/09/08 10:29 PM

It wasn't SCSP. I remember it now - I wanted to ditch my DirectSound based AICA and do a software mixer instead. Looking for some more information on Yamaha-based chips I found ymz280b.c in MAME sources. Multiplying every magic value by 256 to get an integer constant - somehow that never occured to me.

I've brought this up for a reason. I've peeked into this file again and I see that ADPCM decoder stores loop-entry state on first pass and restores it on each jump back. I gotta try this too - but at this very moment I'm in middle of swapping one of my HDDs and that will take some time. So feel free to experiment.

Also, I have a request of sorts. Love Hina game for DC has some sequenced music running on the title screen - but it was always very broken on Makaron. If this is one of those DSF things then perhaps someone could tell me how to extract it. AO has a bit different timer engine and interrupts processing - it would help me narrow down the source of this bug if I AO plays this tune right (or at least in a different way).
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/09/08 11:33 PM

I've not done any DSF ripping of my own yet, but perhaps kingshriek has that game and could take a look? (Alternatively, if Makaron can dump the 2 MB of AICA RAM while that song is playing, I might be able to create a working DSF from it).

Incidentally, Samuele sent in some nice SH4 and Naomi improvements today - the PVR-TA is less buggy, at least for what displays, and the dumped cartridges all start to boot now. I gotta try and bang on Dreamcast soon :-)
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/10/08 12:23 AM

It can, I've sent you memory image a moment ago.

I don't really know that much about Naomi, but I do know the GD-ROMs are encrypted. All I could tell by looking at big file (I assume that's 1:1 DIMM image) is the key is probably 8-bytes long, since some data repeats every 8 bytes. That's probably zero-padding or SEGASEGA.
And there's this strange NAOMIGD.BIN file that seems binary but has all bytes < 0x80...
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/10/08 01:20 PM

I see we all follow the same source when it comes to calculating AICA volume levels smile Pity, as I belive it's a bit off (too loud). Then again it could be a bug somewhere else.

Anyway, there's a value missing in your SDLT table. It's -1000000.0, -39.0, -36.0, (...) and should be -1000000.0, -42.0, -39.0, -36.0, (...) In those 4-bits volumes it's always 3dB spacing. The first one could very well be -45, but that's pretty much zero anyway.

I've tried this saving/restoring ADPCM state and IMO it's wrong. To be sure I need to test it on looped type 2 where return position is not zero - but for now I'll stay with my code.
Posted By: kingshriek

Re: AO SDK release 1.3.2 available - 02/10/08 02:09 PM

Good catch. With that fix, the DSP is clipping much less than it did before, thanks to the reduced IMXL levels.

Speaking of the DSP, I noticed that aicadsp.c and aicadsp.h aren't updated with my last patch in the latest AOSDK package. Any problems with it or was this just a case of forgetting to patch them?

EDIT: Here's a DSF set for Love Hina for those interested --> http://www.sendspace.com/file/bi3qwz.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/10/08 03:14 PM

KS: sorry about that, I guess I messed up patching.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/10/08 04:44 PM

New development AOSDK 1.4.0a4:

http://rbelmont.mameworld.info/aosdk_140a4.zip

- Includes AICA DSP changes (doh)
- Includes SDLT fix above
- Includes latest DK ARM7 core + MAME additions (LDRH/STRH, SWI, BX to word-aligned addresses instead of dword, and a port of MAME's latest PSR transfer function)
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/10/08 05:01 PM

Originally Posted By kingshriek
DSF set for Love Hina for those interested

Much appreciated smile

Originally Posted By R. Belmont
New development AOSDK 1.4.0a4

Uh... What's the fastest way of getting this into binary form, that will eat a DSF and output a WAV? smile
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/10/08 05:06 PM

Well, WAV is a bit iffy, but you can compile it with the usual MAME/MinGW toolchain and it'll play DSFs on your speakers smile

Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/10/08 05:26 PM

Speakers will do and MinGW is what I use to compile Makaron.
BTW - I see the ARM guys got interested in the code. But why stop at PSR Transfers - maybe this is the only thing they changed in the specs since ARM7 but I wouldn't mind them making sure the rest is OK too smile

And since we are at it, it wasn't 24th bit but rather S & H bits are ignored and so are the 4 zero bits that make the upper part of the offset in halfword opcodes. Like this:

#ifdef ARM7_THUMB
else if ((ARM7.kod & 0x0fb00ff0) == 0x01000090)
#else
else if ((ARM7.kod & 0x0fb00090) == 0x01000090)
#endif
R_SWP ();

Consider this unsafe though. May be Dreamcast-specific.

EDIT: Well what do you know, I typed "make" and I got an EXE. And here I though it takes some arcane knowledge smile
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/10/08 05:48 PM

He's already submitted several other fixes for MAME's core (none of them fixed the DISDL/DIPAN issue but the graphics decompression in WarioWare works properly now), and identified a major issue with the data processing: the corner cases for shifts are different depending on if they're immediate or register. I believe you get that right though :-)

Also, I should note that the AOSDK example app is not really user friendly - you must press ^C to stop it playing :-)
Posted By: Knurek

Re: AO SDK release 1.3.2 available - 02/10/08 06:06 PM

How is that not user friendly, compared to, say, vi? smile
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/10/08 06:07 PM

My ARM code is apparently based on obsolete specs frown That not much of an issue with AICA ARM, as it's even older, but I guess it really breaks new cores. Those bits that select which part of PSR to touch? Those are constant in my manual. I was a bit suspicious of that, seeing how the old MAME core actually cared, so I think I got the opcode decoder right.
Funny thing though... that Love Hina tunes plays right only with the revised PSR Transfer, my wonn't cut it. But when I copied that into Makaron nothing changed... it's a broken as always was. Curious. I guess it's digging time...

And CTRL+C was the first thing that came to my mind. If it runs in shell and uses printfs for debug, it's user-friendly enough for me smile

EDIT: I just noticed - that "if (BIT_I)" in LDRH/STRH is implied, as there is separate function handling register specified offset. Unless those are to be merged into one (not a bad idea BTW), I'd throw it away.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/10/08 10:15 PM

Well, unfortunately all the failures in our current cores are well buried. It is beginning to seriously annoy me that nearly every random kiddie GBA and NDS emulator has perfect v4T and v5TE emulation and we can only manage a subset though.
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/11/08 12:55 PM

I'm going to check few timer-related things today afternoon. When at it I could poke the hardware some more. I'd rather not waste time on unnecessary things though so I'd like to know:
- Is LPSLNK behaviour established? I mean, will it really lock the channel in ATTACK phase until LSA is reached?
- Where did that EGHOLD came from? First time I see this... AFAIK that bit is undefined and not used, but then again I do know a bit that's also not mentioned and yet rather important...
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/11/08 08:01 PM

LPSLNK looks good as it is. EGHOLD was nowhere to be found.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/11/08 08:17 PM

Might be something they dropped on the transition from the SCSP, although AICA is almost perfectly a superset of SCSP (except for FM mode) so that would be surprising (some of the darker corners of the SCSP were figured out using the AICA docs, which are much more verbose than the SCSP ones).

Any more insight on ADPCM loops? smile
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/11/08 09:25 PM

Well, one can emulate EGHOLD by specyfing infinite time in D1 transition (and possibly D2 if it might jump due to DL). In any case, setting this bit to 1 did not prevent A->D1/D2 phase change.
On a side note: infinite time for ATTACK is not as useless as it would seem. First, it still works with loop link bit. Second, it does not start at zero volume in that case smile SGC typically starts at 0x1ff, but in this case it stands still at 0x080. Why, thank you SEGA for pointing that out...

The way I handle ADPCM at loop jump now is as follows:
- type 2: decoder is reset to 0/127 (before the LSA sample is read)
- type 3: decoder keeps state, just the address changes.

Seems to work.

EDIT: 6 f**ing hours, not to mention all my previous attempts! I chopped both AO and my own code to pieces, even made a bastard DSF player using a memory dump supplied by AO. And all it took to fix Love Hina was "adres &= ~3;" in doubleword memory write function. Jeez. You'll excuse the noise as I'm going to bang my head against a wall for a while. Then I'll find me the guy who wrote ARM manual and shoot him. Repeatedly.
Posted By: Richard Bannister

Re: AO SDK release 1.3.2 available - 02/11/08 10:21 PM

Look at it on the bright side. You fixed it.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/11/08 11:57 PM

Yeah, some GBA games are quite fussy about the behavior of unaligned reads and writes, so AO inherited that fussiness.

I keep reading about how the ARM was intended to be the simplest of all RISC chips, sort of a RISC 6502. I call "fail" on that - MIPS and SH both are easier to work with at the assembly level, at least vs. ARM mode. Thumb mode behaves a fair amount like an SH-2 with funny mnemonics and is far less painful, so I do applaud that some of ARM's newer chips are Thumb only.
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/12/08 12:37 AM

I now sanitize memory writes in ARM core - I figure this is where it belongs. This allows for a few simple optimizations, like block transfers do the masking only once per run.
Well, with this outta my way I guess I'll try doing LFO now.

By the way, I've noticed that you do your own byte rotation in unaligned reads, so no need for RBOD macro anymore (or it will get rotated twice). And that search & replace on my memory access functions introduced some oddities into Data processing macros. Some opcodes still count cycles wrong. I'm not sure you're going to be using my core for much longer if MAME is getting ARM re-write, but if you do that source needs some serious cleaning now smile
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/12/08 09:54 AM

I got busy with LH and I forgot to mention that during ADPCM tests I've managed to dump a type 3 sample that has no additional bytes after LEA (unlike BIOS samples for example).
I guess that means if there is interpolation, it doesn't affect decoder state. I still encourage you to test that though.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/12/08 10:24 PM

BTW, for people who really want to get the jump on things, there's set of plugins (for Winamp 2, Winamp 5, and KBMediaPlayer I think) based on the WIP DSF code here. I don't think your ears will bleed on any of the released rips (the current code sounds *much* better than what we had when I made that statement), but you will encounter some things that don't sound right.

kingshriek: do you have any more progress on the AICA? I'm interested in trying DK's ADPCM research, but I also don't want to step on your toes.
Posted By: kingshriek

Re: AO SDK release 1.3.2 available - 02/13/08 04:45 AM

R. Belmont: I haven't done anything with the AICA since my last patch, so feel free to work on it.

I do have a (preliminary) Gunbird 2 rip, though, in case anyone is interested. I'm not sure if the rip is correct, however, since IMXL/ISEL/DISDL/DIPAN are constant (0/0/F/0) for all key-ons which would indicate the game's music is mono (can this actually be the case?). I went ahead and ripped all sequences (MSB) and one-shot banks (OSB). Interestingly, Highly Theoretical fails to play any of the OSB tracks, but AOSDK handles them just fine.

http://www.sendspace.com/file/evlrsa
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/13/08 05:01 AM

The arcade Gunbird 2 appears to be mono too, even though it's sequenced on a chip that's quite capable of good stereo (YMF278B, which is essentially the SCSP's father).
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/14/08 03:29 AM

Mmm, nice. Doing type 2 as DK suggests does improve things quite a bit. Gonna try and get interpolation going with ADPCM now.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/14/08 05:14 AM

New SDK:

http://rbelmont.mameworld.info/aosdk_140a5.zip

- Fixed ADPCM looping as per Deunan. Sakura Taisen 4 is distortion-free now, but ST3 still has some (possibly due to other causes?)
- I tried to get ADPCM interpolation going. And failed smirk
- Fixed some Skies of Arcadia songs from crashing - they were setting an active slot playing 16-bit samples' control register so that PCMS = 2, and thus adbase was NULL. Not sure exactly what real h/w would do here since neither KEYONEX or KEYONB are set in the new CTRL value.
- Ideas welcome on whatever we're still missing, notably the filter.
Posted By: kingshriek

Re: AO SDK release 1.3.2 available - 02/14/08 05:33 AM

Originally Posted By R. Belmont

- I tried to get ADPCM interpolation going. And failed smirk


Code:
diff -Nru aosdk_base/eng_dsf/aica.c aosdk/eng_dsf/aica.c
--- aosdk_base/eng_dsf/aica.c	2008-02-14 00:03:50.000000000 -0800
+++ aosdk/eng_dsf/aica.c	2008-02-13 21:30:06.000000000 -0800
@@ -1037,15 +1037,14 @@
 			slot->nxtbase = base;
 			slot->nxtstep = curstep;
 
-			s=(slot->cur_sample);
-	//		s=(int) slot->cur_sample*((1<<SHIFT)-fpart)+(int) slot->nxt_sample*fpart;
+			s=(int) slot->cur_sample*((1<<SHIFT)-fpart)+(int) slot->nxt_sample*fpart;
 		}
 		else
 		{
 			s = 0;
 		}
 
-		sample=s;
+		sample=s>>SHIFT;
 	}
 	
 	slot->prv_addr=slot->cur_addr;

Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/14/08 05:56 AM

And this is why I shouldn't work on code at midnight. Thanks, ks smile
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/14/08 01:01 PM

Hmm... so basically you keep two ADPCM states per channel, one for main sample and one for interpolation? Interesting.
There's a limit on pitch changes (vs sound's own) when it comes to ADPCM, but what happens if you're standing on LEA-1 and steps_to_go is greater than 1, say 2 for example? Won't it read LEA-1 (correct) and then LEA sample/garbage (that's past loop end now) and contaminate decoder state? This is a very rare case, but still...

I don't know what happens when you change sample type on active channel - I could try to test that. I'm kinda busy now, away from home/town much, so it will have to wait a bit on the TO-DO list.
My code will happily switch but ADPCM state will be undefined as it's preset on KEY ON. What AEG phase/level was that channel when the switch happened?

If there are any channels playing ADPCM wrong, try to catch what sample type it is (2/3) and what are LSA and LEA. I can't find good test cases where LSA > 0.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/14/08 02:05 PM

a5 with kingshriek's fix:

http://rbelmont.mameworld.info/aosdk_140a5a.zip

Sounds very nice. I could listen to Skies of Arcadia all day on it now :-)

BTW, KS, how are we doing vs. HE on the problems you were having with some of your rips?

PS: I'll post new AO builds with DSF support later today. Richard, if you want to get a head start, just use the eng_dsf from the aosdk.
Posted By: Richard Bannister

Re: AO SDK release 1.3.2 available - 02/14/08 07:22 PM

Hmmm... sounds a little screwy on my machine. Has this been de-endianed yet?
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/14/08 07:33 PM

The 16-bit samples may need to be de-endianed. I can't think of anywhere else that should be a problem though.
Posted By: Richard Bannister

Re: AO SDK release 1.3.2 available - 02/14/08 07:34 PM

Hmm, maybe it's just my ears picking holes in that particular rip. It's a recognisable tune, just a bit scratchy...
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/14/08 07:38 PM

What game and song?
Posted By: Richard Bannister

Re: AO SDK release 1.3.2 available - 02/14/08 07:39 PM

The one in the SDK. But i've just realised that I was using an expanded version of a2, not a5. Duh me.

FWIW, can you point me to a version of Sakura Taisen ready to go? The one on Kingshrieks page needs me to run a batch file/etc. I can compare that one directly.

(On an unrelated note, anything on Project Tempest?)
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/14/08 07:52 PM

Oh, yeah. a2 is scratchy, that's expected. a5a sounds *much* better :-)

ftp://ftp.modland.com/pub/modules/Dreamcast%20Sound%20Format/Kohei%20Tanaka/Sakura%20Taisen%204/ has the actual DSFs for sakutai4.

I need to find what I did with PT.
Posted By: Richard Bannister

Re: AO SDK release 1.3.2 available - 02/14/08 08:29 PM

Please. I'd like to give it a whirl...
Posted By: Richard Bannister

Re: AO SDK release 1.3.2 available - 02/14/08 08:34 PM

Okay, I can't get reproduce the quality on sakutai4-01 as in the MP3 on your site on either PPC or Intel. The lead instrument in the first section is very scratchy on both platforms. Is this expected?
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/14/08 08:46 PM

No, definitely not. It should sound like the MP3 only without the staticy part between the intro and the main theme and generally a bit higher quality all around. Do make sure the 16-bit samples are behaving though, those can add scratch if they're wrong-endian.
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/14/08 09:45 PM

I've just finished few more DC ARM tests. You already know this but to refresh your memory: ARM7 is pipelined CPU and this makes cycle counting somewhat complicated. It's especially difficult once R15/PC comes into play.

Usually instruction is fetch+decode, then execute. If execute doesn't involve any memory transfers, ARM does prefetch of next opcode and last cycle of instruction N and first of N+1 fold. So basically execution time of N+1 instruction depends on what N was... And of course if you modify PC things get even more interesting - beacuse prefetch queue has to be flushed.
This is also why some instructions add +8 to PC, and some +12 - it all depends on when exacly PC is being used, 2nd or 3rd cycle of the instruction in question.

I still have no idea why am I getting .5 differences, maybe the internal clock is 2x faster than memory access, but it all fits in more or less. Loads are longer than stores due to additional cycle for possible abort situation (in which case Rd has to rolled back). Also, in the light of what I just said, measuring execution times with long sequences of one opcode is probably not the best way to do it...

Anyway, B/BL are whooping 3 cycles. SUB PC,4 is only .5 cycle longer then SUB Rx,4 (where x != 15) though. Don't ask me why.
I'm also proud to announce I got it right and PC used in barrel shifter operations will be +8 if the shift is specified in opcode, or +12 if it's in Rs. What's more, PC can be base of the shift, and same rules apply as well. This is for Data processing, as manual says single load/store may not use PC in that way (but I wouldn't bet on it, maybe I'll even try to test that case too).

As for ADPCM - "ChuChu Rocket!" was suffering from the same bug that "Love Hina" was and now plays music so much better. It also has lots of type 2 samples with LSA != 0 and it seems reseting decoder to 0/127 works in those cases as well. Problem is, most of the time such reset doesn't produce noise if it's wrong, rather it makes the sound too quiet or click a bit. Hard to tell - seems right to me though.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/14/08 10:31 PM

With 2 more buttons ChuChu would've been a perfect GBA port, minus some audio quality. Also, if it has sequenced music clearly KS needs to rip it ;-)
Posted By: etabeta78

Re: AO SDK release 1.3.2 available - 02/14/08 10:44 PM

since you mentioned GBA, let me (very briefly) hijack your DSF discussions to ask: do the changes in MAME0.123u1 improve GBA as well? I'm really lazy tonight and I would not try to compile it if no goodies are to be expected wink

sorry for the intermission...
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/14/08 10:48 PM

The u1 ARM7 updates fix the graphics decompression in at least WarioWare (the original one), but it's not all that playable since it relies pretty heavily on the more advanced features of the graphics hardware.
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/15/08 01:49 PM

Excerpts from ARM manuals:

ARM7vC:
Register R15 holds the Program Counter (PC). When R15 is
read, bits [1:0] are zero and bits [31:2] contain the PC.

ARM7TDMI (rev r4p1):
Register r15 holds the PC.
In ARM state, bits [1:0] of r15 are undefined and must be ignored. Bits [31:2] contain the PC.
In Thumb state, bit [0] is undefined and must be ignored. Bits
[31:1] contain the PC.

Now I remember why was my code clearing lower 2 bits of PC on write - that was (never finished) attempt to move the masking from reads to writes.

Usually it's clearly stated that any unaligned doubleword address will still set A[1:0] lines and those "might be interpreted" by external memory controller. STR is an exception and all the docs say is: "A word store (STR) should generate a word aligned address. The word presented to the data bus is not affected if the address is not word aligned. That is, bit 31 of the register being stored always appears on data bus output 31." Nothing about lowest two address bits... SWP by the way is said to operate as LDR followed by STR - and I now assume that means any unaligned read will rotate and store will be masked to be aligned (on DC at least).

In short, all transfers except LDR are implementation specific (unaligned memory access can be masked, or happen as it is). I'm aiming for my core to be DC compatible but that in turn might break other systems. It's up to MAME devs what to do with their ARMs, I'd split the core code by CPU generation and memory access handlers by system.

Here's another interesting difference, about R14 when branch link bit is set:

ARM7vC:
Note that the CPSR is not saved with the PC.

ARM7TDMI (rev r4p1):
Note that the CPSR is not saved with the PC and R14[1:0] are always cleared.

Why is R14 being sanitized if the code is executing in 32-bit (non-Thumb) mode? PC should be aligned then. Or does it mean lower PC bits are not undefined but in fact valid, and in that case (sooner or later) someone is going to write a piece of code relying on that 'feature'.
Posted By: Richard Bannister

Re: AO SDK release 1.3.2 available - 02/15/08 01:50 PM

Originally Posted By R. Belmont
No, definitely not. It should sound like the MP3 only without the staticy part between the intro and the main theme and generally a bit higher quality all around. Do make sure the 16-bit samples are behaving though, those can add scratch if they're wrong-endian.


Aargh. Second dumb mistake in one evening. The compiler hadn't picked up all the changed files.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/15/08 02:56 PM

DK: there are GBA games that jump (deliberately as far as we can tell) to unaligned addresses in both ARM and Thumb modes and expect the CPU to magically save them.
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/15/08 06:45 PM

This is proper interrupt handling. It suddenly starts to make more sense once you do remember to set F/I flags where appropriate. Duh, I guess.

Code:
diff -Nru old/arm7.c new/arm7.c
--- old/arm7.c	2008-02-15 19:47:10.000000000 +0100
+++ new/arm7.c	2008-02-15 19:47:24.000000000 +0100
@@ -136,13 +136,10 @@
   // mode change could've enabled interrups, so we test for those and set
   // appropriate flag for the instruction loop to catch
   if (ARM7.fiq)
-    if (!(sr & ARM7_CPSR_F) && (ARM7_CPSR_M (sr) != ARM7_CPSR_M_fiq))
-      ARM7.flagi |= ARM7_FL_FIQ;
+    ARM7.flagi |= ARM7_FL_FIQ;
 #ifndef ARM7_DREAMCAST
   if (ARM7.irq)
-    if (!(sr & ARM7_CPSR_I) && (ARM7_CPSR_M (sr) != ARM7_CPSR_M_irq) &&\
- (ARM7_CPSR_M (sr) != ARM7_CPSR_M_fiq))
-      ARM7.flagi |= ARM7_FL_IRQ;
+    ARM7.flagi |= ARM7_FL_IRQ;
 #endif
   }
   //--------------------------------------------------------------------------
@@ -198,10 +195,10 @@
   // (FIQ can interrupt IRQ, but not the other way around)
   if (ARM7.fiq)
     {
-    if (!(sr & ARM7_CPSR_F) && (ARM7_CPSR_M (sr) != ARM7_CPSR_M_fiq))
+    if (!(sr & ARM7_CPSR_F))
       {
       // FIQ
-      ARM7_SetCPSR ((sr & 0xffffffc0) | ARM7_CPSR_M_fiq);
+      ARM7_SetCPSR (ARM7_CPSR_MX (sr, ARM7_CPSR_M_fiq) | ARM7_CPSR_F | ARM7_CPSR_I);
       ARM7.Rx [ARM7_SPSR] = sr;
       // set new PC (return from interrupt will subtract 4)
       ARM7.Rx [ARM7_LR] = ARM7.Rx [ARM7_PC] + 4;
@@ -211,11 +208,10 @@
 #ifndef ARM7_DREAMCAST
   if (ARM7.irq)
     {
-    if (!(sr & ARM7_CPSR_I) && (ARM7_CPSR_M (sr) != ARM7_CPSR_M_irq) &&\
- (ARM7_CPSR_M (sr) != ARM7_CPSR_M_irq))
+    if (!(sr & ARM7_CPSR_I))
       {
       // IRQ
-      ARM7_SetCPSR ((sr & 0xffffffc0) | ARM7_CPSR_M_irq);
+      ARM7_SetCPSR (ARM7_CPSR_MX (sr, ARM7_CPSR_M_irq) | ARM7_CPSR_I);
       ARM7.Rx [ARM7_SPSR] = sr;
       // set new PC (return from interrupt will subtract 4)
       ARM7.Rx [ARM7_LR] = ARM7.Rx [ARM7_PC] + 4;
diff -Nru old/arm7.h new/arm7.h
--- old/arm7.h	2008-02-15 19:27:49.000000000 +0100
+++ new/arm7.h	2008-02-15 19:27:49.000000000 +0100
@@ -42,7 +42,8 @@
 #define ARM7_CPSR_F (1 << 6)
 #define ARM7_CPSR_T (1 << 5)
   /** CPSR bit mask for current operating mode. */
-#define ARM7_CPSR_M(x) (x & 0x1f)
+#define ARM7_CPSR_M(x) ((x) & 0x1f)
+#define ARM7_CPSR_MX(sr,x) (((sr) & ~0x1f) | ((x) & 0x1f))
   /** Bit combinations for each operating mode. */
 #define ARM7_CPSR_M_usr 0x10
 #define ARM7_CPSR_M_fiq 0x11
diff -Nru old/arm7i.c new/arm7i.c
--- old/arm7i.c	2008-02-15 19:27:49.000000000 +0100
+++ new/arm7i.c	2008-02-15 19:27:49.000000000 +0100
@@ -1364,7 +1364,7 @@
     {
 //EMU_BLAD (BLAD_WEWNETRZNY, "BDT: user transfer");
     cpsr = ARM7.Rx [ARM7_CPSR];
-    ARM7_SetCPSR ((cpsr & 0xffffffe0) | ARM7_CPSR_M_usr);
+    ARM7_SetCPSR (ARM7_CPSR_MX (cpsr, ARM7_CPSR_M_usr));
     }
 
   if (ARM7.kod & BIT_L)
@@ -1551,8 +1551,12 @@
 	logerror("ARM7: G111 / Coprocessor data operation\n"); */
     }
   else
-   {
-  	ARM7_SetSWI();
-   }
+    {
+    uint32_t sr = ARM7.Rx [ARM7_CPSR];
+    ARM7_SetCPSR (ARM7_CPSR_MX (sr, ARM7_CPSR_M_svc) | ARM7_CPSR_I);
+    ARM7.Rx [ARM7_SPSR] = sr;
+    ARM7.Rx [ARM7_LR] = ARM7.Rx [ARM7_PC];
+    ARM7.Rx [ARM7_PC] = 0x00000008;
+    }
   }
   //--------------------------------------------------------------------------


I've also simplified group 0 decoder for non-Thumb cores, since it's only swap, multiply or data processing/PSR transfer in that case. I can create AO comptabile patch if anyone's interested.

EDIT: Oops, silly me. One change went into wrong file, corrected.
Posted By: Knurek

Re: AO SDK release 1.3.2 available - 02/15/08 07:29 PM

A friend of mine says that using the newest Winamp plugin (it's based on a5a) "most of the instruments sound too short". Noticable in just about every Skies of Arcadia track, especially SOA_369_04_01.minidsf
Disregard this post if this is known (maybe it's just the missing DSP reverb stuff).
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/15/08 07:36 PM

Thanks. MAME just got that right recently too. I didn't realize SWI actually locked out hardware interrupts but it does make some sense. I'll take the decoder patch too.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/15/08 07:37 PM

Knurek: compared to real hardware or to HE? And the DSP reverb is working fine.
Posted By: Knurek

Re: AO SDK release 1.3.2 available - 02/15/08 07:45 PM

I've been told that compared to the OST and playing the GC conversion. I can whip up some comparison samples if you want.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/15/08 08:37 PM

Not necessary. I have the real game and a real Dreamcast. (Amusingly I can't try Makaron because I only have real GDROMs).
Posted By: nZero

Re: AO SDK release 1.3.2 available - 02/15/08 08:52 PM

Do any DC emulators boot full GD-ROM images? I keep hoping emulation will push the scene away from hacked-up selfbooting CD-R sized rips. Hell, I'd get a BBA and rip my collection if I thought I could use the resulting disc images for anything.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/15/08 09:13 PM

Apparently nullDC can boot full GD-ROM images in the same format Guru's ripping the Naomi discs to. But yeah, emulation needs to get away from the self-booting rips. TOSEC needs to burn their whole "collection" to the ground and start over properly.
Posted By: Knurek

Re: AO SDK release 1.3.2 available - 02/15/08 09:27 PM

Uhh, Makaron *can* boot GDRom dumps.
Stuff with *.gdi, *.raw and *.bin files.
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/15/08 10:04 PM

Yup, Makaron sure can boot GD images. CDI are supported only because homebrew needs to boot as well (though any new stuff could be easily fashioned into GDI as well).
I kinda wonder - who is it exactly that came up with that format?

I've a problem here. I ported some more changes from my ARM core to AO and it stopped playing anything at all. It seems that there are lots of unaligned memory reads by LDR - and those get rotated. There's a bug in AO though, the rotation is done twice: first my RBOD macro and then arm7_read_32 does it's own. Since all of those addresses have bit 1 set, it ends up rotated 2x16=32 bit, that is nothig changes. But it only works like that due to this incorrect double rotation...?

I hardly ever see unaligned reads in Makaron, if any at all. This is why I had #ifdef on that macro int the first place, I was planning on skipping that check later. Is it possible that it's caused by the libraries that are loaded?

EDIT: And maybe it's just me, but I do belive AO plays tunes slightly bit faster then Makaron...
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/15/08 10:14 PM

Unaligned reads probably vary by which version of MANATEE.DRV is loaded. I don't know what game(s) use the 2.50 that's common for DSF rips so we can't get an exact comparison.

Also, maybe the AICA's memory controller just masks the LSBs instead of doing the rotation like the TDMI?
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/15/08 10:25 PM

Well, the rotation is supposed to be ARM thing, so unless AICA memory controller does exactly the opposite...
I've just watched GB2 intro, music (gunbird2_19.minidsf) plays fine in Makaron and no address is ever unaligned. Yet on AO I get tons of these...

Disregard that statement about AO being too fast. I've just compared it's GB2 output to wave taken from Dreamcast and it's a match. It's Makaron that is slowing down a bit - I guess running SH4 in the same thread does take it's toll.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/15/08 10:35 PM

Right, but the real Gunbird 2 game may not use the same sound driver program as the DSF rip[1]. That would presumably affect if unaligned access occured or not. Try this: boot GB2, dump AICA RAM once it starts playing, and check for the driver version string near the top of RAM. Or alternatively, have AOSDK dump a RAM image, load that into Makaron, and see if unaligned accesses occur.

[1] Most DSF rips use version 2.50 because it's known where to patch that version so it doesn't clear the SH4 command buffer before reading it, and it's assumed the sequence data remained compatible. In order to be more accurate games should probably be ripped with the real driver they shipped with, but in practice that hasn't turned out to make much difference (Neill Corlett's Skies of Arcadia test DSF using the game's driver does seem to sound subtly different from KS's full rip using 2.50 but I could be hallucinating ;-)
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/15/08 10:45 PM

"1998,(C)SEGA ENTERPRISES 1999.05.25:DIGITALMEDIA :Y.Kashima / K.Suyama" is all I got text-wise.
It is different than Love Hina for example, which has "1999,(C)SEGA ENTERPRISES 1999.06.16:DigitalMedia :Y.Kashima / K.Suyama"
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/15/08 10:48 PM

Yeah, the really old versions don't seem to include an actual version number, just the date. Still, that's sufficient to prove it's not the same driver the DSF rip is using.
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/15/08 11:01 PM

It might be something I messed up. I don't get it... Freshly unpacked and compiled AO doesn't to that. Stand down from alert, I need to test it some more and depending on outcome bang my head some more or kick the compiler.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/15/08 11:21 PM

LOL :-)
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/16/08 01:21 AM

Long story short: my bad. Both AO and Makaron will produce misaligned reads, it's just I take advantage of Intel CPUs being able to read any memory location for any data size. That means the LSB is always correct, whether you read as-is or align and rotate - and this is what counts for ARM programs. And RBOD will not rotate twice, because it masks address bits before it calls arm7_read_32, so the IF in there is always false.

The problem was, I was trying to be smart and since arm7_read_32 does rotation I thought I could kick RBOD out. Bad move. There was a bug in arm7_read_32, it was rotating all right but was not masking the adddress for the read... Didn't notice it at all.

Anyway, RBOD is back and stays, arm7_read_32 is fixed just in case. Everything seems to work again. I'll send you new sources via mail because the diff would be bigger then the file itself. Keep a copy though, somehow I no longer feel so confident about this stuff smile
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/16/08 01:40 AM

Yeah, working with ARM emulation gives me that feeling too smile Thanks!
Posted By: etabeta78

Re: AO SDK release 1.3.2 available - 02/16/08 01:40 AM

oh well, at least having two independent source code bases allowed to compare all this stuff and to improve both where needed... it's a win-win situation (even if sometimes a bit frustrating when you keep rewriting small bits and testing tons of instruction on the CPU...)
Posted By: kingshriek

Re: AO SDK release 1.3.2 available - 02/16/08 07:07 AM

Originally Posted By R. Belmont
Right, but the real Gunbird 2 game may not use the same sound driver program as the DSF rip[1]. That would presumably affect if unaligned access occured or not. Try this: boot GB2, dump AICA RAM once it starts playing, and check for the driver version string near the top of RAM. Or alternatively, have AOSDK dump a RAM image, load that into Makaron, and see if unaligned accesses occur.

[1] Most DSF rips use version 2.50 because it's known where to patch that version so it doesn't clear the SH4 command buffer before reading it, and it's assumed the sequence data remained compatible. In order to be more accurate games should probably be ripped with the real driver they shipped with, but in practice that hasn't turned out to make much difference (Neill Corlett's Skies of Arcadia test DSF using the game's driver does seem to sound subtly different from KS's full rip using 2.50 but I could be hallucinating ;-)


I can confirm that the Gunbird 2 rip uses the same sound driver as the game. The sound formats it uses are actually incompatible with the ver. 2.50 driver.

Byte 4 in the 0x20-byte music data headers is an indicator of the sound data format, so there shouldn't be any major incompatibility issues using a different driver version as long as this value is same. The driver checks this value with what it expects and will reject loading sound data if it is different. Other than Gunbird 2, all of the Dreamcast games I've seen have a value of 2 for this byte (Gunbird 2 has value 1).

I've disassembled enough of the manatee driver so that I know how to modify the patches so that they work with different versions. I'll try Skies of Arcadia using the original driver and see if that helps things. The Skies of Arcadia driver is named bonito.drv, so there may be a significant enough difference from manatee.drv 2.50 even though they have the same sound format indicator.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/16/08 09:53 AM

Yeah, it turns out there was no behavior difference after all between AO and Makaron with Gunbird anyway, so it was all a false alarm on that front. Kinda weird that the DC driver changed that much given how relatively similar all the Saturn SDDRVS.TSK versions were.

And I still could be hallucinating re: SoA smile
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/16/08 02:59 PM

Sakura Wars for Dreamcast has some sequenced music too. I've just ripped the files from bonus GD and will send them to KS in a moment. This should be interesting, as it was originally Saturn game but got remade for DC. I assume the music was converted too and wonder what the difference would be.

The MANATEE is 2000.03.03 ver.2.02.05.00.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/17/08 10:00 PM

I got MAME's ARM core to write correct DISDL/DIPAN values now - unaligned 32-bit reads weren't masking the low bits before issuing the read to do the rotation on, and manatee.drv relies on it. (On the GBA side, that gets Ashita No Joe to boot and play instead of crashing).
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/18/08 12:03 AM

So it's the same one that creeped into arm7_read_32? smile
I tested that SUB PC,4 again and found out I got the opcode wrong. In the end this instruction takes 3 cycles just as any jump would. Also, barrel shifter should add .5 to any instruction using register count.

Code:
diff -Nru old/arm7i.c new/arm7i.c
--- old/arm7i.c	2008-02-18 00:47:09.000000000 +0100
+++ new/arm7i.c	2008-02-18 00:48:03.000000000 +0100
@@ -335,6 +335,7 @@
 
   if (ARM7.kod & (1 << 4))
     {
+    s_cykle++;
     // shift count in Rs (8 lowest bits)
     if (Rm != ARM7_PC)
       w = ARM7.Rx [Rm];
@@ -890,7 +891,7 @@
     {
     if (Rd == ARM7_PC)
       {
-      s_cykle++;
+      s_cykle += 4;
       // copy current SPSR to CPSR
       ARM7_SetCPSR (ARM7.Rx [ARM7_SPSR]);
       }


This needs to be patched against the source I've sent via mail. I think there were some Polish leftovers in that code, but just a line or two. I had double definitions and it didn't throw an error on compile. Let me just remind you that ARM7_Execute now needs to be fed with twice the number of cycles you want to run. This is to allow for all those .5 differences.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/18/08 12:56 AM

Yeah smile New interesting thing - I put the AICA into MAME and the Naomi BIOS sound test is generating weird values - it's keying on a sample with OCT=0 FNS=0 for the left speaker test, which obviously makes no noise. That's *got* to be an ARM7 bug I would think. The Naomi boot logo plays the appropriate sounds though :-)
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/18/08 01:28 AM

Wha... I think it's valid? Both values on zero mean there's no difference to AICA 44100Hz clock. In other words, use 44100 as sample rate?
Now that you mention it... that AICA_Step sure looks odd. I'm going to sleep now, I'll look into it tommorow after work.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/18/08 03:55 AM

Yeah, I was actually wrong about that. The voice with OCT 0 FNS 0 does play fine.

Here's an interesting pickle for DSF: Mame Italia just sent in a dump of the Naomi game "Toy Fighter", and while the game itself doesn't run yet in MAME, the game's test menu does, including the sound test. After adjusting the AICA to address samples throughout 8 MB of RAM instead of 2 the tunes sound pretty good. So I'm willing to tweek the spec so there's 8 MB of RAM instead of 2. Highly Experimental won't like it, but I suspect Naomi may be a richer source of sequenced music than the DC anyway.
Posted By: kingshriek

Re: AO SDK release 1.3.2 available - 02/18/08 07:27 AM

I've uploaded Sakura Taisen 1 & 2 DSF rips to my page along with a current version of dsfmake.

Does Toy Fighter use the Manatee driver or something else?

Virtua Fighter 3TB uses a non-manatee driver, and I haven't figured out how it works yet. Here's a pack of the driver w/ 2 sound files: http://h1.ripway.com/kingshriek/vf3tb.zip

It appears that 0x60-0x80 is used for SH4/ARM communication and that sound files are mapped at address 0x10000 from a look at the driver code.
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/18/08 10:12 AM

Originally Posted By R. Belmont
I suspect Naomi may be a richer source of sequenced music than the DC

I wouldn't count on it. The way I understand it Naomi has more memory only because it's unable to stream directly from GD-ROM. There's much less content on those GDs compared to DC ones.

Of course that could also mean the now missing movies and streams were replaced by sequenced music to fill the gap smile

kingshriek, there's another tough case I'd like you to take a look at. Soul Reaver has two sound drivers, one called MANATEE2 and one AUDIO64 (looks like MANATEE clone to me). No MLT files of any sort but when you throw out the movies, dialogues pack, graphics pack and binaries, there's still one big file left. Music has to be inside...
I may need to set up an FTP for that one though, as it would clobber your mail box otherwise. I'll let you know once it's ready.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/18/08 01:56 PM

http://rbelmont.mameworld.info/toyfighter.zip has an AICA RAM image while the song in the mp3 I posted is playing.

The driver IDs as "AM2/AICASoundDrv990421/Ver1.60" and "Sequencer 1.27 99/03/16 Y.Takeda" (ETA: which is basically the same driver as VF3TB). From a quick glance it looks like it's something of a midway point between the Saturn driver and Manatee, but that could be wrong. There are several blocks throughout RAM with the signature "DTPK" but none of the normal SMSB/SMPB manatee stuff.

Soul Reaver famously used interactive music, and thus I would presume it's going to be painful to rip (early attempts at various developed-by-Rare N64 games with interactive music usually resulted in all the possible tracks playing at once, which was not real listenable ;-)
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/18/08 02:32 PM

New SDK: http://rbelmont.mameworld.info/aosdk_140a6.zip

- Cleaned up a few AICA bits (removed EGHOLD even though the bit where it would be is actually reserved ;-)
- Latest ARM7 improvements from Deunan
- Support for 8 MB of AICA RAM just in case (none of the existing rips seem to mind being in the larger RAM, fortunately)

Assuming Sakura Taisen 1 is supposed to sound like the Saturn SSF rip the DSP/dry mixing seems possibly a bit off (sakutai_11 is the same song on both rips and makes a handy comparison).
Posted By: Knurek

Re: AO SDK release 1.3.2 available - 02/18/08 04:01 PM

Originally Posted By R. Belmont
Soul Reaver famously used interactive music, and thus I would presume it's going to be painful to rip (early attempts at various developed-by-Rare N64 games with interactive music usually resulted in all the possible tracks playing at once, which was not real listenable ;-)


Unreal (the PC one, not the old Amiga game) had dynamic music as well (exploration/battle IIRC). All that amounted was some jump to pattern commands and a Scream/Impulse tracker module with two or three songs.

Skies of Arcadia has supposedly some dynamic music as well (boss battle tracks?), and I think kingshriek rip has all the music variations as a separate minidsf files, so hopefully Soul Reaver will be the same.

Some more aoDSF/HT comparisons here: [url=www.snesmusic.org/hoot/log.txt]www.snesmusic.org/hoot/log.txt[/url]
Might be a bit longwinded, but there's some good info there. This is all based on a5, BTW.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/18/08 04:16 PM

There are various interviews with Soul Reaver's composer (Kurt Harland) floating around where he claims their system was a lot more complex than simple channel mutes. Certainly nobody's successfully ripped the PS1 version yet and I would think that'd be a chip shot by comparison.
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/18/08 04:19 PM

If memory serves me right SR had the ability to switch tunes without stopping the music as whole. Some instruments would simply expire and new ones would replace them. This wasn't always the case, but still... It's easy to reproduce in the very first tunnel once the intro sequence is over - the music changes as Raziel approaches the first teleport platform. I remember it well because due to a bug in my SH4 there was a time the game would freeze at this very moment.

As for the instruments being too short - I might have an idea. I'll get back to you soon smile
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/18/08 04:22 PM

That log has all but put me off of further development of this code. I assume from the overall hostility to all things not Corlett that it's that "marioman" from HCS's forum?
Posted By: Knurek

Re: AO SDK release 1.3.2 available - 02/18/08 04:41 PM

Uh, what hostility? Not seeing anything there, really.

"[21:46] <M> It's quite likely that it sounds like I'm complaining. That is by no means my intention."

Dunno, maybe I misunderstand, but the guy was generally pleased to have the AODSF plugin (as in something that's being actively worked on and may get rid of all the emulation bugs HT has). And AODSF started way better than AOSSF once did, that's for sure.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/18/08 04:44 PM

It's hard to read people over the Internet, and his choice of phrasing just reads as excessively critical to me. Could be just a non-native speaker though.

DK: I find it interesting that the log apparently pegs the start of "too short instruments" to fixing the SDLT table.
Posted By: Knurek

Re: AO SDK release 1.3.2 available - 02/18/08 05:24 PM

You know, people generally don't waste few hours of their life on bugreports just to piss you off. :P
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/18/08 05:46 PM

Really? Because I wonder about motivation when he's playing the 10th track in a row where he complains that the notes are "too short". I think it's fair to say most people would have stopped by then and just reported something. (In this case that's not even necessary since you'd already relayed that belief here in a less off-putting manner).
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/18/08 07:23 PM

Anyway, I've got my US Dreamcast hooked up and running. 300-02 is unfortunately masked to an extent in-game by the engine sounds, but from what I heard it's very very similar to what aosdk is playing (certainly no missing/short/cutoff notes). I'll check more later.
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/18/08 07:35 PM

Do you have coder's cable (or BBA)? I could (and I will - on weekend most likely) whip up a small application to load AO memory image into AICA. This way I will have 3 players, AO, DKDSF (Makaron based) and Dreamcast smile

BTW, I just cleaned up my DKDSF (and found yet another bug in my AICA) and now it's more standalone. Just one EXE + dcram.bin and it will play - Win32 only of course. If anyone wants to see how badly it sounds, I can share smile No DSP, FEG, PLFO or resonance filter though.
It uses (obviously) same ARM core as AO but my AICA is a bit different. For one, AO with debug output on channel K-ON shows it starts with channel 0x2f or so. DKDSF starts with channel zero...
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/18/08 08:09 PM

I don't, but that would be cool so we can figure out if perhaps some anomoly of the ripping process itself is causing problems. And having more players is *always* good smile I don't really see how the AICA influences what voice number is keyed on first though.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/18/08 08:25 PM

BTW, something smf pointed out: there's a cartridge Naomi version of Samba de Amigo, which implies sequenced music. Has anyone checked the Dreamcast version? smile
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/18/08 08:51 PM

I've no idea why AO starts at channel 0x2F or so and my code at zero. It's just my guess it has to do with AICA, since ARM core is the same and we use exactly the same memory image. Feel free to look for the cause, I've given up. smile

Unfortunately I don't have "Samba de Amigo", so I won't help you with that. I'd love to probe that unique controller though - you'd be suprised to what lengths some games go to ensure you are using original SEGA issue stuff...
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/19/08 01:46 AM

Alright. 350-03, that's the smoking gun...
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/19/08 03:48 AM

A7: http://rbelmont.mameworld.info/aosdk_140a7.zip

ADPCM samples no longer click and go silent when they hit the loop start. I'm slightly disappointed nobody realized this just from the code, but this does greatly help the sound so I'm just happy it's fixed.

Dear Mysterious Plugin Guy: please make new plugins based on this version as soon as possible. Thanks!
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/19/08 10:27 AM

I see you reset (or rather, recall precomputed LSA value) for both ADPCM types now? Well, your call. I'm pretty sure you're going to be reverting those changes once you get more acquainted with type 3 in MESS *evil grin*.

I'm going to test few more type 2 with non-zero LSA later, so far simple reset always worked for me. Now that I have several DSF players I have some reference source.
Posted By: marioman

Re: AO SDK release 1.3.2 available - 02/19/08 10:37 AM

Quote:
That log has all but put me off of further development of this code. I assume from the overall hostility to all things not Corlett that it's that "marioman" from HCS's forum?

Hi R. Belmont,

I thought that I would just stop by and and say that the person in the above discussion log is not me. I am not sure where you get the idea that I am hostile to any non-Corlett plugins, but that is not the case. I am actually one of the biggest supporters of your plugins. Take a look around this thread and you can see that I regularly keep an eye out for updates to aossf and aodsf.

Anyways, I am looking forward to getting my hands on the new version of aodsf. Keep up the good work.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/19/08 01:45 PM

DK: we'll see smile I got the Dreamcast BIOS farther in MESS. It issues a GDROM command, sits a while, fiddles with the interrupt enables, and then does nothing (well, actually it's running a lot of code, it just doesn't seem to go anywhere). soa-350-03 is *the* test for type 2 looping with nonzero LSA (it's actually still not exactly right in my code, but at least it's much closer).

marioman: my apologies if that wasn't you. You were the only person I knew of saying anything about the plugin and it seemed like a similar writing style.
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/19/08 02:12 PM

I assume you didn't get BIOS to play the opening swirl sound, because you'd notice it's not OK on that ADPCM processing smile
Anyway, my bet is you're not issuing interrupts. You should get away without GD, but Maple has to be there. Not to mention VSYNC and related IRQ events: HBLANK_IN (doesn't have to be accurate except few cases), VBLANK_IN and VBLANK_OUT. There's a register that keeps track of current scanline - VPOS. That one has to be properly maintained, especially around zero wrap.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/19/08 02:28 PM

Ahh, yeah, that makes sense. I forgot, this is Sega, you need HBlank in/out to go anywhere smile
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/20/08 04:27 AM

Tonight's improvement: http://rbelmont.mameworld.info/aosdk_140a8.zip

This fixes the random volume spikes that sometimes happened when looping type 2 ADPCM samples, and it also avoids resetting the sampler state for Type 3 (which is intended for streaming anyway).
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/20/08 10:30 AM

My code plays that SoA tune in a bit different way. On loop re-entry the sound gets very quiet, but near the end it's again at full strength. This however produces pulsating modulation and is not correct either.
It's time to see why my previous attempt at saving and restoring ADPCM state has failed...
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/20/08 01:20 PM

Yeah, that's not right - it's supposed to just loop at full strength. This is why that particular song is so valuable for loop tuning :-)
Posted By: kingshriek

Re: AO SDK release 1.3.2 available - 02/24/08 04:48 AM

Here are some more DSFs, covering Segagaga, Rune Jade, Super Robot Taisen Alpha --> http://www.sendspace.com/file/v1emz7 (thanks to Knurek for supplying much of this sound data)

Segagaga is quite interesting as it appears to be highly sensitive to AICA slot monitor reads. It breaks apart quite badly w/ the current AOSDK. I've attempted to address as much of this as I could in the following patch:

Code:
diff -Nru aosdk_base/eng_dsf/aica.c aosdk/eng_dsf/aica.c
--- aosdk_base/eng_dsf/aica.c	2008-02-19 23:19:46.000000000 -0800
+++ aosdk/eng_dsf/aica.c	2008-02-20 20:38:16.000000000 -0800
@@ -130,6 +130,7 @@
 	int curstep, nxtstep;
 	int cur_lpquant, cur_lpsample, cur_lpstep;
 	UINT8 *adbase, *nxtbase, *adlpbase;
+	UINT8 mslc;			// monitored?
 };
 
 
@@ -144,6 +145,9 @@
 #define MIFULL(aica)		((aica->udata.data[4]>>0x0)&0x0200)
 #define MIEMPTY(aica)		((aica->udata.data[4]>>0x0)&0x0100)
 
+#define AFSEL(aica)		((aica->udata.data[6]>>0x0)&0x4000)
+#define MSLC(aica)		((aica->udata.data[6]>>0x8)&0x3F)
+
 #define SCILV0(aica)    	((aica->udata.data[0xa8/2]>>0x0)&0xff)
 #define SCILV1(aica)    	((aica->udata.data[0xac/2]>>0x0)&0xff)
 #define SCILV2(aica)    	((aica->udata.data[0xb0/2]>>0x0)&0xff)
@@ -593,6 +597,7 @@
 		AICA->Slots[i].active=0;
 		AICA->Slots[i].base=NULL;
 		AICA->Slots[i].EG.state=RELEASE;
+		AICA->Slots[i].mslc=0;
 	}
 
 	AICALFO_Init();
@@ -625,6 +630,7 @@
 					{
 						if(KEYONB(s2) && s2->EG.state==RELEASE/*&& !s2->active*/)
 						{
+							if(s2->mslc) AICA->udata.data[0x10] &= 0x7FFF; // reset LP at KEY_ON
 							AICA_StartSlot(AICA, s2);
 							#if 0
 							printf("StartSlot[%02X]:   SSCTL %01X SA %06X LSA %04X LEA %04X PCMS %01X LPCTL %01X\n",sl,SSCTL(s2),SA(s2),LSA(s2),LEA(s2),PCMS(s2),LPCTL(s2));
@@ -687,13 +693,13 @@
 		case 0x9:
 			AICA_MidiIn(0, AICA->udata.data[0x8/2]&0xff, 0);
 			break;
-/*		case 0x12:
+		case 0x12:
 		case 0x13:
 		case 0x14:
 		case 0x15:
 		case 0x16:
 		case 0x17:
-			break;*/
+			break;
 		case 0x90:
 		case 0x91:
 			if(AICA->Master)
@@ -786,12 +792,10 @@
 		case 0x10:	// LP check
 		case 0x11:
 			{
-				int MSLC = (AICA->udata.data[0xc/2]>>8) & 0x3f;	// which slot are we monitoring?
-
-//				AICA->udata.data[0x10/2] |= 0x8000;	// set LP if necessary
+				//int MSLC = (AICA->udata.data[0xc/2]>>8) & 0x3f;	// which slot are we monitoring?
 			}
 			break;
-
+			
 		case 0x14:	// CA (slot address)
 		case 0x15:
 			{
@@ -885,6 +889,7 @@
 		{
 			AICA_UpdateRegR(AICA, addr&0xff);
 			v= *((unsigned short *) (AICA->udata.datab+((addr&0xff))));
+			if((addr&0xfe)==0x10) AICA->udata.data[0x10/2] &= 0x7FFF;	// reset LP on read
 		}
 		else if (addr == 0x2d00)
 		{
@@ -1075,12 +1080,14 @@
 			if(*addr[addr_select]>=LSA(slot) && *addr[addr_select]>=LEA(slot))
 			{
 			//slot->active=0;
+			if(slot->mslc) AICA->udata.data[8] |= 0x8000;
 			AICA_StopSlot(slot,0);
 			}
 			break;
 		case 1: //normal loop
 			if(*addr[addr_select]>=LEA(slot))
 			{
+				if(slot->mslc) AICA->udata.data[8] |= 0x8000;
 				rem_addr = *slot_addr[addr_select] - (LEA(slot)<<SHIFT);
 				*slot_addr[addr_select]=(LSA(slot)<<SHIFT) + rem_addr;
 
@@ -1122,6 +1129,16 @@
 		sample=(sample*EG_Update(slot))>>SHIFT;
 	else
 		sample=(sample*EG_TABLE[EG_Update(slot)>>(SHIFT-10)])>>SHIFT;
+		
+	if(slot->mslc) 
+	{
+		AICA->udata.data[0x12/2] = addr1;
+		if (!(AFSEL(AICA)))
+		{
+			AICA->udata.data[0x10/2] |= slot->EG.state<<13;
+			AICA->udata.data[0x10/2] |= 0x3FF - (slot->EG.volume>>EG_SHIFT);
+		}
+	}
 
 	return sample;
 }
@@ -1143,10 +1160,11 @@
 		// mix slots' direct output
 		for(sl=0;sl<64;++sl)
 		{
+			struct _SLOT *slot=AICA->Slots+sl;
+			slot->mslc = (MSLC(AICA)==sl);
 			RBUFDST=AICA->RINGBUF+AICA->BUFPTR;
 			if(AICA->Slots[sl].active)
 			{
-				struct _SLOT *slot=AICA->Slots+sl;
 				unsigned int Enc;
 				signed int sample;
 


Still not perfect, but perhaps the absence of the filter envelope may be somewhat responsible since filter envelopes can be monitored too.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/24/08 05:21 AM

Could be. The envelope part of the filter envelope isn't hard (it's quite similar to the existing *EGs) but I have no idea how to apply the results to the sound.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 02/24/08 05:58 AM

For reference, in the VF3TB/Toy Fighter driver here's what the SH4 writes after downloading it and booting the ARM7.

First the init:

(keep in mind everything's little endian, so e.g. writing 001100a0 means a0 00 11 00 in memory (command a0, parameter 1=11, parameter2=12).

Code:
200 to 50
ffffffff to 60
ffffffff to 64
ffffffff to 68
ffffffff to 6c
ffffffff to 70
ffffffff to 74
ffffffff to 78
ffffffff to 7c
0 to 60
18a0 to 400
4b505444 to 10000
0 to 10004
1 to b0
0 to b0
1 to 64
18a0 to 404
1 to b0
0 to b0
e to 68
18a0 to 408
1 to b0
0 to b0
26 to 78
18a0 to 40c
1 to b0
0 to b0


And here's how it starts 1 song:
Code:
001100a0 to 410
011100a0 to 414
021100a0 to 418
071100a0 to 41c
061100a0 to 420
031100a0 to 424
2a to 7c
18a0 to 428
1 to b0
0 to b0
ba8 to 42c


and the second song:
Code:
001100a0 to 430
011100a0 to 434
021100a0 to 438
071100a0 to 43c
061100a0 to 440
031100a0 to 444
ffffffff to 7c
18a0 to 448
1 to b0
0 to b0
2b to 7c
18a0 to 44c
1 to b0
0 to b0
ea8 to 450


Based on this I'd gather that 0xa0 is some sort of all-purpose setup and 0xa8 actually plays the sequence.
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/24/08 11:57 AM

Wow, SGGG_1KEN_00_00 does sound much better on my AICA. I guess it's not all that bad smile

There are some old SWI remains in ARM core, not used anymore so it's safe to remove them. If noone feels like it then I'll submit a patch later today - I gotta get some fresh air now (after spending last 24hrs or so in front of my PC)

kingshriek, expect more game files coming your way in very near future. Possibly MUCH more smile
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 02/24/08 08:29 PM

Here's the cleanup. Nothing really important, but it does remove a variable from ARM state structure so make sure to properly recompile all ARM core sources.

Code:
diff -Nru old/arm7.c new/arm7.c
--- old/arm7.c	2008-02-24 21:25:19.000000000 +0100
+++ new/arm7.c	2008-02-24 21:25:26.000000000 +0100
@@ -51,7 +51,6 @@
   // sane startup values
   ARM7.fiq = 0;
   ARM7.irq = 0;
-  ARM7.swi = 0;
   ARM7.carry = 0;
   ARM7.overflow = 0;
   ARM7.flagi = FALSE;
@@ -175,14 +174,6 @@
   //--------------------------------------------------------------------------
 
   //--------------------------------------------------------------------------
-  /** Sets SWI state. */
-void ARM7_SetSWI (void)
-  {
-    ARM7.swi = 1;
-  }
-  //--------------------------------------------------------------------------
-
-  //--------------------------------------------------------------------------
   /** Tests for pending interrupts, switches to one if possible. */
 void ARM7_CheckIRQ ()
   {
@@ -219,19 +210,6 @@
       ARM7.irq = 0;
       }
     }
-
-  if (ARM7.swi)
-    {
-	ARM7_SetCPSR ((sr & 0xffffffc0) | ARM7_CPSR_M_svc);
-	ARM7.Rx [ARM7_SPSR] = sr;
-
-	if  (sr & ARM7_CPSR_T)
-		ARM7.Rx [ARM7_LR] = ARM7.Rx [ARM7_PC] + 2;
-	else
-		ARM7.Rx [ARM7_LR] = ARM7.Rx [ARM7_PC] + 4;
-	ARM7.Rx [ARM7_PC] = 0x00000008;
-	ARM7.swi = 0;
-    }
 #endif
   }
   //--------------------------------------------------------------------------
diff -Nru old/arm7.h new/arm7.h
--- old/arm7.h	2008-02-24 21:25:19.000000000 +0100
+++ new/arm7.h	2008-02-24 21:25:26.000000000 +0100
@@ -101,7 +101,7 @@
   ARM7_REG Rx_bank [6][10];
 
   /** FIQ and IRQ interrupt requests. */
-  int fiq, irq, swi;
+  int fiq, irq;
 
   /** Carry flag for barrel shifter and ALU operations. */
   int carry;
@@ -141,8 +141,6 @@
 void ARM7_SetFIQ (int stan);
   /** Sets IRQ line state. */
 void ARM7_SetIRQ (int stan);
-  /** Sets SWI state. */
-void ARM7_SetSWI (void);
 
   /** Tests for pending interrupts, switches to one if possible. */
 void ARM7_CheckIRQ (void);


Last minute update: DCDSF is now operational. Hooked to my PC via SCART -> Line-in.
If anyone wants a tune hardware-checked, drop me a note smile
Posted By: marioman

Re: AO SDK release 1.3.2 available - 03/07/08 02:23 AM

How about SOA_303_02_00.minidsf from the Skies of Arcadia rip? (I believe that it is the Sky Pirate Base Theme.) Thanks in advance.
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 03/07/08 11:13 AM

With Audacity help I can produce WAV or MP3 - problem is I can't figure out how to configure it for VBR as opposed to 128kbps CBR...
Anyway, I'll get to it once I'm back home. Where do I upload results? Will rapidshare do?
Posted By: marioman

Re: AO SDK release 1.3.2 available - 03/07/08 01:11 PM

Sure. Thanks.
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 03/07/08 06:10 PM

Done: http://rapidshare.com/files/97782885/soa-303-02-00.mp3.html
Rather than use the built-in function (with only CBR settings available) I run Lame myself with "-q 0 --strictly-enforce-ISO -t --vbr-new -V 0". In other words, it's as good as it gets for MPEG layer 3 smile
Posted By: marioman

Re: AO SDK release 1.3.2 available - 03/07/08 09:27 PM

Thanks. So it sounds like the DSF set is good, and that it is just the AO support that needs some work.

It seems that the only issue to be corrected in this particular track is the wind sound in the background. The AO output interprets the sound as a sort of cymbal and plays it many times too loud.

Other than that, it sounds great. Thanks for recording the track. I hope that you figure out what the problem is soon.
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 03/07/08 10:58 PM

Yeah, AO sometimes keys on wrong instruments. Happens on srtalpha_MB_EVA_6 too, just before the music goes more lively.
I've checked it agains DKDSF and DC - it doesn't happen there so the AICA ram image is good.

And by the way - where exactly did DSP program word field assignment came from? I've nothing on it (and yet I have my doubts on several things in aicadsp.c).
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 03/07/08 11:36 PM

In sound artist terms, wind = cymbal (white noise) + filter. That was one of the last things to be solved emulating the SNES SPC-700.

The DSP details are all in the big AICA document. We actually used the AICA documentation to work out the SCSP's DSP (which is now reference-quality).
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 03/07/08 11:58 PM

EVA_6 sound is more like pair of maracas if you ask me, but I had to apply KS last patch manually and I might have borked it.

As for "big AICA document" - any chance I could get my hands on it?
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 03/08/08 12:08 AM

I think this is the right one:

http://rbelmont.mameworld.info/aica.zip
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 03/08/08 01:11 AM

Okay, I suppose my definition of "big" isn't that broad.
BTW I can easily point several places in this doc where it's just plain wrong about things. I assumed whoever wrote original DSP code had access to something a bit more descriptive.

I'll cut to the point - this still doesn't say where exactly in 64-bit DSP word are fields like XSEL, YSEL, etc. And the reason I'm asking is I don't trust the decoding done in current AICA implementation. Example (and based on this doc too): MASA is defined as bits [5:0] (just not where exactly) and aicadsp.c does this first "UINT32 MASA=(IPtr[6]>>9)&0x1f;" and then "ADDR=DSP->MADRS[MASA<<1];" later. That's [4:0] shifted to [5:1].

Sure you don't really get anything out of helping me create DSP support for Makaron, but at least you'd know I didn't just steal your code smile
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 03/08/08 01:15 AM

Well, the DSP output sounds correct. There are other issues with the AICA, but the DSP is generating reverb pretty much as expected. KS did the opcode encoding changes, probably from a magical document that Neill Corlett wrote (ElSemi quoted bits of it to me once but wasn't allowed to share).
Posted By: kingshriek

Re: AO SDK release 1.3.2 available - 03/08/08 01:30 AM

The <<1 shifts are there because the AICA's COEF and MADRS are mapped to 32-bit aligned memory addresses.

For the DSP field definitions I did use the magical Neill document found here ---> http://www.neillcorlett.com/etc/myaica.txt
Posted By: Deunan Knute

Re: AO SDK release 1.3.2 available - 03/08/08 01:34 AM

Well, I've figured as much. DSP is going to stay on my TO-DO list for quite a while then. Never hurts to ask though smile

EDIT: But then again, this one I didn't have. Must sleep now but will read tomorrow smile
As for the shift - there are 64 MADRS entries so the index is still one bit short?
Posted By: kingshriek

Re: AO SDK release 1.3.2 available - 03/08/08 01:39 AM

Originally Posted By Deunan Knute
Example (and based on this doc too): MASA is defined as bits [5:0] (just not where exactly) and aicadsp.c does this first "UINT32 MASA=(IPtr[6]>>9)&0x1f;" and then "ADDR=DSP->MADRS[MASA<<1];" later. That's [4:0] shifted to [5:1].


I'm glad you pointed this out, though, since this is an error. MASA should be:

- UINT32 MASA=(IPtr[6]>>9)&0x1f;
+ UINT32 MASA=(IPtr[6]>>9)&0x3f;

The AICA has 64 MADRS as opposed to the SCSP's 32.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 03/08/08 02:56 AM

Nice.
Posted By: R. Belmont

Re: AO SDK release 1.3.2 available - 03/08/08 03:15 AM

This is the sound in question in soa-303-02-00:

Code:
StartSlot[01]:   SSCTL 0 SA 0CB0A6 LSA 49E6 LEA A575 PCMS 0 LPCTL 1
                 AR 0A D1R 00 D2R 00 RR 0E DL 00 KRS 0 LPSLNK 0
                 TL 2A OCT F FNS 320
                 LFORE 0 LFOF 00 ALFOWS 0 ALFOS 0 PLFOWS 0 PLFOS 0
                 IMXL D ISEL 0 DISDL F DIPAN 00

StartSlot[02]:   SSCTL 0 SA 0CB0A6 LSA 49E6 LEA A575 PCMS 0 LPCTL 1
                 AR 0A D1R 00 D2R 00 RR 0E DL 00 KRS 0 LPSLNK 0
                 TL 25 OCT 0 FNS 156
                 LFORE 0 LFOF 00 ALFOWS 0 ALFOS 0 PLFOWS 0 PLFOS 0
                 IMXL D ISEL 0 DISDL F DIPAN 00
Posted By: R. Belmont

Re: AO SDK release 1.4.0 available - 03/08/08 03:29 AM

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

Re: AO SDK release 1.4.0 available - 03/08/08 11:24 AM

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.
Posted By: R. Belmont

Re: AO SDK release 1.4.0 available - 03/08/08 12:24 PM

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

Re: AO SDK release 1.4.0 available - 03/08/08 01:26 PM

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

Re: AO SDK release 1.4.0 available - 03/08/08 02:40 PM

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

Re: AO SDK release 1.4.0 available - 03/09/08 09:01 PM

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?
Posted By: R. Belmont

Re: AO SDK release 1.4.0 available - 03/13/08 04:18 PM

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
Posted By: kingshriek

Re: AO SDK release 1.4.0 available - 03/14/08 04:29 AM

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

Re: AO SDK release 1.4.0 available - 03/14/08 06:10 PM

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

Re: AO SDK release 1.4.0 available - 03/15/08 01:41 AM

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.
Posted By: etabeta78

Re: AO SDK release 1.4.0 available - 03/15/08 02:21 AM

Originally Posted By Deunan Knute
Um... silly question: Why can't I edit/update my previous post now?


because you can do that only for around 6 hours. after that the post becomes definitive and you have to reply to yourself smile

p.s. thanks for the work on makaron smile
Posted By: R. Belmont

Re: AO SDK release 1.4.0 available - 03/15/08 05:22 AM

Yeah. Of course, mods can change your posts to say "what what in the butt" at any time.
Posted By: Deunan Knute

Re: AO SDK release 1.4.0 available - 03/15/08 10:56 PM

I'm having some trouble getting DSP input levels right. Problem is the sample values in MIXS are well in range but DSP ends up heavily clipping the output anyway...
Seems like AO has this too, try listening to soa-367-04-00 with DSP output only and you should hear it hiss and die within seconds.

kingshriek, as I understand AO uses parts of MANATEE to play DSFs? Would it be possible to create some sort of patcher that would go over dumped RAM image and hack ARM program to mask DISDL writes to zero?
I'd like to test that soa-367-04-00 (and few other tunes as well) on Dreamcast, but with DSP output only. This way I could confirm if it's supposed to be that way or is it our DSP bug.
Posted By: R. Belmont

Re: AO SDK release 1.4.0 available - 03/15/08 11:38 PM

Might work to have the SH4 just constantly read all the slots' DISDL registers and zap them.
Posted By: kingshriek

Re: AO SDK release 1.4.0 available - 03/15/08 11:45 PM

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


I'm not sure what is the correct way to handle this nor am I aware of any documentation that addresses this issue. I did look through a quick sampling of various ssfs and didn't see any meaningful DSP instructions where IWT==IRA.

Originally Posted By Deunan Knute
kingshriek, as I understand AO uses parts of MANATEE to play DSFs? Would it be possible to create some sort of patcher that would go over dumped RAM image and hack ARM program to mask DISDL writes to zero?


Try replacing the following two consecutive instructions:

Code:
- E1811400 ORR	r1, r1, r0, LSL #8
- E5881024 STR	r1, [r8, #36]
  
+ E3A01000 MOV	r1, #0
+ E5881024 STR	r1, [r8, #36]


Instruction locations will vary based on the version of manatee.drv used but I would expect them to occur consecutively in most versions.
Posted By: Deunan Knute

Re: AO SDK release 1.4.0 available - 03/16/08 10:58 AM

Hacking RAM image works as intended - and that is the only good news I bring. Dreamcast DSP output is stable, so it must be a bug.

This is what I get - upper track is Dreamcast DSP, lower is my player. I've ommitted AO because it's pretty much the same (there's slight variance on the time line but that's my code still lagging a tiny bit).

http://pics.livejournal.com/dknute/pic/000ba6dw

EDIT: And one more, perhaps important thing. This wave comes mostly from ADPCP type 2 looped sample. If the decoder adds an offset and the output shifts too much away from zero it could be the source of the problem. I'll need to test it some more though. Do note that the very beginnig of the sample seems to be OK, and the moment it goes wrong (dives down) is, if I'm not mistaken, loop jump.
Posted By: Deunan Knute

Re: AO SDK release 1.4.0 available - 03/16/08 11:28 AM

Yet one more update. Seems like soa-367-04-00 program never sets NEGB to 1. If you do that (like, change "if (NEGB)" to "if (!NEGB)" the echo is gone but the output comes out clean. That gave me an idea, try this:

Code:
		v=(((INT64) X*(INT64) Y)>>12);
+		v = (v * 1000) >> 10;
		ACC=(int) v+B;


Much better I'd say. Good for a quick patch but I still need to find the source.
Posted By: Deunan Knute

Re: AO SDK release 1.4.0 available - 03/17/08 09:18 AM

I'm giving up for the moment. I was never that good with signal processing anyway smile Some loose thoughts:
- as I understand it the accumulator multiplication is X (24b sample value) times Y (.12b signed fixed point)
- for the SOA tune it helps to scale Y down a bit (taken from COEF table)
- that still doesn't help all that much, and some other files still play wrong (like first Sakura Wars 4 one)
- if you scale down MIXS input, the sound will still be clipped and hiss, but won't die completly (wave looking wrong though, so it's not really about input level)

I've tried several modifications, like saturating v, v+B (note, those never get out of 26 bit range anyway). It doesn't seem to be memory read/write problem either - tested on separate table to store full ints rather then packed ones.

That particular SOA program is rather simple, all it does is take MIXS, read some memory, write some, use COEF only, writes output. No fancy addressing or latching registers. It does use MEMS and TEMP though. If you zero whole TEMP range on DSP step entry it behaves a bit like if you lowered MIXS level - sounds better but wave still going up and down and has clipped areas.
Based on this I'd say it's either ACC that is computed wrong or TEMP addressing is incorrect. I've tried many things on both, no results (like getting TEMP address just a bit wrong and you loose one or both sound channels). Perhaps there is a way to control MDEC_CT value?

I'll test few more silly ideas of mine but I don't expect any positive changes. If anyone wants to give it a try, be my guest. At this point I'm not touching DSP anymore unless something comes to me...
Posted By: R. Belmont

Re: AO SDK release 1.4.0 available - 04/01/08 02:27 AM

A bit of the funny: since we locked in the basically perfect SCSP in MAME and AO, Yabause and SSF have both had releases where the primary feature was debugging the SCSP. I'm making no accusations and the code's free and open to look at anyway, but it does make me laugh.
Posted By: R. Belmont

Re: AO SDK release 1.4.0 available - 04/23/08 03:52 AM

There's some complaints about the crash cymbal in Shining the Holy Ark (the SSF rip). In sha-03.minissf it looks like this:

StartSlot: SA 557f6 PCM8B 0 LPCTL 1 ALFOS 0 STWINH 0 TL 35 EFSDL 0
AR 1f D1R 0 D2R b RR 14 DL 0 KRS 0 EGHOLD 0 LPSLNK 0

I agree it sounds unnatural, but not enough that I wouldn't say it's potentially just poorly made. kingshriek, any ideas? If I understand the envelope correctly (and I'm not saying I do) it seems like correct behavior (it keys on full strength and stays there on a very short loop until it's explicitly keyed off).
Posted By: kingshriek

Re: AO SDK release 1.4.0 available - 04/23/08 04:56 AM

Hmm, this is the only reasonable fix that I can come up with:

Code:
diff -Nru aosdk_base/eng_ssf/scsp.c aosdk/eng_ssf/scsp.c
--- aosdk_base/eng_ssf/scsp.c	2008-01-29 16:28:48.000000000 -0800
+++ aosdk/eng_ssf/scsp.c	2008-04-22 21:36:00.000000000 -0700
@@ -357,7 +357,7 @@
 			slot->EG.volume-=slot->EG.D1R;
 			if(slot->EG.volume<=0)
 				slot->EG.volume=0;
-			if(slot->EG.volume>>(EG_SHIFT+5)<slot->EG.DL)
+			if(slot->EG.volume>>(EG_SHIFT+5)<=slot->EG.DL)
 				slot->EG.state=DECAY2;
 			break;
 		case DECAY2:


This will push the crash cymbal sample immediately into the DECAY2 state, bypassing the troublesome zero-valued DECAY1.

Additionally, I've just discovered that using a different driver version fixes the problematic Shining the Holy Ark tracks (e.g. sha-07.minissf) where the SCSP-slot assignment gets derailed. I'm at a complete loss as to why the game's original driver is doing this in the rip.

You can get the "fixed" copy here for now:

http://h1.ripway.com/kingshriek/Shining_the_Holy_Ark.7z
Posted By: Deunan Knute

Re: AO SDK release 1.4.0 available - 04/23/08 09:21 AM

It's rather difficult to compare my AEG code to what AO uses (many fundamental differences in timing and channel flag handling) but here's what I'm doing:

Code:
if (kanal.AEG.poziom < 0)
  {
  // przejscie do Decay 1 / Decay 2
  kanal.AEG.poziom = 0;
  if (kanal.AEG.poziom >= D2AEGP)
    FazaAEG (kanal, AEG_DECAY2);
  else
    FazaAEG (kanal, AEG_DECAY1);
  }


This is for the case when the current phase is ATTACK. As you see, I'm switching directly to Decay 2 if DL (I call it D2AEGP) permits it.
AFAIR this is what I observed on hardware. The switch to Release however will need at least one more sample, there is no direct route even if both Decay values are set to immediate.

As for slot assigments - sometime ago I belive I mentioned that AO seems to start playing with channel numbers in 0x2F range (rather then zero, like my player). Haven't really tested it since and it was alpha stage back then...
I still say you handle the key-on/off thing wrong (as in: hardware does it different way) and that could be the problem with the driver. This shouldn't have such effect though, I'd be rather expecting "ghost" (repeats) or incompletly defined sounds to appear - since you allow the channel to be keyed on in situations where it should not be possible.
But then again this doesn't seem to be happening so far, I guess nobody is trying to pull such dirty tricks on AICA smile

EDIT: Seems like the board doesn't like non-latin letters much. Fixed. And some nasty typos too.
Posted By: R. Belmont

Re: AO SDK release 1.4.0 available - 04/23/08 12:56 PM

Ahh, it sounds much nicer with the patch smile
Posted By: R. Belmont

Re: AO SDK release 1.4.1 available - 04/24/08 02:46 AM

SDK is updated with that patch.
Posted By: R. Belmont

Re: AO SDK release 1.4.1 available - 04/24/08 05:52 AM

DK: the exact same voices with the exact same parameters are keyed on between our cores, it's just they're on different slots. (And I've not seen such an effect with the SCSP). Probably they use timer ticks to seed the slot allocation or something.
Posted By: Deunan Knute

Re: AO SDK release 1.4.1 available - 04/24/08 01:18 PM

This was just a wild guess. I'm simply pointing out things, since I'm too lazy to investigate myself smile
Posted By: R. Belmont

Re: AO SDK release 1.4.1 available - 04/26/08 11:26 PM

smile

That's ok, meanwhile I've realized I should apply that envelope change to the AICA too.
Posted By: ajax16384

Re: AO SDK release 1.4.1 available - 07/14/08 03:52 PM

some piece of "eng_dsf" code need clarification:
1)
if(slot->mslc)
{
AICA->udata.data[0x12/2] = addr1; // 2812 has no description. only 2814 contains monitored channel position (CA). so what's the purpose of 0x2812 ?
if (!(AFSEL(AICA)))
{
AICA->udata.data[0x10/2] |= slot->EG.state<<13;
AICA->udata.data[0x10/2] |= 0x3FF - (slot->EG.volume>>EG_SHIFT);
}
}

2)where is no "voff" checking (channelOffset + 0x28 bit 6 - according to great Neill Corlett's notes).

3)aosdk 1.4.1 handles 0x2892 & 0x2894 address for TimerB & TimerC instead of 0x2894 & 0x2898.
Posted By: Deunan Knute

Re: AO SDK release 1.4.1 available - 07/14/08 04:59 PM

1) Probably a bug. CA is used mostly for ADPCM streams, so this has little impact on AO I guess.
2) & 3) - those are never used anyway smile

Posted By: R. Belmont

Re: AO SDK release 1.4.1 available - 07/14/08 05:04 PM

I was gonna say, the fact that something uses timers B/C is bigger news than our mishandling of them wink I'll fix it anyway though.
Posted By: Deunan Knute

Re: AO SDK release 1.4.1 available - 07/18/08 11:23 AM

Going back to that DSP issue - now, after a few more hours of tests, I'm pretty much convinced this isn't about DSP but rather ADPCM.
See, the DSP works just fine with 8- and 16-bit samples being input:
- it works for Saturn tunes
- it breaks only certain Dreamcast tunes
- hissing/clipping only occurs when ADPCM samples are being routed through DSP

All DSP does (in short) is take the input wave, modify it a bit and add it back time-shifted. However if the output saturates and stays like that it will distort or even mute all sounds during final mixing pass. Non-ADPCM samples eventually integrate to zero, so the adder never overflows. But ADPCM samples seem to have a bias and tend to dive into negative numbers and stay there (loop jumps recover a bit, but not completly). And it's exactly what upsets the DSP - you can test that by inverting the sign of ADPCM samples being written to MIXS. It will create exactly the same output wave but mirrored around time axis. Reducing ADPCM dynamic range (from -/+ 32768 to let's say 24000) helps, but you can still see the output swinging rather then being symmetric.

I'm trying to figure out what's wrong with the decoder and why does it introduce the bias, but not much luck so far. Maybe I'm missing something obvious?
kingshriek, if you have some time could you please look into that as well? All you need to do is extract some raw ADPCM data and convert it to WAV, then view it under some sound editor like Audacity. You should see the problem right away. You can use soa-367-04-00.minidsf as it starts with ADPCM and exibits the symptoms.
I can provide you with longer streams if you want - dialog lines from Soul Reaver. It's very obvious on those:
http://pics.livejournal.com/dknute/pic/000eky4b

EDIT:
Well, I haven't found this to be a problem in a while... anyway - shifting is the culprit. -1 >> 3 is still -1, whereas -1 / 8 is zero. It's consistent with the fact that the bias is towards negative values. I'll see if +1 trick will work and test it further and get back to you smile
Posted By: Deunan Knute

Re: AO SDK release 1.4.1 available - 07/18/08 04:43 PM

Bingo. Update aica.c with this modified decoder and all DSP problems will go away smile

Code:
signed short inline DecodeADPCM(int *PrevSignal, unsigned char Delta, int *PrevQuant)
{
	int x = *PrevQuant * quant_mul [Delta & 15];
        x = *PrevSignal + ((int)(x + ((UINT32)x >> 29)) >> 3);
	*PrevSignal=ICLIP16(x);
	*PrevQuant=(*PrevQuant*TableQuant[Delta&7])>>ADPCMSHIFT;
	*PrevQuant=(*PrevQuant<0x7f)?0x7f:((*PrevQuant>0x6000)?0x6000:*PrevQuant);
	return *PrevSignal;
}


Posted By: R. Belmont

Re: AO SDK release 1.4.1 available - 07/19/08 03:57 AM

Nice smile
Posted By: Kaminari

Re: AO SDK release 1.4.1 available - 07/19/08 02:00 PM

Great! in_aodsf updated.

http://foobar2000.xrea.jp/up/
Posted By: R. Belmont

Re: AO SDK release 1.4.1 available - 07/19/08 03:48 PM

Now there's a cart-ahead-of-the-horse moment wink
Posted By: Deunan Knute

Re: AO SDK release 1.4.1 available - 07/26/08 09:32 PM

You know what's funny? Since this ADPCM decoder originates in Yamaha YMZ280B driver I peeked into MAME sources today, being sure it has the same bug. And it doesn't, Aaron Giles coded it with "/8" and not ">>3" smile
Don't you just love rediscovering the wheel again...
Posted By: R. Belmont

Re: AO SDK release 1.4.1 available - 07/27/08 02:30 AM

Premature optimization, all evil, etc.

Plus on Northwood-core Pentium 4s the /8 is faster than the >>3 :-)
Posted By: ajax16384

Re: AO SDK release 1.4.1 available - 07/27/08 07:03 PM

Interpolation algorithm uses neighbor sample - so we can optimize
ADPCM channel process to use last decoded values. We can rid of "nxt*" variables and second adpcm decode cycles (will speed up ADPCM a little bit). Following diff against aosdk 1.4.1 shows my assumption.

Code:
diff -Nru aosdk_base/eng_dsf/aica.c aosdk/eng_dsf/aica.c
--- aosdk_base/eng_dsf/aica.c	2008-03-07 21:21:32.000000000 +0300
+++ aosdk/eng_dsf/aica.c	2008-07-27 23:05:18.596041500 +0400
@@ -125,12 +125,10 @@
 	struct _LFO ALFO;		//Amplitude LFO
 	int slot;
 	int cur_sample;       //current ADPCM sample
-	int nxt_sample;       //next ADPCM sample
 	int cur_quant;        //current ADPCM step
-	int nxt_quant;        //next ADPCM step
-	int curstep, nxtstep;
+	int curstep;
 	int cur_lpquant, cur_lpsample, cur_lpstep;
-	UINT8 *adbase, *nxtbase, *adlpbase;
+	UINT8 *adbase, *adlpbase;
 	UINT8 mslc;			// monitored?
 };
 
@@ -431,10 +429,9 @@
 		UINT8 *base;
 		UINT32 curstep, steps_to_go;
 
-		slot->curstep = slot->nxtstep = 0;
-		slot->adbase = slot->nxtbase = (unsigned char *) (AICA->AICARAM+((SA(slot))&0x7fffff));
+		slot->curstep = 0;
+		slot->adbase = (unsigned char *) (AICA->AICARAM+((SA(slot))&0x7fffff));
 		InitADPCM(&(slot->cur_sample), &(slot->cur_quant));
-		InitADPCM(&(slot->nxt_sample), &(slot->nxt_quant));
 		InitADPCM(&(slot->cur_lpsample), &(slot->cur_lpquant));
 
 		// walk to the ADPCM state at LSA
@@ -956,7 +953,6 @@
 	UINT32 addr1,addr2,addr_select;                                   // current and next sample addresses
 	UINT32 *addr[2]      = {&addr1, &addr2};                          // used for linear interpolation
 	UINT32 *slot_addr[2] = {&(slot->cur_addr), &(slot->nxt_addr)};    //
-	int    *adpcm_sample[2] = {&(slot->cur_sample), &(slot->nxt_sample)};
 
 	if(SSCTL(slot)!=0)	//no FM or noise yet
 		return 0;
@@ -1007,12 +1003,16 @@
 		UINT8 *p1=(unsigned char *) (AICA->AICARAM+((SA(slot)+(addr1>>1))&0x7fffff));
 		UINT8 *p2=(unsigned char *) (AICA->AICARAM+((SA(slot)+(addr2>>1))&0x7fffff));
 		INT32 s;
+		int cur_sample;       //current ADPCM sample
+		int nxt_sample;       //next ADPCM sample
 		INT32 fpart=slot->cur_addr&((1<<SHIFT)-1);
-		UINT32 steps_to_go = addr1, curstep = slot->curstep;
+		UINT32 steps_to_go = addr2, curstep = slot->curstep;
 
 		if (slot->adbase)
 		{
-			// seek to the current sample
+			cur_sample = slot->cur_sample; // may already contains current decoded sample 
+
+			// seek to the interpolation sample
 			while (curstep < steps_to_go)
 			{
 				int shift1, delta1;
@@ -1024,33 +1024,15 @@
 				{
 					base++;
 				}
+				if (curstep == addr1)
+					cur_sample = slot->cur_sample;
 			}
+			nxt_sample = slot->cur_sample;
 
 			slot->adbase = base;
 			slot->curstep = curstep;
 
-			base = slot->nxtbase;
-			curstep = slot->nxtstep;
-			steps_to_go = addr2;
-
-			// seek to the interpolation sample
-			while (curstep < steps_to_go)
-			{
-				int shift1, delta1;
-				shift1 = 4*((curstep&1));
-				delta1 = (*base>>shift1)&0xf;
-				DecodeADPCM(&(slot->nxt_sample),delta1,&(slot->nxt_quant));
-				curstep++;
-				if (!(curstep & 1))
-				{
-					base++;
-				}
-			}
-
-			slot->nxtbase = base;
-			slot->nxtstep = curstep;
-
-			s=(int) slot->cur_sample*((1<<SHIFT)-fpart)+(int) slot->nxt_sample*fpart;
+			s=(int)cur_sample*((1<<SHIFT)-fpart)+(int)nxt_sample*fpart;
 		}
 		else
 		{
@@ -1093,7 +1075,7 @@
 				rem_addr = *slot_addr[addr_select] - (LEA(slot)<<SHIFT);
 				*slot_addr[addr_select]=(LSA(slot)<<SHIFT) + rem_addr;
 
-				if(PCMS(slot)>=2 && addr_select==0)
+				if(PCMS(slot)>=2)
 				{
 					// restore the state @ LSA - the sampler will naturally walk to (LSA + remainder)
 					slot->adbase = &AICA->AICARAM[SA(slot)+(LSA(slot)/2)];
@@ -1106,16 +1088,6 @@
 
 //					printf("Looping: slot_addr %x LSA %x LEA %x step %x base %x\n", *slot_addr[addr_select]>>SHIFT, LSA(slot), LEA(slot), slot->curstep, slot->adbase);
 				}
-				else if(PCMS(slot)>=2 && addr_select==1)
-				{
-					slot->nxtbase = &AICA->AICARAM[SA(slot)+(LSA(slot)/2)];
-					slot->nxtstep = LSA(slot);
-					if (PCMS(slot) == 2)
-					{
-						slot->nxt_sample = slot->cur_lpsample;
-						slot->nxt_quant = slot->cur_lpquant;
-					}
-				}
 			}
 			break;
 		}


Posted By: R. Belmont

Re: AO SDK release 1.4.1 available - 07/28/08 04:57 AM

DK: Just got back to my computer after a ton of vacation (had a laptop but no source to test out). The sound quality improvement from that change is amazing and the samples no longer "float" with a DC offset :-)

Ajax: Thanks. I don't see much real-world CPU improvement but the code cleanup is well worth it.
Posted By: R. Belmont

Re: AO SDK release 1.4.2 available - 07/28/08 06:06 AM

An updated SDK has been posted. Thanks everyone.
Posted By: Deunan Knute

Re: AO SDK release 1.4.2 available - 07/28/08 10:54 AM

And nowdays conditional jumps (if predictable enough) are faster than CMOVs on x86. Makes you wonder why Intel introduced those in the first place... Then again, I just found a use for BSR instruction, and nothing beats that idea of theirs to remove hardware shifters from P4 smile

Quite frankly I never much liked how AO handles ADPCM decoding (a bit too complicated for my taste) but at least it seemed to work. Are you sure this change will not break the long stream type on loop jumps? It gets a bit tricky if you're doing interpolation and only keep the last computed sample value...
Posted By: R. Belmont

Re: AO SDK release 1.4.2 available - 07/28/08 12:06 PM

Well, the streaming samples in Naomi Toy Fighter seem to be broken with or without the cleanup patch, so I'm assuming it's not harmful for the moment :-) (Fixing the slot monitor address made them closer to working though).
Posted By: ajax16384

Re: AO SDK release 1.4.2 available - 07/28/08 02:54 PM

loop jumps should work without a problems. current sample takes value from previous interpolation pair calculation or calculates from scratch through decoding of current interpolation pair.
i played several .dsf by modified aosdk - and did not find any difference.

to complete code cleanup i decided to remove addr_select and *addr arrays at all. following diff against 1.4.2 based on the fact that we can check only next sample address for exceeding the LSA or LEA bounds.
Code:
diff -Nru aosdk_base/eng_dsf/aica.c aosdk/eng_dsf/aica.c
--- aosdk_base/eng_dsf/aica.c	2008-07-28 01:39:46.000000000 +0400
+++ aosdk/eng_dsf/aica.c	2008-07-28 18:39:47.804063500 +0400
@@ -125,12 +125,10 @@
 	struct _LFO ALFO;		//Amplitude LFO
 	int slot;
 	int cur_sample;       //current ADPCM sample
-	int nxt_sample;       //next ADPCM sample
 	int cur_quant;        //current ADPCM step
-	int nxt_quant;        //next ADPCM step
-	int curstep, nxtstep;
+	int curstep;
 	int cur_lpquant, cur_lpsample, cur_lpstep;
-	UINT8 *adbase, *nxtbase, *adlpbase;
+	UINT8 *adbase, *adlpbase;
 	UINT8 mslc;			// monitored?
 };
 
@@ -431,10 +429,9 @@
 		UINT8 *base;
 		UINT32 curstep, steps_to_go;
 
-		slot->curstep = slot->nxtstep = 0;
-		slot->adbase = slot->nxtbase = (unsigned char *) (AICA->AICARAM+((SA(slot))&0x7fffff));
+		slot->curstep = 0;
+		slot->adbase = (unsigned char *) (AICA->AICARAM+((SA(slot))&0x7fffff));
 		InitADPCM(&(slot->cur_sample), &(slot->cur_quant));
-		InitADPCM(&(slot->nxt_sample), &(slot->nxt_quant));
 		InitADPCM(&(slot->cur_lpsample), &(slot->cur_lpquant));
 
 		// walk to the ADPCM state at LSA
@@ -951,12 +948,11 @@
 
 INLINE INT32 AICA_UpdateSlot(struct _AICA *AICA, struct _SLOT *slot)
 {
-	INT32 sample;
+	INT32 sample, fpart;
+	int cur_sample;       //current sample
+	int nxt_sample;       //next sample
 	int step=slot->step;
-	UINT32 addr1,addr2,addr_select;                                   // current and next sample addresses
-	UINT32 *addr[2]      = {&addr1, &addr2};                          // used for linear interpolation
-	UINT32 *slot_addr[2] = {&(slot->cur_addr), &(slot->nxt_addr)};    //
-	int    *adpcm_sample[2] = {&(slot->cur_sample), &(slot->nxt_sample)};
+	UINT32 addr1,addr2;                                   // current and next sample addresses
 
 	if(SSCTL(slot)!=0)	//no FM or noise yet
 		return 0;
@@ -967,12 +963,7 @@
 		step>>=SHIFT;
 	}
 
-	if(PCMS(slot) == 1)
-	{
-		addr1=slot->cur_addr>>SHIFT;
-		addr2=slot->nxt_addr>>SHIFT;
-	}
-	else if(PCMS(slot) == 0) 
+	if(PCMS(slot) == 0) 
 	{
 		addr1=(slot->cur_addr>>(SHIFT-1))&0x7ffffe;
 		addr2=(slot->nxt_addr>>(SHIFT-1))&0x7ffffe;
@@ -987,32 +978,26 @@
 	{
 		INT8 *p1=(signed char *) (AICA->AICARAM+(((SA(slot)+addr1))&0x7fffff));
 		INT8 *p2=(signed char *) (AICA->AICARAM+(((SA(slot)+addr2))&0x7fffff));
-		INT32 s;
-		INT32 fpart=slot->cur_addr&((1<<SHIFT)-1);
-		s=(int) (p1[0]<<8)*((1<<SHIFT)-fpart)+(int) (p2[0]<<8)*fpart;
-		sample=(s>>SHIFT);
+		cur_sample = p1[0] << 8;
+		nxt_sample = p2[0] << 8;
 	}
 	else if (PCMS(slot) == 0)	//16 bit signed
 	{
 		INT16 *p1=(signed short *) (AICA->AICARAM+((SA(slot)+addr1)&0x7fffff));
 		INT16 *p2=(signed short *) (AICA->AICARAM+((SA(slot)+addr2)&0x7fffff));
-		INT32 s;
-		INT32 fpart=slot->cur_addr&((1<<SHIFT)-1);
-		s=(int) LE16(p1[0])*((1<<SHIFT)-fpart)+(int) LE16(p2[0])*fpart;
-		sample=(s>>SHIFT);
+		cur_sample = LE16(p1[0]);
+		nxt_sample = LE16(p2[0]);
 	}
 	else	// 4-bit ADPCM
 	{
 		UINT8 *base= slot->adbase;
-		UINT8 *p1=(unsigned char *) (AICA->AICARAM+((SA(slot)+(addr1>>1))&0x7fffff));
-		UINT8 *p2=(unsigned char *) (AICA->AICARAM+((SA(slot)+(addr2>>1))&0x7fffff));
-		INT32 s;
-		INT32 fpart=slot->cur_addr&((1<<SHIFT)-1);
-		UINT32 steps_to_go = addr1, curstep = slot->curstep;
+		UINT32 steps_to_go = addr2, curstep = slot->curstep;
 
-		if (slot->adbase)
+		if (base)
 		{
-			// seek to the current sample
+			cur_sample = slot->cur_sample; // may already contains current decoded sample 
+
+			// seek to the interpolation sample
 			while (curstep < steps_to_go)
 			{
 				int shift1, delta1;
@@ -1024,42 +1009,23 @@
 				{
 					base++;
 				}
+				if (curstep == addr1)
+					cur_sample = slot->cur_sample;
 			}
+			nxt_sample = slot->cur_sample;
 
 			slot->adbase = base;
 			slot->curstep = curstep;
-
-			base = slot->nxtbase;
-			curstep = slot->nxtstep;
-			steps_to_go = addr2;
-
-			// seek to the interpolation sample
-			while (curstep < steps_to_go)
-			{
-				int shift1, delta1;
-				shift1 = 4*((curstep&1));
-				delta1 = (*base>>shift1)&0xf;
-				DecodeADPCM(&(slot->nxt_sample),delta1,&(slot->nxt_quant));
-				curstep++;
-				if (!(curstep & 1))
-				{
-					base++;
-				}
-			}
-
-			slot->nxtbase = base;
-			slot->nxtstep = curstep;
-
-			s=(int) slot->cur_sample*((1<<SHIFT)-fpart)+(int) slot->nxt_sample*fpart;
 		}
 		else
 		{
-			s = 0;
+			cur_sample = nxt_sample = 0;
 		}
-
-		sample=(s>>SHIFT);
 	}
-	
+	fpart = slot->cur_addr & ((1<<SHIFT)-1);
+	sample=cur_sample*((1<<SHIFT)-fpart)+nxt_sample*fpart;
+	sample>>=SHIFT;	
+
 	slot->prv_addr=slot->cur_addr;
 	slot->cur_addr+=step;
 	slot->nxt_addr=slot->cur_addr+(1<<SHIFT);
@@ -1073,52 +1039,43 @@
 			slot->EG.state = DECAY1;
 	}
 
-	for (addr_select=0; addr_select<2; addr_select++)
+	switch(LPCTL(slot))
 	{
-		INT32 rem_addr;
-		switch(LPCTL(slot))
+	case 0:	//no loop
+		if(addr2>=LSA(slot) && addr2>=LEA(slot)) // if next sample exceed then current must exceed too
 		{
-		case 0:	//no loop
-			if(*addr[addr_select]>=LSA(slot) && *addr[addr_select]>=LEA(slot))
-			{
-			//slot->active=0;
+		//slot->active=0;
+		if(slot->mslc) AICA->udata.data[8] |= 0x8000;
+		AICA_StopSlot(slot,0);
+		}
+		break;
+	case 1: //normal loop
+		if(addr2>=LEA(slot))
+		{
+			INT32 rem_addr;
 			if(slot->mslc) AICA->udata.data[8] |= 0x8000;
-			AICA_StopSlot(slot,0);
-			}
-			break;
-		case 1: //normal loop
-			if(*addr[addr_select]>=LEA(slot))
-			{
-				if(slot->mslc) AICA->udata.data[8] |= 0x8000;
-				rem_addr = *slot_addr[addr_select] - (LEA(slot)<<SHIFT);
-				*slot_addr[addr_select]=(LSA(slot)<<SHIFT) + rem_addr;
-
-				if(PCMS(slot)>=2 && addr_select==0)
+			rem_addr = slot->nxt_addr - (LEA(slot)<<SHIFT);
+			slot->nxt_addr = (LSA(slot)<<SHIFT) + rem_addr;
+			if(addr1>=LEA(slot))
+			{
+				rem_addr = slot->cur_addr - (LEA(slot)<<SHIFT);
+				slot->cur_addr = (LSA(slot)<<SHIFT) + rem_addr;
+			}
+				
+			if(PCMS(slot)>=2)
+			{
+				// restore the state @ LSA - the sampler will naturally walk to (LSA + remainder)
+				slot->adbase = &AICA->AICARAM[SA(slot)+(LSA(slot)/2)];
+				slot->curstep = LSA(slot);
+				if (PCMS(slot) == 2)
 				{
-					// restore the state @ LSA - the sampler will naturally walk to (LSA + remainder)
-					slot->adbase = &AICA->AICARAM[SA(slot)+(LSA(slot)/2)];
-					slot->curstep = LSA(slot);
-					if (PCMS(slot) == 2)
-					{
-						slot->cur_sample = slot->cur_lpsample;
-						slot->cur_quant = slot->cur_lpquant;
-					}
-
-//					printf("Looping: slot_addr %x LSA %x LEA %x step %x base %x\n", *slot_addr[addr_select]>>SHIFT, LSA(slot), LEA(slot), slot->curstep, slot->adbase);
-				}
-				else if(PCMS(slot)>=2 && addr_select==1)
-				{
-					slot->nxtbase = &AICA->AICARAM[SA(slot)+(LSA(slot)/2)];
-					slot->nxtstep = LSA(slot);
-					if (PCMS(slot) == 2)
-					{
-						slot->nxt_sample = slot->cur_lpsample;
-						slot->nxt_quant = slot->cur_lpquant;
-					}
+					slot->cur_sample = slot->cur_lpsample;
+					slot->cur_quant = slot->cur_lpquant;
 				}
+//printf("Looping: slot_addr %x LSA %x LEA %x step %x base %x\n", slot->cur_addr>>SHIFT, LSA(slot), LEA(slot), slot->curstep, slot->adbase);
 			}
-			break;
 		}
+		break;
 	}
 
 	if(ALFOS(slot)!=0)
Posted By: R. Belmont

Re: AO SDK release 1.4.3 available - 07/28/08 03:24 PM

Thanks. Updated the SDK again, and this time it includes all of the changes I had intended to go into 1.42 smile
Posted By: ajax16384

Re: AO SDK release 1.4.3 available - 07/28/08 07:00 PM

yet another suggestion:
Code:
--- aosdk_base/eng_dsf/aica.c	2008-07-28 11:16:04.000000000 +0400
+++ aosdk/eng_dsf/aica.c	2008-07-28 22:59:17.914934500 +0400
@@ -800,7 +800,7 @@
 		case 0x15:
 			{
 				int MSLC = (AICA->udata.data[0xc/2]>>8) & 0x3f;	// which slot are we monitoring?
-				unsigned int CA = AICA->Slots[MSLC].cur_addr>>(SHIFT+12);
+				unsigned int CA = AICA->Slots[MSLC].cur_addr>>(SHIFT/*+12*/);
 
 				AICA->udata.data[0x14/2] = CA;
 			}
Posted By: R. Belmont

Re: AO SDK release 1.4.3 available - 07/28/08 09:00 PM

Hmm, I don't notice any difference anywhere with that change. Is there some test case?
Posted By: Deunan Knute

Re: AO SDK release 1.4.3 available - 07/28/08 10:15 PM

Why was there +12 in the first place?
BTW: CA should read zero when the sample ends.
Posted By: R. Belmont

Re: AO SDK release 1.4.3 available - 07/28/08 10:16 PM

The +12 is because on the SCSP CA reads back the sample progress in 4096 byte units (which simplifies the 68000 code necessary for streaming). I assume AICA is different? smile
Posted By: ajax16384

Re: AO SDK release 1.4.3 available - 07/29/08 07:33 AM

According to one of aica specs CA register defined as sample position relative to SA. So, an extra +12 shift was a definitely strange piece of code.

CA should read zero when the slot becomes inactive (!Slots[mslc].active) or if the current slot sample position reaches LEA ?
Posted By: Deunan Knute

Re: AO SDK release 1.4.3 available - 07/29/08 06:23 PM

I checked to be sure smile
CA is sample position (and not address as the name would suggest). It's zero if given channel is not playing and that means position is not advancing. It could be because it was never started, reached LEA, or it's AEG counter reaches 960.
Posted By: Knurek

Re: AO SDK release 1.4.3 available - 10/04/08 09:57 PM

There's been some new DSF ripping going on lately, so if any of you is interested, here's the new stuff (as the Modland admin seems to be busy and has stopped adding new stuff to the pub folder a while ago):

http://hcs64.com/2sf/new/dsf

Includes the first ever(?) Naomi DSF rip - Idol Janshi Suchie-Pai 3.

And speaking of Naomi, here's a little bonus: Lupin the Typing (2002)(Sega)

Requires a fairly recent VGMStream for replaying. Not sure if the version available here: http://sourceforge.net/projects/vgmstream will play it (AICA ADPCM was added pretty recently IIRC), but eventually it ought to be updated. Nice jazzy music as per usual with Lupin games.

All rips done by manakoAT.
Posted By: R. Belmont

Re: AO SDK release 1.4.3 available - 10/04/08 10:26 PM

Nifty, those all sound great.
Posted By: Knurek

Re: AO SDK release 1.4.3 available - 10/04/08 10:40 PM

Pity most of the sequenced Naomi games seem to use a different driver (libsnd with DTPK signature vs manatee on standard DC games). Maybe the former lets the games use all 8MB of Naomi sound RAM, dunno?
Posted By: R. Belmont

Re: AO SDK release 1.4.3 available - 10/04/08 11:21 PM

Yeah, I tried logging the setup for that driver now that several games boot in MAME but I couldn't make much sense of it. Maybe Deunan or someone will have better luck.
Posted By: Knurek

Re: AO SDK release 1.4.3 available - 10/09/08 03:48 PM

Two more sets, this time by me:

Memories Off Complete (2000)(KID)
Mercurius Pretty - End of the Century (2000)(Stack, Longshot, NEC Interchannel)

http://hcs64.com/2sf/new/dsf/

Much thanks to a certain very nice guy.
Posted By: R. Belmont

Re: AO SDK release 1.4.3 available - 10/09/08 03:50 PM

Nice. I seem to recall people scoffing at the idea that there'd be more than about half a dozen DC games with sequenced music. Glad to see that's wrong smile
Posted By: Knurek

Re: AO SDK release 1.4.3 available - 10/10/08 05:36 PM

Our daily DSF rippage continues:

manakoAT:
Close to - Inori no Oka (2001)(KID)
Elemental Gimmick Gear (1999)(Birthday, Hudson Soft)

me:
Memories Off 2nd (2001)(KID)
Never7 - The End of Infinity (2000)(KID)

http://hcs64.com/2sf/new/dsf/
Posted By: Knurek

Re: AO SDK release 1.4.3 available - 10/11/08 11:59 AM

4 new sets today:

Ever 17 - The Out of Infinity (2002)(KID)
My Merry May (2002)(KID)
My Merry Maybe (2003)(KID)
Tentama - 1st Sunny Side (2001)(KID)

In the usual place.

BTW, figured out what's the dealie with KID games having two copies of the same song. First one is looping, while the second one actually ends.
Posted By: Knurek

Re: AO SDK release 1.4.3 available - 10/12/08 11:31 AM

Some new DSF rips today:

Atsumare! Guruguru Onsen (1999)(Overworks, Sega)
Boku to Bokura no Natsu (2002)(KID)
Erde - Nezu no Ki no Shita de (2003)(KID)
Iris (2003)(KID)
Milky Season (2002)(KID)
Omoide ni Kawaru Kimi - Memories Off (2002)(KID)
Yume no Tsubasa - Fate of Heart (2001)(KID)

In the usual place.
Posted By: Knurek

Re: AO SDK release 1.4.3 available - 10/15/08 02:40 PM

5 new rips today:

kingshriek:

Akihabara Dennou-gumi Pata Pies! (1999)(Westone, Sega)
Mahjong Taikai 2 Special (1999)(Koei)

me:

Atelier Marie & Elie - Salburg no Renkinjutsushi (2001)(Gust, Kool Kizz Amusement Works)
Nobunaga's Ambition - Shouseiroku with Power Up Kit (1999)(Koei)
Remember 11 - The Age of Infinity Demo (2003)(KID)

Remember 11 SOUND.AFS file seems to contain all music files from Ever17. I didn't include those
Posted By: Knurek

Re: AO SDK release 1.4.3 available - 10/16/08 05:21 PM

new rips for today:

Black Matrix Advanced (1999)(Flight Plan, NEC Interchannel)
Blue Stinger (1999)(Climax Graphics, Sega)
Konohana - True Report (2001)(Vridge, Success)
Milky Season (2002)(KID) [miniDSF repack by kingshriek]
Pia Carrot he Youkoso!! 2 (2001)(Cocktail Soft, Stack, NEC Interchannel)
Sister Princess Premium Edition (2002)(Stack, Media Works)

http://hcs64.com/2sf/new/dsf/

Black Matrix is about as weird as possible with VGM (sRPG with music that wouldn't feel out of place in Pulp Fiction? WTF?).
Posted By: R. Belmont

Re: AO SDK release 1.4.3 available - 10/16/08 05:24 PM

Blue Stinger would've been legendary if they could have fixed the camera. Cranking up those tunes now :-)
Posted By: Knurek

Re: AO SDK release 1.4.3 available - 10/16/08 05:30 PM

I'm not sure if Blue Stinger is complete. There are some gaps in the file numeration (no M01 or M08).

Those might be used in the movies though (there were a few SFD files, but with vocals mixed in, so I didn't include the audio tracks from those).
Or might be something with the GDI file extractor I'm using, dunno...
Posted By: R. Belmont

Re: AO SDK release 1.4.3 available - 10/17/08 02:00 PM

The goofy fake Christmas song is present and plays great (M04.dsf) and that's what I was most hoping to hear, so I call it a huge success ;-)

I was going to suggest you could probably at least title-tag Black/Matrix Advanced from the SSF and PSF2 Black/Matrix sets (which have title tags) but they call the same song different things. The Cypress Hill-sounding song that's in all the sets (BGM_004 in Advanced) is called "Zombie Spray" in the SSF set and "Beat the Jazz" in the PSF2, for instance.
Posted By: Knurek

Re: AO SDK release 1.4.3 available - 10/17/08 06:12 PM

4 new rips today:

by manakoAT:
Tetris 4D (1998)(Bullet Proof Software)

and three by me:

Dancing Blade Katteni Momotenshi! (1998)(Konami)
Fire Pro Wrestling D (2001)(Vaill, S-Neo, Spike)
Idol Janshi wo Tsukucchaou (1999)(Jaleco)

Word of a warning. The latter two games make extensive use of CD-DA (or rather GD-DA). I've included them (APS MP3 should be playable just about anywhere), which kinda makes the set largeish. For pure DSF packs, you'll have to wait for Modland to catch up with the latest ripping spree.

Fire Pro is as bad as it gets (700 kB of DSF files vs 120+ MB of MP3). But hey, at least you're getting the whole game soundtrack, not just 5 minutes worth of jingles. smile
Posted By: Richard Bannister

Re: AO SDK release 1.4.3 available - 10/17/08 09:01 PM

I'm joining this thread late and appear to have missed some of these rips. Are the deleted ones around anywhere else?
Posted By: Knurek

Re: AO SDK release 1.4.3 available - 10/17/08 09:11 PM

Yes, all should be on Modland (sans the streamed tracks though). Modland Frontend might help if you're ftp impaired.

Or if you can wait a while, I plan to reupload all the sets when I manage to find some free time. The older sets were deleted since kingshriek released his DSF timer tool.
Posted By: Knurek

Re: AO SDK release 1.4.3 available - 10/18/08 07:30 AM

Also, there's this: DSF Torrent

In semi OT, I'm curious how on earth did people put up with the crap the DC scene did with CDI rips...
Resampling lossy music from 44kHz to 22/11kHz isn't even as bad as what they did with Soul Calibur (there were L and R files for each song, pretty obvious what each of them does). The rippers deleted all R files as dupes and resampled the L ones to 22kHz, making the game... Well, you get the picture.
Thank god for GDIs.
Posted By: R. Belmont

Re: AO SDK release 1.4.3 available - 10/18/08 01:39 PM

A lot of CD systems are still distributed as ISO + 128 kbit MP3, which isn't a whole lot better.

Incidentally, some of the Blue Stinger songs have real endings, after which there's a brief pause before they start over. The current time tags make them play completely through twice and then fade out when the third time starts, which sounds a little weird.
Posted By: Knurek

Re: AO SDK release 1.4.3 available - 10/19/08 12:26 AM

Well, kingshriek's timer parses the whole sequence data, so it's just set up originally this way.
You can just retime those using dsftime.py with one loop, not two and zero fade. smile
Posted By: kingshriek

Re: AO SDK release 1.4.3 available - 10/19/08 01:55 PM

Noticed a few Naomi incompatibilities in AOSDK 1.4.3:

- dc_read16() function is limited to 2 MB
- SA channel register is a bit too short (22 instead of 23 bits).

Code:
diff -Nru aosdk_base/eng_dsf/aica.c aosdk/eng_dsf/aica.c
--- aosdk_base/eng_dsf/aica.c	2008-07-28 11:16:04.000000000 -0700
+++ aosdk/eng_dsf/aica.c	2008-10-19 06:41:52.000000000 -0700
@@ -41,7 +41,7 @@
 #define LPCTL(slot)		((slot->udata.data[0x0]>>0x9)&0x0001)
 #define PCMS(slot)		((slot->udata.data[0x0]>>0x7)&0x0003)
 
-#define SA(slot)		(((slot->udata.data[0x0]&0x3F)<<16)|(slot->udata.data[0x4/2]))
+#define SA(slot)		(((slot->udata.data[0x0]&0x7F)<<16)|(slot->udata.data[0x4/2]))
 
 #define LSA(slot)		(slot->udata.data[0x8/2])
 
diff -Nru aosdk_base/eng_dsf/dc_hw.c aosdk/eng_dsf/dc_hw.c
--- aosdk_base/eng_dsf/dc_hw.c	2008-02-18 09:19:58.000000000 -0800
+++ aosdk/eng_dsf/dc_hw.c	2008-10-19 06:41:11.000000000 -0700
@@ -74,7 +74,7 @@
 
 uint16 dc_read16(int addr)
 {
-	if (addr < 0x200000)
+	if (addr < 0x800000)
 	{
 		return dc_ram[addr] | (dc_ram[addr+1]<<8);
 	}
Posted By: R. Belmont

Re: AO SDK release 1.4.3 available - 10/19/08 03:03 PM

Very nice. The SA fix greatly improves Toy Fighter in MAME (except in some cases where I'm pretty sure it's streaming samples from the cartridge). I'll update the SDK and AO.

I need to get you a rip from ST-V Columns '97 soon too. It's got an SCSP DSP program with an instruction where "IRA" is greater than 0x31, with predictably crashing results.
Posted By: R. Belmont

Re: AO SDK release 1.4.4 available - 10/19/08 03:17 PM

And here's the updated SDK.
Posted By: R. Belmont

Re: AO SDK release 1.4.4 available - 10/19/08 03:50 PM

The Columns '97 RAM image is here:

http://rbelmont.mameworld.info/col97.zip

Looks like an unknown driver ("Ver 3.2.6|96 9/14|Tit&Sat by Hiro F.") to boot, although the host commands at least seem compatible.
Posted By: Deunan Knute

Re: AO SDK release 1.4.4 available - 10/19/08 08:02 PM

Consider #define'ing AICA RAM size to 2/8MB, selected by another definition (command-line given) to switch between NAOMI and DC. Also, rather than doing that if (in_range) you could do address & mask, where mask is size - 1. This way you can always have wide SA and not worry about it, as it will get masked and fit into DC memory even if you set the high bits.
This BTW makes my life much easier, I can work on either project and when I change the sources I just copy the files over.

I know next to nothing about Saturn but my DSP code treats invalid IRA as hardware zeros. Well it's either that or the address decoder only tests the highest bits and will wrap.
Then again I've seen some "invalid" values being written to hardware and performing neat tricks smile
Posted By: R. Belmont

Re: AO SDK release 1.4.4 available - 10/20/08 02:58 AM

It'd be nice to test some of the "out of range" things on real hardware sometime.

BTW, DK, I'll warn you in advance: 99% of the bitching we get about the Windows version of AO is due to the stupid and misleading error messages XP and Vista generate when the newer runtime DLLs are missing (usually something about "incorrect install"). Brace yourself smile
Posted By: Deunan Knute

Re: AO SDK release 1.4.4 available - 10/20/08 09:40 AM

I can test that particular case on my DC (that is, SA vs 2MB). I hadn't so far because I've never had any problems related to addressing.

As for the MS compiler - Knurek was my test subject (though it's usually guinea pigs that are used for that *) and he got it running within minutes.
I admit the SxS error message you get is cryptic at best - shame on MS for that. There are several ways to make it work, the preffered being to download and install a redistributable with necessary dynamic libraries. It's only 4MB and all you need to do is run it and wait for the progress bar to reach 100%. And that's it, Makaron starts working again. A bit of a pain in the behind, yes, but a small price to pay for a decent compiler + debugger combo. If it has bugs I've yet to find them.

*) that joke is only funny in Polish smile
Posted By: R. Belmont

Re: AO SDK release 1.4.4 available - 10/20/08 01:26 PM

SA I expect would wrap on the real DC, but I gave up on trying to predict Sega somewhere around Charles discovering that System 16 had a fully remappable address space for no particular reason.

And if users could follow instructions... smile
Posted By: Knurek

Re: AO SDK release 1.4.4 available - 10/20/08 03:17 PM

Two new DSF rips:

Guruguru Onsen 2 (2001)(Overworks, Sega)
Industrial Spy - Operation Espionage [Espion-Age-Nts] (1999)(HuneX, NEC)

Guruguru Onsen 2 shares some tracks with the earlier Atsumare Guruguru Onsen rip. The source MLTs are binary different, so I've included them just to be safe.

Both available here:
http://hcs64.com/dsf/

I'll upload the older rips soonish (maybe add a proper frontend too, we'll see).
Posted By: Deunan Knute

Re: AO SDK release 1.4.4 available - 10/21/08 07:01 PM

Sorry it took so long but I had other things on my head...
As was to be expected, Dreamcast AICA will effectively ignore the highest bits of a given channel SA. Address decoding in this case is imperfect and the physical 2MB memory is being mirrored in the available address range. This is true for both AICA side and SH4 side access.

As for DSP - testing that would require me to create a whole new tool (my current code doesn't even touch DSP). Quite frankly I'm too lazy for that smile However, if someone comes up with a KOS-compatible source, ELF, plain binary, or even a hacked 2MB memory dump from AO for example - I will give that a try.
Posted By: Knurek

Re: AO SDK release 1.4.4 available - 10/23/08 09:38 PM

Ladies and gentlemen, two new DSF rips:

DiGi Charat Fantasy (2001)(Westone, Broccoli)
Eve Zero Perfect Edition - Ark of the Matter (2001)(C's Ware, Gamevillage)

Do enjoy, Eve Zero is really nice from what I've listened to.

http://dsf.hcs64.com/
Posted By: Knurek

Re: AO SDK release 1.4.4 available - 10/29/08 12:24 AM

Four new DSF rips today:

Giga Wing (1999)(Takumi, Capcom)
Hundred Swords (2001)(Sega) [by manakoAT]
Langrisser Millenium (1999)(Santa Entertainment, Masaya, NCS)
Shin Nihon Pro Wrestling Toukon Retsuden 4 (1999)(Tomy) [mostly streamed, those are just some menu tunes]

Hundred Swords is insane (yes, that's 70 MB of pure sequenced music) if a bit clicky (some glitches in ADPCM decoding?).
Posted By: kingshriek

Re: AO SDK release 1.4.4 available - 10/30/08 06:48 AM

I've been attacking the AM2 (DTPK) sound driver this past week and now understand enough of it to successfully rip dsfs. So, I tested out some Virtua Fighter 3TB rips with AOSDK 1.4.4 and noticed the following:

(1) They are playing way too slow.
(2) Many voices aren't being keyed-on properly (many are cut off abruptly).

(1) was obviously a timer problem. A quick scan through aica.c revealed a few places where the timer register offsets were incorrect (some of these were actually using SCSP offsets). I changed these offsets to the correct values and the VF3 tracks are now playing at the correct speed. Interestingly enough, the AM2 driver actually runs on Timer B (so it is actually used for something).

For (2), I was almost certain that was related to slot-monitoring based on previous experience with Segagaga. Some quick tests confirmed my hypothesis. I'm not exactly sure how to fix this, but commenting out the AEG monitoring fixes the rest of the problems with VF3TB dsf playback.

patch:
Code:
diff -Nru aosdk_base/eng_dsf/aica.c aosdk/eng_dsf/aica.c
--- aosdk_base/eng_dsf/aica.c	2008-07-28 11:16:04.000000000 -0700
+++ aosdk/eng_dsf/aica.c	2008-10-29 22:54:12.000000000 -0700
@@ -469,6 +469,7 @@
 		slot->active=0;
 	}
 	slot->udata.data[0]&=~0x4000;
+	
 }
 
 #define log_base_2(n) (log((float) n)/log((float) 2))
@@ -712,16 +713,16 @@
 		case 0x95:
 			if(AICA->Master)
 			{
-				AICA->TimPris[1]=1<<((AICA->udata.data[0x92/2]>>8)&0x7);
-				AICA->TimCnt[1]=(AICA->udata.data[0x92/2]&0xff)<<8;
+				AICA->TimPris[1]=1<<((AICA->udata.data[0x94/2]>>8)&0x7);
+				AICA->TimCnt[1]=(AICA->udata.data[0x94/2]&0xff)<<8;
 			}
 			break;
 		case 0x98:
 		case 0x99:
 			if(AICA->Master)
 			{
-				AICA->TimPris[2]=1<<((AICA->udata.data[0x94/2]>>8)&0x7);
-				AICA->TimCnt[2]=(AICA->udata.data[0x94/2]&0xff)<<8;
+				AICA->TimPris[2]=1<<((AICA->udata.data[0x98/2]>>8)&0x7);
+				AICA->TimCnt[2]=(AICA->udata.data[0x98/2]&0xff)<<8;
 			}
 			break;
 		case 0xa4:	//SCIRE
@@ -912,7 +913,7 @@
 {
 	if(AICA->TimCnt[0]<=0xff00)
 	{
- 		AICA->TimCnt[0] += ticks << (8-((AICA->udata.data[0x18/2]>>8)&0x7));
+ 		AICA->TimCnt[0] += ticks << (8-((AICA->udata.data[0x90/2]>>8)&0x7));
 		if (AICA->TimCnt[0] > 0xFF00)
 		{
 			AICA->TimCnt[0] = 0xFFFF;
@@ -924,7 +925,7 @@
 
 	if(AICA->TimCnt[1]<=0xff00)
 	{
-		AICA->TimCnt[1] += ticks << (8-((AICA->udata.data[0x1a/2]>>8)&0x7));
+		AICA->TimCnt[1] += ticks << (8-((AICA->udata.data[0x94/2]>>8)&0x7));
 		if (AICA->TimCnt[1] > 0xFF00)
 		{
 			AICA->TimCnt[1] = 0xFFFF;
@@ -936,7 +937,7 @@
 
 	if(AICA->TimCnt[2]<=0xff00)
 	{
-		AICA->TimCnt[2] += ticks << (8-((AICA->udata.data[0x1c/2]>>8)&0x7));
+		AICA->TimCnt[2] += ticks << (8-((AICA->udata.data[0x98/2]>>8)&0x7));
 		if (AICA->TimCnt[2] > 0xFF00)
 		{
 			AICA->TimCnt[2] = 0xFFFF;
@@ -1096,7 +1097,7 @@
 		if (!(AFSEL(AICA)))
 		{
 			AICA->udata.data[0x10/2] |= slot->EG.state<<13;
-			AICA->udata.data[0x10/2] |= 0x3FF - (slot->EG.volume>>EG_SHIFT);
+			//AICA->udata.data[0x10/2] |= 0x3FF - (slot->EG.volume>>EG_SHIFT);
 		}
 	}
 


test data:
http://www.snesmusic.org/hoot/kingshriek/other/dsfdtpk_test.zip
Posted By: Knurek

Re: AO SDK release 1.4.4 available - 10/30/08 07:55 AM

Great news, since the driver is used in most Naomi games and a few DC ones too to boot (Guilty Gear X, Shenmue IIRC).

Should I upload the music data from other games for you to play with?
Posted By: Deunan Knute

Re: AO SDK release 1.4.4 available - 10/30/08 12:29 PM

It would seem my code can play that test DSF just fine. Well, at the very least I don't have to worry about those SCSP copy/paste bugs smile

As for AEG monitor... I don't think it can be fixed. AO treats AEG like a fancy addition to volume control but it's way more than that.
I do have an idea though: AO only keeps track of the EG volume and uses 10 bits for that, meaning it can go from 0 to 1023 (and back). However the AEG internal state counter range is only 0 to 959. Try either masking, or better yet - rescaling, the value that's being put into the monitoring register. It's a hack but it might just be enough to fool the driver.
Posted By: R. Belmont

Re: AO SDK release 1.4.4 available - 10/30/08 01:25 PM

"I don't think it can be fixed"? Dude, it's only code.
Posted By: Deunan Knute

Re: AO SDK release 1.4.4 available - 10/30/08 02:16 PM

Semantics. This all depends on your definition of a "fix".
What I'm trying to say here is the algorithm behind that code is at fault, so this particular problem would require a "change" (not a trivial one IMO) rather than a "fix".
Posted By: R. Belmont

Re: AO SDK release 1.4.4 available - 10/30/08 02:37 PM

My definition of a "fix" is "correct operation of the emulated hardware" (more than ever given that the hack for Segagaga is what broke VF3). We're trying to advance the (only) working public emulation of the AICA here. If you have patches or pseudocode or anything else that's helpful towards that end I'd love to hear it. "It's not as good as Makaron and I don't think it can be fixed" is not really what I'm looking for smile
Posted By: Deunan Knute

Re: AO SDK release 1.4.4 available - 10/30/08 05:06 PM

Thing is, it's such a mess I don't know where to begin...
AO's AICA more or less worked without AEG in it at first - and that is the root of all evil. Don't take me wrong - my own code was like that too, once. In short: if you can key on/off channels and set volume without emulating AEG, it's a hack.
Only when I added AEG to my code I could finally make it behave like the hardware would. But that was a big move, one I call a rewrite. Definitely not a "fix".

You should start with Corlett's document on AICA. The perfect timings on AEG are a nice touch, but not required. You can go with the values from SEGA docs too and noone would be the wiser. I you really want perfect timing that's another level of difficulty.
If you want I can provide you with my AICA sources. Though this time only for reference and not to be directly included into any open source project. And don't go thinking it'd be piece of cake to figure it out just because you got the ARM7 core running smile
Posted By: R. Belmont

Re: AO SDK release 1.4.4 available - 10/30/08 05:36 PM

Cool. I know I have Corlett's document someplace, I'm just not sure where wink
Posted By: Knurek

Re: AO SDK release 1.4.4 available - 11/02/08 01:20 AM

Three new DSF rips today:

Guilty Gear X (2000)(Arc System Works, Sammy)
Sega GT (2000)(Tose, Sega)
Takoron (Naomi)(2007)(Compile Heart)

GGX and Sega GT are mostly streamed (Sega GT still has roughly 20 minutes of Sega Arcade Music (TM) though, so enjoy).

Both Guilty Gear X and Takoron use the AM2 driver, and both don't really work in either in_aosdk (bad tempo) and current AOSDK compile (Takoron needs AEG code tinkered with, GGX crashes the driver few seconds in each song).

http://dsf.hcs64.com/
Posted By: kingshriek

Re: AO SDK release 1.4.4 available - 11/02/08 04:57 AM

To be more precise, GGX isn't actually crashing the driver but instead is keying on looped samples with LSA > LEA and this is being mishandled.

Code:
StartSlot[0E]:   SSCTL 0 SA 04EFEA LSA FFEC LEA 0008 PCMS 2 LPCTL 1
                 AR 1F D1R 00 D2R 00 RR 1F DL 00 KRS 0 LPSLNK 0
                 TL 0C OCT 0 FNS 000
                 LFORE 0 LFOF 00 ALFOWS 0 ALFOS 0 PLFOWS 0 PLFOS 0
                 IMXL 0 ISEL 0 DISDL C DIPAN 17


I'm not exactly what the hardware does in this case, but it would make the most sense if LEA is only processed after LSA is reached, and for this to work, the sample counter needs to rollover upon reaching 0x10000.

AOSDK isn't applying this rollover, and in this particular case, havoc ensues with the steps_to_go part of the ADPCM decoder as this value gets very large and contiunes to increase, unbounded. The result of this is the sound processing spends most of it's time chasing this everly increasing steps_to_go value and is unable to update the sound buffer at the required 44.1 kHz. And so, the end user then hears something along the likes of a broken record.
Posted By: R. Belmont

Re: AO SDK release 1.4.4 available - 11/02/08 05:10 AM

That makes sense. I'll take a look.
Posted By: Knurek

Re: AO SDK release 1.4.4 available - 11/02/08 06:04 PM

New DSF rips for today:

Quiz Keitai Q-Mode (Naomi)(2002)(Amedio, Taito)
Slashout (Naomi)(2000)(Sega)
Spikers Battle (Naomi)(2001)(Sega)
Sports Jam (Naomi)(2001)(Sega)
Street Fighter Zero 3 Upper (Naomi)(2001)(Capcom)
Super Major League (Naomi)(2001)(Sega)
Super Shanghai 2005 (Naomi)(2005)(Star Fish)
Virtua Athlete 2000 (2000)(Sega)
Virtua Golf (Naomi)(2001)(Sega)
Posted By: Deunan Knute

Re: AO SDK release 1.4.4 available - 11/02/08 09:35 PM

...no. LSA > LEA = all hell breaks loose.
Well, it's maybe not that bad but it's pretty much undefined behaviour.

I think it's a bug. Could be ARM core (sigh) or a broken driver.
1) I see that happening on my code as well (still works though)
2) Even if a channel is started like this, it will be stopped moments later (as in less than a second, much less)
3) Quite frankly loop like this makes no sense smile

On hardware this setting is simply invalid. This is what happens on simple 400Hz test tone (44100 samples, 16-bit sine wave):
1) The loop goes fine once
2) There is a brief period of silence (1/4 a second give or take)
3) Squeaking starts :P

Hard to say why 3) sounds like it does, but since my program zeroes all AICA memory it could be the sine wave itself but played at much higher speed, along with the empty part of memory up to 0xffff (realative to SA). This is as good guess as any smile
Anyway, once in this mode CA reports pretty much random values. Maybe because of how fast it goes. This is consistent with the fact that "loop jump" flag gets set shortly after it's read (and thus reset). But it does reset so the loop still works.

Note: CA does not fall within the 0xFFEC -> 0x(1)0008 range, it spans entire 0xffff range. My code will keep the loop going but will limit the range and will not change speed. I say it's invalid setting so I'm not keen on trying very hard to match hardware here...

EDIT: One more thing. GGX tune plays fine (?) both in my player and as AICA RAM dump on DC. This is most likely due to channels with invalid valued being promptly turned off, so not much sound is produced anyway. Or maybe a real ARM is not doing that to AICA. Anyway, it works.
Posted By: Knurek

Re: AO SDK release 1.4.4 available - 11/02/08 09:50 PM

If you're hearing nice, instrumental rock, then GGX plays fine.
Posted By: R. Belmont

Re: AO SDK release 1.4.4 available - 11/02/08 09:55 PM

Thanks for testing on hardware, DK. That's useful to know. I can try with a different ARM core and see if weird LSA/LEA values are also written.

Update: MAME's ARM core writes identical wacky LSA/LEA values. I changed my AICA so that on keyon if LSA > LEA it sets LEA to 0xffff and that seems to work for the Guilty Gear X tracks even if it's not what actually happens smile

Update 2: I hacked up the AEG monitor as Deunan recommended (scaling the result to 0-959) and both Takoron and the VF3 test rip seem to play properly now.
Posted By: R. Belmont

Re: AO SDK release 1.4.5 available - 11/02/08 10:46 PM

AOSDK 1.4.5 is posted. This fixes Guilty Gear X, Takaron, and probably other things.
Posted By: R. Belmont

Re: AO SDK release 1.4.5 available - 11/02/08 11:06 PM

Incidentally, Slashout_019_50.dsf and several of Knurek's other most recent rips are keying on voices with very low SA (0x001a6c, for instance) and thus "playing" the ARM7 code and data (which unsurprisingly sounds like gibberish). I'm guessing ripping the AM2 driver isn't quite perfected yet? smile
Posted By: Deunan Knute

Re: AO SDK release 1.4.5 available - 11/03/08 01:07 AM

Just FYI some Dreamcast games make use of AEG monitoring (and in strange places too), that hack might not work for them. But there's only a handful of those.

Slashout_019_50.dsf works for me. Not a single SA below 0x2000 (and I don't hear any strange noises either). Maybe it's another case of Dreamcast 2MB mask/limit being applied somewhere?
Posted By: R. Belmont

Re: AO SDK release 1.4.5 available - 11/03/08 01:16 AM

The same song keys on something up in the 0x7fxxxx range, so masking is definitely not happening. Or at least it's not in the AICA anyway.

ETA: Found it. The AM2 driver requires that unused words in the AICA address space return 0x0000. Anything else makes it screw up an address calculation.
Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 11/03/08 02:40 AM

1.4.6 with that fix is now up. It should play all the current rips decently. Applying similar fixes to MAME made Toy Fighter sound a lot better (it's DTPK too - I'd rip it myself if I knew where to get the driver image that the ripper wants).
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 11/03/08 06:15 AM

RB, search for AM2/AICA, go *back* 0x20 bytes from beginning of the string and extract 0xf000 bytes or up to the 0x00 bytes end (it's usually smaller than that, co can 0xf000 can overflow into DTPK data). That should be the driver.

toyfight one:

bcut mpr-22033.ic9 aicadrv.bin 0x558f00 0xd000
Posted By: kingshriek

Re: AO SDK release 1.4.6 available - 11/03/08 06:41 AM

Or you can grab am2drvext.py that I just put up on my site which basically does just that (although I extract 0x10000 bytes just to be on the safe side).

EDIT: Actually, it seems that the size of the driver is specified at 0x54 - no need to guess.
Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 11/03/08 02:04 PM

Perfect, that made a working rip the first try smile Does dsftime work with DTPK tracks? I get this error (using Python 2.5.1 on Linux, which works with all your other stuff fine):

Code:
Traceback (most recent call last):
  File "../dsftime.py", line 296, in <module>
    dsftime(ndsf)
  File "../dsftime.py", line 239, in dsftime
    trackdata = gettrack(dsfbin)
  File "../dsftime.py", line 83, in gettrack
    offseq = unpack('<I',areamap[0x8*bank:0x8*bank+4])[0]
UnboundLocalError: local variable 'bank' referenced before assignment
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 11/03/08 03:58 PM

dsftime.py handles only manatee.drv files (since it's keyed to interpret MSB files, not monitor read/writes on emulated memory, like other autotimers do), hence why all my DTPK rips are untimed too.
Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 11/03/08 06:05 PM

My Toy Fighter rip is now posted. I don't know if the plugin's been updated to 1.4.6 spec yet, but it should work fine once it has been. I also was able to rip a bunch of sound effects from the Naomi BIOS, some of which aren't playing in AOSDK for some reason. I'll investigate smile
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 11/04/08 12:03 AM

Three new rips for today:

Dead or Alive 2 (Naomi)(1999)(Tecmo)
Sega Marine Fishing (Naomi)(1999)(Sega)
Virtua Fighter 4 (Naomi 2)(2001)(Sega)

I've also mirrored RB's Toy Fighter rip.

http://dsf.hcs64.com

Haven't checked any of those with AOSDK (been using Deunan's player for testing, since the plugins aren't updated yet).

Incidently, RB, if you want to add streamed Naomi sets to M1 (like the MP3 Model 3 ones), here's the relevant info.

ADX (lotsa rippers for this one, so you should be able to find the file offsets/player easily):

Melty Blood - Act Cadenza (take note, one ADX file is muxed into SFD stream)
Musapey no Choco Marker
Senko no Ronde

AM2 SPSD stream container:

Capcom Vs. SNK - Millennium Fight 2000 Pro
Capcom Vs. SNK 2 - Millionaire Fighting 2001
Guilty Gear XX #Reload (has one additional music more than normal XX)
Mobile Suit Gundam - Federation Vs. Zeon DX (didn't try the normal version, but I imagine it doesn't have more music than this one).

How to rip/play SPSD files:

SPSD magic at offset 0x00, 0x40 bytes of header, then Yamaha ADPCM data (all files I've seen have 2 channels with 0x2000 interleave).
Offset 0x0c in header stores # of samples in the file (DWORD, LE). Add header size to that and you have full SPSD filesize.
Offset 0x2a in header stores stream frequency (WORD, LE).

SPSD files are playable by a fairly recent VGMStream compile (say, from yesterday).
Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 11/04/08 01:03 AM

VF4's songs are built entirely out of loops (more like a MOD than normal sequencing) and it looks like the timer's a little slow in AOSDK because they don't quite match up. I'll massage it ;-) DOA2 and Marine Fishing sound fine.

ETA: fixed it, VF4's now seamless. I should've followed SCSP more closely on this one, it had it right ;-)
Posted By: R. Belmont

Re: AO SDK release 1.4.7 available - 11/04/08 02:09 AM

AOSDK 1.4.7 is posted with the tempo fixed so VF4 plays properly.
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 11/04/08 10:53 AM

Originally Posted By R. Belmont
VF4's songs are built entirely out of loops (more like a MOD than normal sequencing)


Wha? That doesn't make any sense, since MODs are sequenced, plain and proper. Unless you're talking about those Amiga MODs that tried to get around the 4ch limit by sampling whole sections of the song...
Though why Sega would want to do that on a 64ch chip is beyond me.

Also, latest dsfdtpk.py flagged all VF4 songs as SFX... Which means I need to go through all games once more, to check if it didn't do so with previous games too.
Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 11/04/08 02:17 PM

Each song is a single mono ADPCM sample which they key on roughly 32k at a time (due to AICA sample size restrictions). It's like streaming except it's entirely resident in AICA RAM. And that's also why it sounds like crap on good speakers, especially compared to a lot of sequenced DSFs.

Given that I'm not surprised it got tagged as SFX since it effectively is.
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 11/04/08 06:39 PM

New sets for today:

http://dsf.hcs64.com/

Initial D - Arcade Stage (Naomi 2)(2002)(Sega)
Virtua Striker 2 Ver.2000 (Naomi)(1999)(Sega)
Virtua Striker 3 (Naomi 2)(2001)(Sega)

Cosmic Smash is purely streamed (SPSD format).

Initial D's streams are broken in VGMStream right now (they aren't interleaved at all, just binary joined). Not sure if this can be derived from the header, if not, I'll post a SPSD->GENH batch soonish.

Think that wraps up all currently dumped Naomi games. smile
Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 11/04/08 07:03 PM

Nice. I was hoping for rippable stuff in the Hikaru dump (Air Trix is complete) but no luck, at least DTPK-wise. That board has two complete 8 meg AICAs (although each with their own ARM7 so a single 128-voice sequence isn't happening).
Posted By: MooglyGuy

Re: AO SDK release 1.4.6 available - 11/04/08 07:31 PM

Originally Posted By R. Belmont
(although each with their own ARM7 so a single 128-voice sequence isn't happening).


I doubt any sane composer would attempt 128-voice music in an arcade game anyway, but I don't see why it would be so impossible to do it with two ARM7s driving 64 voices apiece. As long as one of the SH-4s issues a sound command to both ARM7s at relatively the same time, they should end up playing in sync with no noticeable lag.
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 11/04/08 07:35 PM

It's prolly used like other arcade games with multiple chips, one for music, other for SFX.
That said, I don't see any AM2/AICA refferenced there (even taking into account the fact the roms are bytesplitted).

//Edit

Ack, messed the VF4 and VS3 sets a bit (renamed the dsflibs while not updating the _lib tags in minidsfs).

If you don't want to redownload the whole 28 MB archive just to fix that, here are just the minidsfs:

http://dsf.hcs64.com/Virtua%20Fighter%204%20(Naomi%202)(2001)(Sega)%20fix.zip
http://dsf.hcs64.com/Virtua%20Striker%203%20(Naomi%202)(2001)(Sega)%20fix.zip

Plese tell me if you find any other mistakes. :|
Posted By: Deunan Knute

Re: AO SDK release 1.4.6 available - 11/04/08 10:58 PM

Hey, don't diss on-the-fly joined streams! It might look silly in VF4 but this system can be made to dynamically pick the next fragment to play rather then follow a predefined order. And it can do so in response to change in the game environment.
This extended system was used for in-game music in System Shock 2. They don't make games like this anymore... okay, so maybe HL2 is as good. But not better yet smile
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 11/04/08 11:04 PM

Also used in DC version of Rayman 2 IIRC.
Lotsa small wavs with different sections of the song.
Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 11/04/08 11:49 PM

I like interactive music. It just seems to me that playing relatively low sample rate mono ADPCM for music when you have 64 voices and 8 megs of sample RAM is lame smile

Sega's weird with the VF series though. VF1 and 2 had classic sequenced music. Remix on the ST-V had 8 kHz mono 8-bit streams, VF3 pushed the SCSP harder than anything else probably ever will, and now VF4 is this?
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 11/05/08 04:56 PM

Bacause you just can't have Initial D without eurobeat, here's a batch that will convert the SPSD files into GENH ones that are playable by current public VGMStream.

Songs seem to loop, but I don't think the looppoints are determined in SPSD header, so they are unlooped. They might sound glitchy near the end.

I'll post updated batch if I manage to find them somehow (so keep the original SPSDs handy).

Initial D: Arcade Stage convert batch
Posted By: Deunan Knute

Re: AO SDK release 1.4.6 available - 11/05/08 06:04 PM

Yeah! Don't stop the music!
I gotta be careful not to bring those tunes to the car. Or it's going to hit 7000 rpm way more often than it should :P
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 11/05/08 11:54 PM

Okay, ladies and gentlemen, the big one:

Shenmue (1999)(Sega)

http://dsf.hcs64.com/

BGM061.dsf <3

The lead section craps out a bit under both my (outdated) AOSDK compile and Deunan's player.

BGM093.dsf <3

The 'let's go away' part clicks in both players.

//Edit: NVM, listened to Model 2 version, and it click there too. Not as noticable since the samplerate is clearly lower.
Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 11/06/08 12:33 AM

I'm not sure what "craps out" means wrt Magical Sound Shower. As far as I can tell they just bump the LFO up on certain notes to give it more of an FM-like "growl".
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 11/06/08 01:04 AM

I'll do wave write comparisions tom... later today. One section just sounds weird to me.
Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 11/06/08 03:34 PM

BTW, I've been trying to update the aodsf plugins myself and not having a lot of luck yet. Even unmodified source won't build a working aodsf.bin on VS.NET 2005 - I guess he used '03 or '01. And they need a version of the Foobar 2000 SDK that's no longer available to build that plugin. If there's some way to contact whoever made them that would probably be preferable.
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 11/06/08 04:11 PM

This is what I'm talking about:

http://www.snesmusic.org/hoot/BGM061.dsf.mp3

The last two notes of the section sound kinda off key compared to the arcade original.

In other news, Initial D: Arcade stage SPSD2GENH batch v2

http://dsf.hcs64.com/fix/Initial%20D%20-%20Arcade%20Stage%20SPSD2GENH.zip

Still not perfect, glitches a bit at the loop point, but at least has looping (and no dual file crap to boot).

In other other news, in_aodsf is up to date with AOSDK 1.47 and sounds great. Thanks a lot mysterious plugin guy!
Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 11/06/08 04:55 PM

Ahh, fantastic (re: the plugin getting updated).

ETA: for those who are interested, the plugins are here.
Posted By: Deunan Knute

Re: AO SDK release 1.4.6 available - 11/06/08 06:30 PM

Shenmue tune indeed sounds wrong compared to hardware, because - brace for it - we do not emulate FEG.
Now, FEG is 4-point envelope with a 5-point low-pass filter. All of these values are user-definable of course smile
I'm going to try and implement this monster this weekend. I hope to reuse some of the AEG code...
Posted By: exolon2

Re: AO SDK release 1.4.6 available - 11/07/08 03:16 PM

Hi guys, sorry to butt in with ignorance, but not many of these dumps play in the current AO v2.0 on the Mac (e.g. Shenmue, Initial D, Virtua Golf). Do they depend on recent builds of the AO SDK that make AO outdated?
Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 11/07/08 03:21 PM

Yes. By definition if I fixed those games after the last AO was posted then AO won't play them without an update. And Richard's in Kuala Lumpur so the Mac version can't get updated right now.

Also, Initial D is not sequenced and won't play in AO even after the update. You'll need someone to port VGMStream to the Mac.
Posted By: exolon2

Re: AO SDK release 1.4.6 available - 11/07/08 03:40 PM

Originally Posted By R. Belmont
Also, Initial D is not sequenced and won't play in AO even after the update. You'll need someone to port VGMStream to the Mac.

Would this require in-depth knowledge of all of AO, or could an outsider do it? There are some quality streaming soundtracks out there, so I'd like to help get something working unless it's completely beyond my meagre capabilities laugh
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 11/07/08 03:52 PM

RB, Initial D is partly sequenced. There's even one or two eurobeaty ones.

Also, VGMStream should compile on a POSIX-like system, MacOS X included (the console line player, not the Winamp plugin, obviously). hcs says the program assumes little-endian for now, so I can't say it will work on PPC based systems though.
Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 11/07/08 03:52 PM

It's something I'm interested in adding to AO at some point since there's currently no non-Windows way to play those rips. I had thought the license was incompatible but I just checked it on SourceForge and I was mistaken. Hmm smile
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 11/07/08 04:19 PM

Originally Posted By R. Belmont
It's something I'm interested in adding to AO at some point since there's currently no non-Windows way to play those rips. I had thought the license was incompatible but I just checked it on SourceForge and I was mistaken. Hmm smile


<smartass>
I wonder what will come sooner, system16.com update or new M1 core laugh
</smartass>
Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 11/07/08 04:22 PM

Duke Nukem Forever will be out before system16 updates again smile

I really want to figure out why M1 isn't scheduling 68000s correctly before I release another core update (and it's only the 68000, it's not a core-wide thing), because that has implications for the F3 accidental vibrato as well as possibly finally getting Spy Hunter to behave.
Posted By: exolon2

Re: AO SDK release 1.4.6 available - 11/07/08 04:43 PM

Originally Posted By Knurek
Also, VGMStream should compile on a POSIX-like system, MacOS X included (the console line player, not the Winamp plugin, obviously). hcs says the program assumes little-endian for now, so I can't say it will work on PPC based systems though.

I checked if it would build out of the box, but it depends on Audacious, an apparently Linux-only(?) music player which uses GTK. Can't tell for sure yet because the Audacious website is down and apparently has been for a couple of months.
Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 11/07/08 05:00 PM

Eh? It should build standalone from what I've seen.
Posted By: hcs

Re: AO SDK release 1.4.6 available - 11/07/08 05:01 PM

The whole configure/make thing was designed around building the audacious plugin, but the core of VGMstream is a library without any frontend. There isn't a standalone way to just build that, though (well, a make in /src could work), and there are a few different build systems there so I understand how it can be confusing.

./bootstrap && ./configure && make -f Makefile.unix
for the audacious plugin

make in /
builds the Winamp plugin and command line decoder with the mingw cross-compiler in Ubuntu

make in /test
does a native build of the command line decoder (I guess you want to start with this)

and vgmstream.sln is a MSVC (don't recall which version) solution for building the Winamp plugin and command line decoder for Windows

There is also a dependency on libvorbis and libmpg123. If you remove references to those from the makefile and comment out the VGM_USE_* #defines in vgmstream.h it should work without them.

The endian-dependency mentioned is in the command line decoder; while the wav header is always written little-endian, the audio itself is rendered in host-endian and written straight out to the file. This can be fixed easily enough. But it is that way because I've never had an opportunity to test it on a big-endian system, so there could well be mistakes elsewhere. Also while I tried to be careful about types (using the intXX_t types where needed) it's never been built for anything but 32-bit x86.

Good luck, I'll try to pay attention if you need any help, and if you spot bugs let me know. The test decoder was supposed to be an example for how to interface with the library though it's become a bit unwieldy with features at this point.
Posted By: exolon2

Re: AO SDK release 1.4.6 available - 11/07/08 06:18 PM

Hi hcs,

Thanks for that. Once I'd installed libvorbis and libmpg123 I was indeed able to compile the command-line decoder, although I had to manually specify the library path for some reason.

I'm not exactly sure what to test it on, though - are there any simple examples?
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 11/07/08 06:30 PM

Get the Initial D: Arcade Stage set linked earlier, and the SPSD2GENH batch (you will need to append the headers manually, since I'm using windows CMD.exe commands for it).
Posted By: exolon2

Re: AO SDK release 1.4.6 available - 11/07/08 06:44 PM

Hi Knurek,

Yeah, I made an equivalent bash script which did the appending, but I'm not sure it's working right.

However, I found a .adx file in the DiGi Charat archive which vgmstream converted cleanly to a .wav file, so it looks good.

Incidentally, while looking for streaming music to test, I found another music player called XBMC which works in Linux, Windows, OS X and XBox, and includes vgmstream among a horde of other vgm plugins (but not AO SDK it seems). Looks nice.
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 11/07/08 07:41 PM

If you're talking about a little skip @ looppoint, then yes, the files have that on Windows too.

And VGMStream supports so many formats you shouldn't have a problem finding some files for it if your game collection has more than one entry. smile
Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 11/07/08 09:01 PM

I had no idea, I thought it just played ADX varients smile
Posted By: exolon2

Re: AO SDK release 1.4.6 available - 11/07/08 09:26 PM

Originally Posted By Knurek
If you're talking about a little skip @ looppoint, then yes, the files have that on Windows too.

And VGMStream supports so many formats you shouldn't have a problem finding some files for it if your game collection has more than one entry. smile

No, I mean it dies on the files, printing "failed opening IniD_01.spsd" or similar for each one; maybe looking for header magic which isn't there. Looks like there's no debugging or even higher-verbosity mode in vgmstream, so I'll have to go in and throw printfs about the place - since I'm ignorant here I've no intuition about how to use these tools properly. crazy
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 11/07/08 09:36 PM

Rename to processed files to GENH, it should work then (SPSD is supported only in SVN test compiles).
Posted By: exolon2

Re: AO SDK release 1.4.6 available - 11/07/08 09:53 PM

Hi Knurek, I tried that as well, both GENH and genh in case of case-specific code. Unless I understand your .bat file wrong - mine does:
Code:
for i in 1 2 3 4 5 6 7 8 9
do
	cat IniD_0$i.GENH IniD_0$i.spsd > IniD0$i.spsd.new
	mv IniD0$i.spsd.new IniD0$i.spsd
done

Since there was no output file specified in your "copy /b ...GENH + ...SPSD" I tried both ways, but vgmstream isn't happy. I wish it would give a better error message (at least I code grep a return code in the source) shocked
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 11/07/08 10:04 PM

Hmm, unless cat needs some switch to process files in binary mode(like windows copy does), everything seems to be in order.

Looking at the source of the public version, it doesn't have Yamaha ADPCM GENH support added yet, so that's probably the problem.
Posted By: Deunan Knute

Re: AO SDK release 1.4.6 available - 11/07/08 10:19 PM

Copy with no explict output will append all files to the first one. Try this:
Code:
for i in 1 2 3 4 5 6 7 8 9
do
	cat IniD_0$i.spsd >> IniD_0$i.GENH
done


Now, back to the FEG business. Envelope part is rather easy - there are some things I'm not sure of but this can be tested once it actually works. And it doesn't because the filter part is beyond my skills I'm afraid. This from Neil's doc:
Quote:

out = f * in + (1.0 - f + q) * prev_out - q * prev_prev_out

Where f and q are coefficients. Exactly how f and q are computed, I'm still
not 100% sure. I have a fairly good idea for f:

f = (((filtervalue & 0xFF) | 0x100) << 4) >> ((filtervalue>>8)^0x1F)

Where filtervalue is the filter envelope level, and f becomes a linear value
in the range of 0x0000 (0.0) to 0x1FFF (almost 1.0).

I'm less certain about q. For now, I intend to simply use the Q register
value, where 0x00=0.0 and 0x20=1.0 (max is 0x1F).


First of all, the equation is wrong. If it was like (1.0 - (f + q)) it'd make more sense, but that's still no good. Most of the result comes from f * in part - if the f is too big it won't do much filtering. If it's too small it will all but mute that channel. Since it's only 13 bits I think that ((filtervalue>>8)^0x1F) is a bit of overkill (shifts up to 31 bits).

In short: I'm lost. I've said it before that signal processing is not my forte - I don't really get the math behind IIR filters. I've tried some random changes, alas only ended up with unstable vibrato or noise generators smile Any ideas?
Posted By: exolon2

Re: AO SDK release 1.4.6 available - 11/07/08 11:01 PM

Originally Posted By Knurek
Looking at the source of the public version, it doesn't have Yamaha ADPCM GENH support added yet, so that's probably the problem.

Thanks, you were spot on - I checked out and rebuilt the latest revision from svn it worked first time. smile Great sound too.
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 11/08/08 01:15 AM

Pity the third one didn't get made.

Shenmue II (2001)(Sega) set available:

http://dsf.hcs64.com/

Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 11/08/08 01:26 AM

It's handy that the Afterburner II tracks are all "Ab2_xxxx" smile
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 11/08/08 01:42 AM

Funny how Ab2_001_0D_00_00.minidsf gets heavily distorted after 15 seconds or so.
Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 11/08/08 02:41 AM

Yeah, the crash cymbal in the AB2 sets has a *severe* DC offset. In most of the tracks that voice gets reused pretty soon and it doesn't matter, but on some it doesn't and the overall level gets shoved down against 0dB.
Posted By: kingshriek

Re: AO SDK release 1.4.6 available - 11/08/08 04:30 AM

Originally Posted By Deunan Knute
First of all, the equation is wrong. If it was like (1.0 - (f + q)) it'd make more sense, but that's still no good. Most of the result comes from f * in part - if the f is too big it won't do much filtering. If it's too small it will all but mute that channel. Since it's only 13 bits I think that ((filtervalue>>8)^0x1F) is a bit of overkill (shifts up to 31 bits).


(1.0 - f + q) looks right to me. It produces a stable lowpass filter for all values of f and q between 0.0 and 1.0. (1.0 - (f + q)) has more of a bandpass characteristic.

As for the ((filtervalue>>8)^0x1F) part, it looks a bit weird to me, too - causes more than half the filter values to produce filters w/ zero (-infinity dB) gain.

Originally Posted By Deunan Knute
In short: I'm lost. I've said it before that signal processing is not my forte - I don't really get the math behind IIR filters. I've tried some random changes, alas only ended up with unstable vibrato or noise generators smile Any ideas?


Not sure exactly what's going wrong. Are you scaling the f the q values properly (to account for their fixed-point representation)?
Posted By: Deunan Knute

Re: AO SDK release 1.4.6 available - 11/08/08 09:35 AM

I'm going to check again but this filter simply mutes things too much. I don't know, maybe it's another bug somewhere else but some channels are keyed on with infinite (or close to) attack rate, so we can focus on single-value filtering. In this case filtering value looks like 0x1d78 for example, so you can calculate f for it. Q is 0x400 (0x04 scaled to produce 0x1fff from 0x1f range: << 8 in my case).

If the envelope value is 0x1ff8 it's seems to be working. No low-pass filtering (since x * f is gives back more or less x, q can be all but ignored). Now, the way I understand IIR filters it's supposed to be an integrator of sorts? So, for low cut-off frequency it should be adding very little of the current sample and keep adding the previous values. This way for a DC signal the output should reach the input eventually?
Now, let's say f is close to zero. That gets us small x * f, that's what we want. But even if Q is big, the previous values can only be previous x * f and for DC input it's all the same. So that leaves us with:

y = u0 + (1 + q) * v1 - q * v2 = u0 + v1 + q * (v1 - v2)
(where u0 = f * x input (small), v is previous output, and 1 - f can be replaced with 1)

Let's say x is positive. That makes u and v > 0 always. This means v1 - v2 is also > 0, so the y value will only get bigger over time. And will not stop at input level, but go all the way to infinity. This is not a stable filter?

Theory says 2-nd order IIR looks like this:

y = 1/a0 (b0 * x0 + b1 * x1 - a1 * v1)

a0 is usually 1, so we can do away with it. This filter uses previous input values as well... I kinda like it better than using only previous output values. Then again, I know nothing so don't hit me smile

What order filter are we trying to get here? I guess 2nd or 3rd at best, right? Isn't it strange that we only use previous output values (all bn coefficients are zero then)? I've tried some Java scripts out there to get coefficient values for low-pass filters and would always end up with non-zero b1 at least?

EDIT: One shouldn't be doing math so late at night...
I'm not so sure now 1 - f can be simplified with 1. If I don't do that:

u0 + (1 - f + q) * v1 - q * v2
u0 + v1 - f * v1 + q * (v1 - v2)
v1 + f * (x - v1) + q * (v1 - v2)

q * (v1 - v2) is very small, so we get a fight between x and v1. In the end it should come to an equilibrium when v1 = x... then why the hell I'm getting saturation?
Posted By: kingshriek

Re: AO SDK release 1.4.6 available - 11/08/08 12:47 PM

This particular filter's frequency response spikes up in the passband right before coming to the cutoff frequency. How much it spikes depends mostly on the value of q (f mainly determines where the cutoff frequency happens so it also has a minor affect on the spike). For example, with values f=0.2 and q=0.8, the frequency response gain peaks at about +6.0 dB at 3 kHz, so it definitely has potential to push higher-amplitude tones beyond the saturation range.

I wrote up a quick Python script to examine the impulse and frequency response for this filter for particular values of f and q. Not sure if this will help at all, but here it is just in case:

Code:
from cmath import *

xs = [0.0 for k in range(100)]; xs[0] = 1.0
ys = [0.0, 0.0, 0.0]
ws = [k/100.0 for k in range(101)]

def imp_response(f,q):
	print 'Impulse response'
	i = 0
	for x in xs:
		j = [(i+k)%3 for k in range(3)]
		ys[j[2]] = f*x + (1 - f + q)*ys[j[1]] - q*ys[j[0]]
		print '%02d     %+0.8f' % (i,ys[j[2]])
		i += 1
	
def freq_response(f,q):
	print 'Frequency response'
	for w in ws:
		zi = exp(-1.0j*pi*w)
		H = f / (1 - (1 - f + q)*zi + q*zi*zi)
		print '%7.1f Hz     %+2.3f dB' % (22050.0*w,20.0*log10(abs(H)).real)

if __name__ == '__main__':
	f = 0.2
	q = 0.8
	imp_response(f,q)
	freq_response(f,q)



Posted By: Deunan Knute

Re: AO SDK release 1.4.6 available - 11/08/08 03:13 PM

If an equation doesn't work it means that assumptions are incorrect. In this case I wrote "q * (v1 - v2) is very small" but turns out it was not. More specifically I was getting rather big v1 & v2 and with different sign. That really upset the filter and made it into noise generator. The cause? I messed up the integrator part, I was assigning wrong value to the "prev_out"...
You may kill me now smile

I'm still not sure about some of the envelope stuff, or when exactly I should be doing sample range saturation, but it seems to work now.
Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 11/08/08 03:23 PM

So what are the final correct equations for f, q, and out so I can fix my copy of Neill's document? smile
Posted By: Deunan Knute

Re: AO SDK release 1.4.6 available - 11/08/08 03:43 PM

I went with Corlett's original suggestions for now. I've tried various things, for example:
f = (((filtervalue & 0xFF) | 0x100) * (filtervalue>>8)) >> 1
but this doesn't do enough filtering.
Looking at the graphs in AICA docs, the sensible filter values (cutoff > 100Hz) start at 0x1400 anyway. So maybe it really is shifted like that.
As for q, I just shift it 8 bits left to make all coefficients 13-bit.
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 01/06/09 12:18 PM

Managed to find another sequenced game:

Treasure Strike (2000)(h.a.n.d., KID):

http://dsf.hcs64.com/Treasure%20Strike%20(2000)(h.a.n.d.,%20KID).zip

Pretty crappy music compared to other KID games, but they only published this one.
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 01/06/09 08:27 PM

One more for today, from Saturn this time:

Conveni, The - Ano Machi wo Dokusen Seyo (1997)(Masterpiece, Access, Human):

http://2sf.hcs64.com/rip/Conveni,%20The%20-%20Ano%20Machi%20wo%20Dokusen%20Seyo%20(1997)(Masterpiece,%20Access,%20Human).zip

This game uses 2.04 version of the driver (the one that's very quiet). Did use the original driver and opted for volume=100 tag. Seems to help, don't hear anything bad with the rip (well, it's still kinda quite, but at least you can listen to it).

//Edit

Crap, noticed one of the tracks did overflow the tone bank.
Proper rerip uploaded, correct BGM07.SSF CRC32: E1BF4CC1
Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 01/06/09 08:57 PM

Nifty. Treasure Strike was crappy as advertised, but more rips is more rips. I'll check out Conveni a bit later.
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 01/06/09 09:28 PM

Conveni is nice if you like muzak. 's to be expected given that it's a convenience store sim.
Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 01/08/09 12:27 AM

Heh. You weren't kidding about Conveni being quiet. Nice songs though. BGM09 sounds like it's threatening to break out into reggae before it just stops.
Posted By: Deunan Knute

Re: AO SDK release 1.4.6 available - 01/08/09 12:30 AM

I can't get that damned filter to work.
I've been trying to match the output of kingshriek's script to what (I think) I should be getting and it doesn't correspond.

Given f=1.0 and different q values I end up with cutoff F at 9-15kHz. You'd think with f that high it should easily go up to 22kHz (and above). On the other hand, if I'm reading the figure right, I should expect F as low as 4Hz for f=0.25 and about 50Hz for f=0.5

The Q has range of -3 to 20.25dB:
Q [dB] = 0.75 * (reg_val - 3)
where reg_val is 0 to 31.

Is there a clever way to figure out the filter equation given some points with f and resulting cutoff F known? Assuming Q is neutral, that is 0dB.
Posted By: Deunan Knute

Re: AO SDK release 1.4.6 available - 01/08/09 11:12 AM

Q is 0.75 * (reg_val - 4). Or, 0.75 * reg_val - 3. It's quite funny how I used bold on the part I made mistake in, and can't even edit it now smile

Anyway, BIOS uses filtering as well - not to mention envelopes. Shenmue music seems to prefer single values (infinite time between FEG points). The problem is that if I move the cutoff point (for a given filter value) lower it makes Shenmue sound better - but also breaks BIOS sounds. And vice versa. The only immediate difference that I see is that on the most broken sound effects BIOS uses Q (register) value of zero.

I'm beginning to wonder if the filter equation proposed by Corlett is indeed correct - hence the question, how do I come up with something like that given the cutoff vs filter value curve. Q unknown but assumed to be 0dB.
Posted By: kingshriek

Re: AO SDK release 1.4.6 available - 01/09/09 01:57 AM

Given f (derived from the filter value) and q (given), you need to solve the following equation to get the cutoff frequency:

abs(H(f, q, w)) = -3.0 dB

where H is the filter transfer function and w is the normalized digital frequency (with 1.0 corresponding to the Nyquist frequency of 22050 Hz). In other words, the cutoff frequency will be 22050 * w.

For this particular filter, the transfer function is:

H(f, q, w) = f / (1 - (1 - f + q)*z + q*z*z)

where z is the point on the unit circle in the complex plane at angle -pi*w:

z = exp(-j*pi*w)

Quick python script to do the above:

Code:
from cmath import *
from bisect import bisect
import sys

def transfer_function(f, q, w):
	zi = exp(-1.0j*pi*w)
	return f / (1.0 - (1.0 - f + q)*zi + q*zi*zi)

def bisection(func, x0, x1, TOL=1.0e-6):
	while abs(x1 - x0) > 2*TOL:
		x2 = (x0 + x1) / 2.0
		if func(x0) * func(x2) > 0:
			x0 = x2
		else:
			x1 = x2
	return (x0 + x1) / 2.0
	
def calculate_f(filtervalue):
	return ((((filtervalue & 0xFF) | 0x100) << 4) >> ((filtervalue>>8)^0x1F))/8192.0

def lpfcutoff(filtervalue, q):
	f = calculate_f(filtervalue)
	func = lambda w: 20.0*log10(abs(transfer_function(f, q, w))).real + 3.0
	return 22050.0*bisection(func, 0.0, 1.0) 

if __name__ == '__main__':
	argv = sys.argv
	argc = len(argv)
	
	if argc == 1:
		sys.stdout.write('Usage: python %s <filtervalue> [<q>]\n' % argv[0])
		sys.exit(0)
	
	if argv[1][:2].lower() == '0x':
		filtervalue = int(argv[1], 16)
	else:
		filtervalue = int(argv[1])
	
	if argc == 2:
		q = 0.0
	else:
		q = float(sys.argv[2])
	
	sys.stdout.write('%f\n' % lpfcutoff(filtervalue, q))

Posted By: Deunan Knute

Re: AO SDK release 1.4.6 available - 01/09/09 09:58 AM

Still, this is just another brute-force method smile
Don't get me wrong, I know that IIR filter design is not exactly elementary school math. I just hoped there would be a way to figure out the whole thing - without having to try out one conversion equation after another...

I've already modified the previous script to generate f to cutoff frequency table, it's way off from that in AICA docs. So it seems that at least we can't use the filter value directly as the f coefficient (I've tried this too by the way).
This script is more accurate because I was to lazy to actualy solve the transfer function, rather I just made the loop do 1000 points and waited for it to dive below -3dB.

That does not address the main issue I have now - is the filter itself correct or not. This is what little I understand:

Basic 1-pole filter:
out = f * in - (1 - f) * prev_out

Basic 1-pole filter with negative feedback:
out = f * in - (1 - f) * prev_out - q * prev_out

In the end q * (prev_out - prev_prev_out) is just a slightly more convoluted way of introducing feedback - or am I wrong? This feedback will cause resonance, though (if I get this right) q in AICA can also have negative values, causing a dip first - very dangerous with f close to 1 as it will tend to amplify and overload.

The problem is I never found anyone doing actual filtering with this kind of feedback - though I've stumbled upon statement that resonance is not really used much except in synthesiers (which AICA is).
I'm going to run more tests on Dreamcast this weekend. Perhaps FEG is much more closely tied to AEG than I initially thought... With my luck it's going to turn out this is not a filter problem at all, but something entierly else - just like it was with the DSP smile
Posted By: Vas Crabb

Re: AO SDK release 1.4.6 available - 01/09/09 11:39 AM

/me goes into signal processing lecturer mode:

All IIR filters introduce feedback - after all, that's the way they generate an infinite impulse response (hence the name). The output from an IIR filter is only bounded for a subset of possible inputs - it is possible to give input that will cause an IIR filter to go into self-sustaining oscillations.

That's why FIR filters are much more common in control systems. Unconditional stability is a big plus. FIR filters also have linear phase response. However, the transport delays introduced by an FIR filter can be problematic, too. FIR filters are easy to design, too - just do an inverse Fourier transform of the impulse response to get the frequency response, and vice versa.

Why use an IIR filter? An IIR filter with a given number of taps can be made to have much steeper roll-off than an FIR filter with the same number of taps. An IIR filter can be made to have lower transport delay, which could make or break a controller. Finally, if you really do want to produce oscillations under certain conditions, an FIR filter will never do that for you.

If you want to play with digital filter design a bit, you can download DFDP (an old Fortran program that runs under DOS). The next step up would be to use MATLAB Simulink's linear system analysis features to play around. If you're more serious about learning digital control system theory, the text you can't go past is Katsuhiko Ogata's Discrete-Time Control Systems (2nd Edition).
Posted By: Deunan Knute

Re: AO SDK release 1.4.6 available - 01/09/09 02:39 PM

Words "MATLAB" and "Simulink" scare me. See, back at Uni they've managed to convince me that I in fact do not like math. Or know it, for that matter smile

I have just enough knowledge to understand what "zi = exp(-1.0j*pi*w)" does in kingshriek's script and why, or how to build my own function to compute frequency cutoff for a given FIR/IIR filter. But that's it.
There is always a chance I will figure this out, probably by sheer luck trying every possible filter equation I can come up with, but that will take massive amounts of time and work.

I'm hoping someone with more experience in that matter could, with little effort, just pull something nice out of his/her magic hat smile
Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 01/09/09 03:15 PM

Maybe run a program on hardware that lets you control the filter values. Then feed the audio output into the PC and show the frequency spectrum? I'm not great with math either smile
Posted By: blargg

Re: AO SDK release 1.4.6 available - 01/09/09 08:13 PM

Originally Posted By Vas Crabb
it is possible to give input that will cause an IIR filter to go into self-sustaining oscillations.

How could a stable IIR filter go into oscillation? And if it's unstable, I'd think most inputs would drive it into oscillation (but I haven't done much with IIR filters myself).
Quote:
That's why FIR filters are much more common in control systems. Unconditional stability is a big plus. FIR filters also have linear phase response. However, the transport delays introduced by an FIR filter can be problematic, too.

FIR filters can also have non-linear phase response. A minimum-phase FIR filter has most of the energy at the beginning, just like an IIR filter. I'm assuming this is what you mean by "transport delay".
Quote:
Why use an IIR filter? An IIR filter with a given number of taps can be made to have much steeper roll-off than an FIR filter with the same number of taps.

This is about the only reason, efficiency. Otherwise, a (much higher order) FIR can virtually match response, since one can always take the impulse response of the IIR, window it, and make an FIR out of that.
Posted By: Vas Crabb

Re: AO SDK release 1.4.6 available - 01/09/09 09:28 PM

Originally Posted By blargg
How could a stable IIR filter go into oscillation? And if it's unstable, I'd think most inputs would drive it into oscillation (but I haven't done much with IIR filters myself).

Well the issue is that a "stable" IIR filter is only stable for a subset of possible input conditions. Now you may design the system in such a way that it will never give the IIR filter an input that will cause it to oscillate, or you can design it so that non-ideal characteristics such as saturation will come in to play before it oscillates. But irrespective of that, it's still a design condition to think about.

Originally Posted By blargg
FIR filters can also have non-linear phase response. A minimum-phase FIR filter has most of the energy at the beginning, just like an IIR filter. I'm assuming this is what you mean by "transport delay".

The first filter will still have linear phase response. It has lower transport delay than the second one, but the transport delay is still constant across all frequencies. Since the phase response p = 2*pi*ƒ*T/ƒs (ƒ = input frequency, T = tap number with maximum amplitude, ƒs = sample frequency) for an FIR filter, you can't end up with anything but a linear phase response for an FIR filter - it's a simple linear equation with no tricks to pull.

(BTW - a transport delay in control systems is anything that has a transfer function anything like e^(-a*s) in s domain.)
Posted By: Deunan Knute

Re: AO SDK release 1.4.6 available - 01/10/09 08:19 PM

One would think there are tons of simple FIR/IIR design aids out there... not so. I mean sure, there are all kinds of *labs, octaves and whatnot, some of them free, but I don't need a full-blown higher math computation tool (and most definitely I don't want to learn how to use them first).

All I need is something that will eat a0-a2,b0-b2 and spit out a nice magnitude vs frequency plot. Possibly with an option to switch to log scaling on f axis. Native Windows GUI please.
Since this task requires complex numbers and I'm too lazy to code a GUI with pure Win32 (no RAD on my home PC), I figured I could modify kingshriek's script to output the data for gnuplot. Of course no python on Windows box either, so I'm using a nearby Linux for all the work. I realized I don't have gnuplot on my FC8 so I did "yum install gnuplot" - and yum asked me if I would like additional 67 packages with it, just above 35MB. Err... no, thanks.

Anyway - I've run some tests. Neill's filter is indeed a low-pass IIR but I still think it's not the correct one. The function that converts filter value to f coefficient is wrong. I'm having a hard time coming up with something that would both work and not requite floating point math functions...
Q values other than zero do create a resonance but not like AICA does it. The biggest difference it that AICA creates resonance a bit before f0, so cutoff point is basically unaffected. Neill's filter has the gain peak all over f0 and ends up with a different curve altogether.

The figures in SEGA docs are (for once) pretty much what I got from frequency spectrum analysis. The FEG timing is wrong though, or so I belive - it's basically the same table as AEG decay/release but multiplied by 4. There's even an obvious copy-paste bug that messes up the last part completely. FEG counter is not only wider than AEG, it also goes all the way up to all ones, whereas AEG ends at 960.

Eh, in short: nothing working yet.
Posted By: Vas Crabb

Re: AO SDK release 1.4.6 available - 01/10/09 09:28 PM

Seriously, the simplest thing for that is MATLAB Simulink. You just draw the filter by dragging and dropping the gain, summing and delay blocks onto the workspace and drawing lines between them, and it gives you the time-domain and frequency domain responses of the system. It's the tool of choice in the industry.
Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 01/10/09 09:53 PM

What kinda ghetto are you in that 35 MB of packages is a problem? I've seen Windows Update pull down more than that on a good day smile
Posted By: Richard Bannister

Re: AO SDK release 1.4.6 available - 01/10/09 10:59 PM

Quite, even lowly Ireland has 20Mbit connections now.

Posted By: Deunan Knute

Re: AO SDK release 1.4.6 available - 01/10/09 11:23 PM

You people don't get it, do you smile

Vas: Let me explain this again. I got an IIR low-pass filter inside AICA, aka Black Box. It uses two values as parametres for variable cutoff.
Even if I now have some figures as to how the magnitude vs frequency curve should look like, I still don't know how to construct the filter itself. It's only a guess that it's 2nd order filter - and if it is there are 6 internal coefficients that can be anything, really.
I need to figure out how the 2 parameters make those 6 coefficients. I can do that only by trying various combinations, not exactly very scientific method. With a design tool I could probably create a filter but it will only have one, set cutoff value. Still no clue how to make it variable with two parameters. Given a set of such filters I could possibly figure out what it is they have in common and focus on that. But that is simply too much work.

As explained before - someone who actually gets this stuff would probably know which coefficient to poke, just by looking at the curve. I just see that it doesn't match what I need, so now I can add something. Anything. Or substract. To any of the 6 variables. Good luck with that.

RB: Okay, this is in Polish but you will get the idea:
Code:
Rozwi&#261;zano zale&#380;no&#347;ci

================================================================================
 Pakiet                      Architektura
                                      Wersja             Repozytorium     Rozmiar
================================================================================
Instalowanie:
 gnuplot                     i386     4.2.2-1.fc8        updates-newkey   2.0 M
Instalowanie, aby rozwi&#261;za&#263; zale&#380;no&#347;ci:
 ConsoleKit                  i386     0.2.3-3.fc8.1      updates-newkey    55 k
 GConf2                      i386     2.20.1-1.fc8       fedora           1.6 M
 ORBit2                      i386     2.14.10-2.fc8      fedora           187 k
 PolicyKit                   i386     0.6-2.fc8          updates-newkey    76 k
 PolicyKit-gnome             i386     0.6-1.fc8          fedora            34 k
 SDL                         i386     1.2.13-2.fc8       updates-newkey   222 k
 alsa-lib                    i386     1.0.16-3.fc8       updates-newkey   402 k
 atk                         i386     1.20.0-1.fc8       fedora           212 k
 audiofile                   i386     1:0.2.6-7.fc8      fedora           107 k
 avahi                       i386     0.6.21-8.fc8       updates-newkey   237 k
 avahi-glib                  i386     0.6.21-8.fc8       updates-newkey    17 k
 bluecurve-icon-theme        noarch   8.0.0-1.fc8        fedora           5.1 M
 cdparanoia-libs             i386     alpha9.8-27.2      fedora            50 k
 control-center-filesystem   i386     1:2.20.3-3.fc8     updates-newkey    34 k
 dmidecode                   i386     1:2.7-1.26.1.fc6   fedora            61 k
 esound-libs                 i386     1:0.2.38-6.fc8     fedora            73 k
 fedora-gnome-theme          noarch   8.0.0-2.fc8        updates-newkey    10 k
 fedora-icon-theme           noarch   1.0.0-1.fc8        fedora           115 k
 gail                        i386     1.20.2-1.fc8       updates-newkey   290 k
 gnome-keyring               i386     2.20.3-1.fc8       updates-newkey   210 k
 gnome-mime-data             noarch   2.18.0-2.fc7       fedora           724 k
 gnome-mount                 i386     0.7-1.fc8          fedora           126 k
 gnome-themes                noarch   2.20.2-1.fc8       updates-newkey   2.5 M
 gnome-vfs2                  i386     2.20.1-1.fc8       updates-newkey   1.1 M
 gstreamer                   i386     0.10.15-1.fc8      updates-newkey   689 k
 gstreamer-plugins-base      i386     0.10.15-4.fc8      updates-newkey   879 k
 gstreamer-tools             i386     0.10.15-1.fc8      updates-newkey    18 k
 gtk-nodoka-engine           i386     0.6.2-1.fc8        updates-newkey    47 k
 gtk2                        i386     2.12.8-2.fc8       updates-newkey   6.8 M
 gtk2-engines                i386     2.12.2-1.fc8       fedora           393 k
 hal                         i386     0.5.10-5.fc8       updates-newkey   461 k
 hal-info                    noarch   20080607-2.fc8     updates-newkey   118 k
 hal-libs                    i386     0.5.10-5.fc8       updates-newkey    61 k
 hicolor-icon-theme          noarch   0.10-2             fedora            32 k
 libIDL                      i386     0.8.9-1.fc8        fedora            87 k
 libXcomposite               i386     0.4.0-3.fc8        fedora            14 k
 libXcursor                  i386     1.1.9-1.fc8        fedora            29 k
 libXinerama                 i386     1.0.2-3.fc8        fedora            12 k
 libXrandr                   i386     1.2.2-1.fc8        fedora            21 k
 libXres                     i386     1.0.3-3.fc8        fedora            13 k
 libXv                       i386     1.0.3-3.fc8        fedora            19 k
 libart_lgpl                 i386     2.3.19-3.fc8       fedora            77 k
 libbonobo                   i386     2.20.3-1.fc8       updates-newkey   469 k
 libbonoboui                 i386     2.20.0-1.fc8       fedora           352 k
 libglade2                   i386     2.6.2-4.fc8        updates-newkey    64 k
 libgnome                    i386     2.20.1-2.fc8       fedora           966 k
 libgnomecanvas              i386     2.20.1-3.fc8       updates-newkey   228 k
 libgnomeui                  i386     2.20.1.1-1.fc8     fedora           1.0 M
 libnotify                   i386     0.4.4-8.fc8        fedora            33 k
 libogg                      i386     2:1.1.3-5.fc8      fedora            19 k
 liboil                      i386     0.3.12-11.fc8      fedora           158 k
 libsmbios-bin               i386     0.13.13-1.fc8      updates-newkey    58 k
 libsmbios-libs              i386     0.13.13-1.fc8      updates-newkey   237 k
 libtheora                   i386     1.0beta2-3.fc8     updates-newkey   138 k
 libvisual                   i386     0.4.0-4.fc8        fedora           150 k
 libvorbis                   i386     1:1.2.0-2.fc8      updates-newkey   192 k
 libwnck                     i386     2.20.3-1.fc8       updates-newkey   322 k
 libxslt                     i386     1.1.24-2.fc8       updates-newkey   526 k
 metacity                    i386     2.20.2-1.fc8       updates-newkey   2.2 M
 nodoka-metacity-theme       noarch   0.3.2-2.fc8        fedora           7.8 k
 notification-daemon         i386     0.3.7-6.fc8        fedora            48 k
 pm-utils                    i386     0.99.4-19.fc8      updates-newkey    44 k
 shared-mime-info            i386     0.23-2.fc8         updates-newkey   166 k
 startup-notification        i386     0.9-3.fc8          fedora            38 k
 wxBase                      i386     2.8.9-1.fc8        updates-newkey   688 k
 wxGTK                       i386     2.8.9-1.fc8        updates-newkey   3.9 M

Podsumowanie transakcji
================================================================================
Instalowanie      67 pakietów     
Aktualizowanie     0 pakietów     
Usuwanie           0 pakietów     

Ca&#322;kowity rozmiar pobierania: 37 M


It's not about 35MB. It's about the 67 packages I don't need or have even heard of.
This is beyond sloppy. I mean c'mon - SDL? gtk2? Why not the whole KDE when at it?! What is the point of creating separate packages in the first place then?
This is just like the install process on the new distros - you can select "only the things you need" - to conserve disk space. Right. Pick one wrong program and the whole DVD will get installed anyway, as dependencies. It's like chain reaction. Linux sworn people laughing at Vista's size should really do du -hs on their /usr sometime.

I simply refuse to bloat my precious headless system. I'm pretty sure I would have to install much less devel libs when trying to compile gnuplot from sources (most of those I probably already have). And even then I'd never need any pm-utils. Sheesh.
Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 01/10/09 11:30 PM

Oh, yeah, that's a famous bug in FC8. gnuplot doesn't actually depend on all that stuff and they've fixed it since. FC8's end-of-lifed though so it's not gonna benefit. (Olivier bitches them out regularly when they do stuff that makes his large lab suck).

Also, I'm the guy who defends Vista on MAMEWorld, home of the Win98 holdout ;-)

ETA: you might try just getting the RPM itself and installing it with --nodeps.
Posted By: Vas Crabb

Re: AO SDK release 1.4.6 available - 01/10/09 11:54 PM

If you just want to design a filter given certain parameters, download DFDP and run it in DOSBox. It asks you for filter parameters and makes your filter coefficients for you. It also plots the response.
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 01/12/09 01:05 AM

Here's a little something for today:

Ogre Battle: The March of the Black Queen (1996)(Quest, Riverhillsoft)

http://2sf.hcs64.com/rip/Ogre%20Battle%20-%20The%20March%20of%20the%20Black%20Queen%20%5bDensetsu%20no%20Ogre%20Battle%5d%20(1996)(Quest,%20Riverhillsoft).zip

Only 9 tracks (rest is CDDA, which I can upload somewhere if anyone wants) but very nice tracks (I'd say they're better than the SNES originals, and that's saying something).
Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 01/12/09 01:13 AM

Very nice tracks!
Posted By: Deunan Knute

Re: AO SDK release 1.4.6 available - 01/12/09 03:44 PM

Now I'm starting to understand this. See, all it took was a simple tutorial here:
http://www.bores.com/courses/intro/iir/5_poles.htm
and a nice Windows application here:
http://www.winfilter.20m.com/ (beware banners)

For a 2nd order type 1 Chebyshev filer we conveniently get 2 zeros at -1;0i and two poles symmetrical to Re axis. Meaning we can pretty much focus on just a half of the Zero-Pole diagram.
This gets simple now - when you move the pole around it's projection on the Re axis will be the point where frequency response starts to drop. The closer the pole gets to the unity circle (that is, the absolute value of the complex number approaches one) the bigger the resonance at this point. Of course near 0 and Fmax you end up being almost on the circle anyway, so nothing changes much (frequency wise, phase response is different).

This is no longer a problem of getting 2 variables to fit into 6, but rather into 2 coordinates. And we also get to know some rules of how this is supposed to happen. Much better I'd say. Too bad this is just as useful as Winfilter gets - you can't move the poles freely around (with a mouse for example) and it doesn't show the coefficients unless a project is created. It's doesn't accept negative ripple either so I can't test if this will cause the response to drop even faster - but it should, I mean if the poles don't reach up to 0dB then the projected slope has to look like this?

BTW, leave it to English speakers to come up with a transcription of simple slavic name to something I need to look up every time to make sure I got it right smile
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 01/20/09 10:18 PM

Managed to find another mostly sequenced Saturn game:

Sotsugyou II - Neo Generation (1995)(Crosstalk, Riverhillsoft):

http://2sf.hcs64.com/rip/Sotsugyou%20II%20-%20Neo%20Generation%20(1995)(Crosstalk,%20Riverhillsoft).zip

Misses about 6 songs (sung songs, I mean). Custom 16-bit 22kHz PCM format, so would make the pack a bit larger, and they aren't anything special anyway.
Anyone wants'em though, just ask.
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 01/21/09 10:58 PM

And another one done:

Kidou Senshi Z Gundam - Zenpen Zeta no Kodou (1997)(Bandai)

http://2sf.hcs64.com/rip/Kidou%20Senshi%20Z%20Gundam%20-%20Zenpen%20Zeta%20no%20Kodou%20(1997)(Bandai).zip

1942 Saturn port rip should be good for laughs, maybe tomorrow. smile
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 01/24/09 08:03 AM

3 new DSF rips for today (yea, the folder's emptish ATM, will get full (or even fullier) again soon).

Bikkuriman 2000 Viva! Festiva! (2000)(Sega Toys)
Digital Keiba Shinbun - My Trackman (1999)(Shouei System)
Maken X (1999)(Atlus) <-- raises a few flags here, has 10 or so tracks less than the OST, also uses sample bank #3, couldn't find anything to populate #0-2. No missing instruments that I could spot though, maybe first three banks are for SFX only...

http://dsf.hcs64.com

Also that 1942 SSF rip I've mentione earlier. Funnies thing is it's not even used (game has ADPCM recorded from the arcade cab).
Like I've said, good for laughs:

Capcom Generation - Dai 1 Shuu Gekitsuiou no Jidai (1998)(Capcom)

http://2sf.hcs64.com/rip/Capcom%20Generation%20-%20Dai%201%20Shuu%20Gekitsuiou%20no%20Jidai%20(1998)(Capcom).zip
Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 01/24/09 05:12 PM

Nice rips, and yeah, the 1942 one is hilarious.
Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 02/02/09 01:14 AM

Looks like new GD-ROM dumps soon, so hopefully more DSF rips as well smile
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 02/03/09 11:42 PM

Speak of the devil:

http://dsf.hcs64.com/

Nobunaga's Ambition - Reppuuden (1999)(Koei)
Pro Mahjong Kiwame D (2000)(Athena)

I must say that both games have very nice scores.

Also, since I recall RB being kind of pissed with not being told about HES+ADPCM, I'd just like to mention that a recent NEZPlug++ build added VBlank+Timer mode for GBS files, needed by some newer rips (that were only possible with GBR format previously).
More info here: http://www.angelfire.com/nc/ugetab/nezplug.html (scroll to the bottom of the page).

Oh, and while we're on the GBS topic, here's my updated collection: http://2sf.hcs64.com/gbs/ (!Game Boy Music.rar has everything in one archive for easy leeching). Everything nicely organized, Game Boy Color rips marked, alternative region names and developer/porter info where applicable. Should have everything, including latest ugetab rips.
Posted By: exolon2

Re: AO SDK release 1.4.6 available - 02/04/09 03:03 AM

The Nobunaga's Ambition soundtrack is lovely indeed (did Yoko Kanno do this one? I have some nice real orchestral mp3s of one of the series). Haven't listened to the other one yet. Nice rip!
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 02/04/09 03:26 PM

Couldn't find any info on the game (except for japanese Wikipedia, which I can't really read, but which doesn't feature her name). But I'm guessing not, Yoko Kanno stopped writing music for Koei at around Uncharted Waters 2.

//Edit

Managed to find another Dreamcast game that uses Soul Reaver sequence driver (Silver: http://www.vgrebirth.org/games/game.asp?id=1100).

Most of music data uses standard Sega files (FOB, FPB, MPB), while sequences are stored as standard General MIDI files, everything in .KAT containers.
Posted By: Kaminari

Re: AO SDK release 1.4.6 available - 02/05/09 05:18 PM

The last Nobunaga soundtrack by Kanno was episode 6 (Tenshouki). For info, Reppuuden is episode 8.

She left Koei the same year she worked on Macross Plus, and mostly stopped composing for games (except a recent Sangokushi IIRC).
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 02/05/09 05:30 PM

She did some music for a Dreamcast game actually, Napple Tale - Arsia in Daydream (2000)(Chime, Sega)

Fully streamed though.
Posted By: exolon2

Re: AO SDK release 1.4.6 available - 02/05/09 10:16 PM

Good info, thanks guys.
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 02/07/09 12:54 AM

Two new rips for tonight:

Sonic Shuffle (2000)(Hudson Soft, Sega)
Advanced Daisenryaku 2001 (2001)(System Soft, Sega)

http://dsf.hcs64.com/
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 02/07/09 12:44 PM

Five new ones today:

Golem no Maigo (2000)(Caramelpot)
Magic - The Gathering (2001)(Alfa System, Sega)
Pachinko no Dendou CR Nanashii (2001)(Microcabin)
Puyo Puyo Da! featuring Ellena System (1999)(Compile)
Rent A Hero No. 1 (2000)(Aspect, Sega) <-- might be missing some tracks, lots of MSB files without a matching MPB. More tracks than the OST anyway

http://dsf.hcs64.com/
Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 02/07/09 04:34 PM

Love the homages to classic Sega games in Rent-a-Hero (even if Sega always uses the same sections of the same songs when referencing those games). I'd love to hear a full version of the AfterBurner song done with this arrangement.
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 02/08/09 12:23 AM

One more to match the recent DSF one:

Pro Mahjong Kiwame S (1996)(Athena)

http://2sf.hcs64.com/rip/Pro%20Mahjong%20Kiwame%20S%20(1996)(Athena).zip
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 02/14/09 02:20 PM

Some new SSF rips, more to come:

Angelique Special (1996)(Koei)
Minnesota Fats - Pool Legend [Side Pocket 2 - Densetsu no Hustler] (1995)(Data East)
Nobunaga's Ambition - Tenshouki with Power Up Kit (1997)(Koei)

Tenshouki was scored by Yoko Kanno, Side Pocket 2 continues the good jazzy tradition set by the first game.

http://2sf.hcs64.com/rip/

Also, uhh, http://dsf.hcs64.com
Just sayin'...
Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 02/14/09 02:45 PM

Awesome.
Posted By: R. Belmont

Re: AO SDK release 1.4.6 available - 02/15/09 02:04 AM

Alright, I got off my butt. Enjoy the jazzy T&E Soft stylings of Pebble Beach - The Great Shot (ST-V version) on my rip page.

The game's not running properly in MAME right now so I may not have gotten everything. Also, info on titles and/or composer(s) is welcome.

ETA: Also thrown in: the minimal music of Name Club Ver. 3 (an ST-V based photo-printer thingy) and the surprisingly credible sounding rave stylings of Steep Slope Sliders (ST-V version).
Posted By: Knurek

Re: AO SDK release 1.4.6 available - 02/15/09 09:16 AM

pblbeachb47.ssf crashes both in_aosdk and my build of Audio Overload

Saturn version of Steep Slope Slider has 2 more tunes, but then it's completely different CDDA music, so prolly nothing's missing from your pack (nice music on both versions though).

Two new rips for today:

Sangokushi Eiketsuden (1996)(Koei)
Sangokushi Koumeiden (1997)(Koei)

http://2sf.hcs64.com/rip/
Posted By: R. Belmont

Re: AO SDK release 1.4.8 available - 02/15/09 06:30 PM

Seems to be a rare bug in makessf.py - it's spitting out a zlib chunk that decompresses to 9 megs for those songs. I've put a workaround into the SDK (now 1.4.8) and hopefully anonymous plugin guy will update soon.
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 02/15/09 11:25 PM

Okay, since I'm an idiot, the folowing rips weren't using DSP at all (stupid Koei using more than one mixer)

Angelique Special (1996)(Koei)
Nobunaga's Ambition - Tenshouki with Power Up Kit (1997)(Koei)
Sangokushi Koumeiden (1997)(Koei)

Please redownload for 100% more reverb/echo.

Also, one new rip:

Romance of the Three Kingdoms 5 [Sangokushi V] (1996)(Koei)

http://2sf.hcs64.com/rip/
Posted By: R. Belmont

Re: AO SDK release 1.4.8 available - 02/16/09 01:02 AM

Those sound *much* better with DSP smile
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 02/16/09 06:12 AM

New aosdk plugin suite version. Well, versions to be precise. The + one has some changes to scsp.c, anything good there?
Posted By: R. Belmont

Re: AO SDK release 1.4.8 available - 02/16/09 06:36 AM

Where's the site for that stuff again? It's nearly impossible to find relevant references with Google smile
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 02/16/09 03:38 PM

http://foobar2000.xrea.jp/up/
Posted By: R. Belmont

Re: AO SDK release 1.4.8 available - 02/16/09 04:25 PM

The changes in the Plus version are legit - he hooked up LFORE (reset phase of ALFO and PLFO on key-on) and SDIR (disable effects of envelope, LFO, and TL register). No idea which song(s) those would affect though - I added printfs for those things and ran through a bunch of SSFs and they never went off.

Also, I guess the question becomes "how do I credit this when I add these changes to MAME"? =)
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 02/16/09 10:26 PM

I take it 'anonymous plugin guy' won't work. smile

New SSF rips by me:

Angelique Special 2 (1997)(Koei)
Masters Harukanaru Augusta 3 (1995)(T&E)
Nobunaga's Ambition - Sengoku Gunyuuden (1998)(Koei)

and one by ANUSFEST:

Album Club (Mune Kyun) ~Saint Paulia Jogakouin~ (1997)(Societa Daikanyama) <-- really creepy game, with the cover that wouldn't feel out of place at 'To Catch a Predator'

http://2sf.hcs64.com/rip/

More T&E, more Koei...
Oh, and speaking of Koei:

Genghis Khan II - Clan of the Gray Wolf [Aoki Ookami to Shiroki Mejika - Genchou Hishi] (1998)(Koei)
http://www.sendspace.com/file/lcbl8a

Since it's not yet up on the PSF mirror.
Almost on par with Racing Lagoon in the 'wth, this isn't streamed?' factor.
Posted By: R. Belmont

Re: AO SDK release 1.4.8 available - 02/16/09 11:25 PM

ANUSFEST? Do some of these (Japanese?) guys understand what they're calling themselves? smile

Anyway, Genghis Khan II sounds quite amazing for a sequenced PS1 game.
Posted By: nZero

Re: AO SDK release 1.4.8 available - 02/16/09 11:56 PM

Any idea if the NAOMI and/or DC versions of Shikigami no Shiro 2 are sequenced? Somewhat different to the other versions and the original soundtrack disc, makes me wonder.
Posted By: R. Belmont

Re: AO SDK release 1.4.8 available - 02/17/09 12:06 AM

If it's Naomi and not GD-ROM it's almost certainly sequenced.
Posted By: exolon2

Re: AO SDK release 1.4.8 available - 02/17/09 12:29 AM

Originally Posted By Knurek
and one by ANUSFEST:

Uh... ANUSFEST? Sounds like a week-long gay orgy party with techno music and flashing lights eek
Posted By: Deunan Knute

Re: AO SDK release 1.4.8 available - 02/17/09 12:45 AM

I'm bit too busy/tired/lazy to go through AO sources but those SCSP changes might affect AICA as well.

First, there is an undocumented bit (Neill calls it "voff") that does the same as SDIR. That is: LP, AEG and ALFO will not affect channel volume - but everything still gets computed. That means no matter if voff is on, if AEG goes (or is set) past ATTACK and the counter reaches 960 it will cause the channel to stop.
That is bit 6 of register 0x28. Incidentally bit 5 in that register will turn off lowpass filter (aka all-pass, again it is still being computed anyway).

Now, this is for amplitude side of things. I don't know if "voff" affects PLFO as well - right now I assume it doesn't but I guess this should be verified one of these days...
PLFO (the resulting frequency shift) is somewhat tricky anyway.

Second, Neill was very specific in his explanation of LFORE:
If set, the LFO phase is reset at the start of EACH SAMPLE LOOP.
And so this is exactly what I'm doing. I assume the big letters mean he checked it himself and is sure of it, so I didn't bother doing it myself.
This is how AICA does it and since the FQ8005 doc doesn't say it was changed, I'm willing to bet that SCSP operates in the same manner.
Posted By: R. Belmont

Re: AO SDK release 1.4.8 available - 02/17/09 12:59 AM

Thanks for the tips. Let me know if you check any more of this stuff on real h/w.
Posted By: Deunan Knute

Re: AO SDK release 1.4.8 available - 02/17/09 08:53 AM

Small errata: voff affects TL, AEG and ALFO - and not LP. Somehow I confused the names smile

"lpoff" (low pass disable bit) I'm sure of. As for "voff" and PLFO - I'll run a quick test later today. It should show up on FFT.
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 02/17/09 03:33 PM

Originally Posted By nZero
Any idea if the NAOMI and/or DC versions of Shikigami no Shiro 2 are sequenced? Somewhat different to the other versions and the original soundtrack disc, makes me wonder.


I think I've looked at it, same CRC as the current DSF rip IIRC.

//Edit

Oh, wait, you're asking about both Naomi and DC?
DC one was ripped a while ago, I'm currently in the process of uploading all my Dreamcast stuff to dsf.hcs64.com, so it should be there soon.
Posted By: nZero

Re: AO SDK release 1.4.8 available - 02/17/09 03:49 PM

Oh! Didn't know it had been ripped yet, cheers smile
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 02/17/09 09:45 PM

I know some people might've been waiting for this one:

Dragon Force (1996)(Sega AM7)(Sega): http://2sf.hcs64.com/rip/Dragon%20Force%20(1996)(Sega%20AM7)(Sega).zip

One of the instruments used in the game sounds kinda weird (try 21_00_00.ssf for instance). Don't have htcore.exe anymore to compare, but doesn't sound like it's inteded.

Also, many tracks are sequence dupes with tone bank switched (subsongs #1 and up, it seems). As they sound different for each ssflib, I didn't remove them. Not having played the game I can't tell if they are supposed to sound this way or if it's just a quirky way the sequences were made.
Posted By: Deunan Knute

Re: AO SDK release 1.4.8 available - 02/17/09 11:04 PM

Research complete smile

PLFO is not affected by voff bit (and neither by lpoff nor the still unknown bit 7, no surprise there).

LFORE = 0:
LFOs are not reset on key-on or sample loop start/end. The starting position (and by that I mean the shape's phase) seems to be random, it is possible that the counter is running even if the channel is not playing anyting.

LFORE = 1:
LFOs aren't working at all... quite puzzling. It looks like the period counter is forced to zero and not advancing. This does not affect the noise mode however, because period is then ignored (noise works at sampling frequency).
In other words, LFORE seems to act like a disable bit. Well, the doc says it "puts the LFO in the reset state"...

Maybe I'm doing something wrong, but quite frankly there's not much room for error when all you have to do is toggle one bit. I'm going to leave this as is for now - maybe I'll figure something out later.
BTW, as far as I can tell both LFOs share one common phase counter (though keep in mind ALFO can only add to attenuation while PLFO shifts frequency both up and down so it's zero point is shifted).
Posted By: R. Belmont

Re: AO SDK release 1.4.8 available - 02/17/09 11:08 PM

Very interesting, thanks for doing the research smile
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 02/18/09 07:44 PM

New SSF rips:

Dragon Force II - Kamisarishi Daichi ni (1998)(Chime)(Sega)
Riglordsaga 2 (1996)(Microcabin)(Sega)
Vandal Hearts [Vandal Hearts - Ushinawareta Kodai Bunmei] (1997)(KCE Tokyo)(KCE Nagoya)(Konami)
With You - Mitsumete Itai (1999)(Cocktail, Stack)(NEC Interchannel)

All pretty much great (Dragon Force 2 scored by Hayato Matsuo, and Vandal Hearts is the usual Konami greatness.

http://2sf.hcs64.com/rip

Also, RB, just making sure... Did you by chance skip the Dragon Force 1 bug I mentioned at the end of the previous page?
Posted By: R. Belmont

Re: AO SDK release 1.4.8 available - 02/19/09 04:35 AM

What am I supposed to be hearing wrong in 21_00_00.ssf from Dragon Force? Besides that I've heard the sample CD all the instruments are from and it's distracting, that is? (And I would've thrown in more DSP reverb if I were the composer).
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 02/19/09 06:04 AM

One of the samples is a bit too much clicky for my tastes, I take it it just's supposed to sound this way? Kind of grating if so...
Posted By: kingshriek

Re: AO SDK release 1.4.8 available - 02/19/09 07:30 AM

It's probably high frequency distortion in the FM bass. I haven't had much luck improving it.

Posted By: belegdol

Re: AO SDK release 1.4.8 available - 02/19/09 09:41 AM

Hmm, is it just me or does AO die often when trying to load either of Dragon Force rips?
Posted By: R. Belmont

Re: AO SDK release 1.4.8 available - 02/19/09 01:19 PM

Like I said, sometimes makessf.py outputs a zlib block that decompresses to 9+ megs and the destination is 512k of SCSP RAM. And because of the address randomization thing modern kernels do that sort of bug is no longer a 100% thing (unless you run with Electric Fence or Valgrind). The latest SDK has a workaround.
Posted By: R. Belmont

Re: AO SDK release 1.4.8 available - 02/19/09 07:20 PM

Knurek: question about the giant DC upload. Most of them are either DSF or ADX rips as expected but some are MP3 or FLAC. Are those OSTs rather than actual game rips or what?
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 02/19/09 08:36 PM

Nope, CD-DA (well, GD-DA, but same deal).

Few games had an bonus OST included with the game (usually one or two tracks). Not sure how to treat those though, but not planning on having actual sold OSTs there (even if they've been out of print for a few years). There are other places for that.

//Edit

This took a bit longer than expected:

Idol Janshi Suchie-Pai II (1996)(Jaleco)
Yuukyuu Gensoukyoku Ensemble (1998)(Starlight Marry)(Media Works)

Suchie-Pai rip still isn't perfect, some songs just refuse to play. Not sure why, ssfinfo.py output looks perfectly okay for those.

Oh, and a nice new hub for all the new/uploading rips:

http://vgm.hcs64.com
Posted By: R. Belmont

Re: AO SDK release 1.4.8 available - 02/20/09 03:22 AM

Yuukyuu Gensoukyoku is really nice for a Saturn game - some great use of stereo, and the instruments sound pretty good considering the system's constraints.

ETA: I missed listening to it when it was posted, but Riglordsaga 2 merits a "holy !@#$%!!!@!". That's some very nice SCSP work. M36.SSF may be my new favorite VGM from any system.
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 02/20/09 05:19 AM

Well, pity the PSF version (Yukyu Gensokyoku 2nd Album) sounds better (too little reverb used IMO in the SSFs, dunno, there are 6 available mixers, so maybe I choose the wrong one, but tried the first 4 and didn't spot any difference in ssfinfo values).
Or maybe I was just too sleepy when I compared them earlier. Now that I listen to them, the PSF one has too much reverb smile

And yea, Riglordsaga is niiice. Would be much nicer if it had more sequenced stuff though, streamed formats with sampling rate below 32kHz are rather painful.
Posted By: R. Belmont

Re: AO SDK release 1.4.8 available - 02/20/09 03:21 PM

Yeah, the PSF definitely has higher sample rates on the instruments, but the reverb's a bit excessive. Somewhere between the SSF and PSF would've been nice smile
Posted By: kingshriek

Re: AO SDK release 1.4.8 available - 02/21/09 03:21 AM

The "nonworking" Suchie Pai II tracks are actually just fine.

Code:
python ssfinfo.py -s SQ_FY.minissf

==========================================================================================
Sequence Bank 1 - Track 0
------------------------------------------------------------------------------------------
Resolution : 480 steps/quarter-note
Tempo Event  0:   55680 steps,  625000 microseconds/quater-note 
Tempo Event  1:    5280 steps,  625000 microseconds/quater-note 
Tempo Event  2:   10080 steps,  652173 microseconds/quater-note 
Tempo Event  3:   70880 steps,  389610 microseconds/quater-note 
------------------------------------------------------------------------------------------
...
[0x0005C] 88              EXT_GATE          : gate=512
[0x0005D] 88              EXT_GATE          : gate=512
[0x0005E] 88              EXT_GATE          : gate=512
[0x0005F] 8F              EXT_DELTA         : delta=4096
[0x00060] 8E              EXT_DELTA         : delta=2048
[0x00061] 8D              EXT_DELTA         : delta=512
[0x00062] 8D              EXT_DELTA         : delta=512
[0x00063] 21 37 64 90 FF  NOTE              : channel=1 note=G(3) key=55 volume=100 gate=144 step=511
...


Adding up the step-times before the first note gives 4096+2048+512+512+511 = 7679 steps.

Converting to seconds:

7679 steps * .625 seconds/quarter-note / 480 steps/quarter-note = 10 seconds.

In other words, have some patience and wait 10 seconds. wink
Posted By: R. Belmont

Re: AO SDK release 1.4.8 available - 02/21/09 04:40 AM

There seems to be more to it than that - I just let SQ_FY play over a minute with no sound and no key-ons.
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 02/21/09 07:07 AM

Also, the Winamp plugin skips any song that has more than 3 seconds of silence at beginning.

//Edit

New SSF rips:

Mahjong Taikai II Special (1996)(Koei)(ASCII)
Pebble Beach Golf Links [Pebble Beach Golf Links - Stadler ni Chousen] (1995)(T&E)(Sega)
Yuushun Classic Road (1997)(Progress)(Victor)
Valora Valley Golf [Hyper Golf, The - Devil's Course] (1995)(T&E)(VIC Tokai)

http://ssf.hcs64.com/
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 02/21/09 06:04 PM

New SSF rips (STV this time :D)

Dark Legend [Suiko Enbu - Outlaws of the Lost Dynasty] (STV)(1995)(Data East)
Othello Shiyouyo (STV)(1998)(-)(Success)
Winter Heat (STV)(1997)(-)(Sega)

Dark Legend has that oldschool vs fighter vibe going on, very nice.
More STV to come.

http://ssf.hcs64.com
Posted By: R. Belmont

Re: AO SDK release 1.4.8 available - 02/21/09 06:11 PM

Nice. I tried to rip ST-V prikura but it's the infamous 2.04 driver and all the notes get keyed on with TL 0xff (which is zero volume effectively). We really gotta figure out why it behaves that way sometime smile

ETA: Othello Shiyouyo is remarkably listenable for an othello game. I was gonna rip it but you saved me the trouble.
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 02/21/09 06:17 PM

I've tried that Purikura game as well, thinking I could just rip the SEQ/TON from memory and make custom SSFs with a working driver...
But the map the game uses is a horror, with multiple Tone banks per song and other stuff like that (just thinking how to tackle it gave me a headache).
I guess I'd persevere if the track I managed to make didn't sound like utter crap. smile
Posted By: R. Belmont

Re: AO SDK release 1.4.8 available - 02/21/09 06:25 PM

Yeah. The best part is not all the banks in the map are marked "valid", it's pretty crazy.

Here's the map the game has loaded in case it helps putting stuff together from the pieces. Note that not all the slots are marked "valid".

Code:
TONE          Bank  0 : offset=0x0B000 size=0x12600 transferred=1 valid=1 crc32=0x12CBD449
DSP_PROGRAM   Bank  0 : offset=0x1D600 size=0x00540 transferred=1 valid=1 crc32=0x6823BA16
DSP_RAM       Bank  0 : offset=0x1E000 size=0x10040 transferred=0 valid=1
SEQUENCE      Bank  0 : offset=0x2E040 size=0x07638 transferred=1 valid=1 crc32=0x56CC177C
TONE          Bank  1 : offset=0x35678 size=0x1B4F0 transferred=1 valid=1 crc32=0x00000000
SEQUENCE      Bank  1 : offset=0x50B68 size=0x04A68 transferred=1 valid=1 crc32=0x39267599
TONE          Bank  2 : offset=0x555D0 size=0x0EB50 transferred=1 valid=1 crc32=0x74B9B6BD
SEQUENCE      Bank  2 : offset=0x64120 size=0x005E0 transferred=1 valid=1 crc32=0x6B485951
TONE          Bank  3 : offset=0x64700 size=0x0E884 transferred=0 valid=0
SEQUENCE      Bank  3 : offset=0x72F84 size=0x004B0 transferred=0 valid=0
TONE          Bank  4 : offset=0x73434 size=0x09F08 transferred=0 valid=0
SEQUENCE      Bank  4 : offset=0x7D33C size=0x00870 transferred=0 valid=0
TONE          Bank  5 : offset=0x7DBAC size=0x019A0 transferred=1 valid=1 crc32=0x19985A6B
SEQUENCE      Bank  5 : offset=0x7F54C size=0x00084 transferred=1 valid=1 crc32=0x00000000


Also, sequence 0/tone 0 are the music in most cases. Sequence 1/tone 1 is the sound f/x.
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 02/21/09 06:29 PM

The one track I've tried (don't recall now which, 8~10 range), had the sequence data reference both bank 0 and 1.
Posted By: R. Belmont

Re: AO SDK release 1.4.8 available - 02/21/09 06:31 PM

Oh yeah. Now that you mention it, I did notice the sequences contained tone and mixer (!) change commands. This game will be fun fun fun :-)
Posted By: R. Belmont

Re: AO SDK release 1.4.8 available - 02/23/09 08:40 PM

"Typing of the Date"? Wow. I had to Google that one to make sure Knurek wasn't pulling a fast one :-) I bet Sega would've sued if it had been a PS2 game smile
Posted By: Deunan Knute

Re: AO SDK release 1.4.8 available - 02/23/09 11:41 PM

Meh. Try "Hang The DJ" for size. And no, it's not a survival horror.
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 02/25/09 11:25 PM

Some new rips:

Saturn:
Digital Angel - Dennou Tenshi Spiral Story (1997)(Koga Game Factory)(Tokuma Shoten)
Terra Phantastica (1996)(Chime)(Sega)

Dreamcast:
Yuukyuu Gensoukyoku 3 - Perpetual Blue (1999)(Starlight Marry)(Media Works)

10 Liquid Sounds of Morning Dew.dsf of the above has a little problem in the beginning. Sounds like the song is trying to play a nonbanked sample (resulting in chip sounds at start). No dsfinfo.py so I can't easily check what's wrong, PSF rip doesn't have this problem.

http://vgm.hcs64.com/
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 02/26/09 10:39 PM

New Saturn rips:

Fire Pro Gaiden - Blazing Tornado (1995)(Human)
Idol Mahjong Final Romance 4 (1998)(Video System)
Mahjong Ganryuujima (1995)(Cosmos Computer)(ASCII)
SD Gundam G-Century S (1998)(Japan Art Media)(Bandai)

SD Gundam is purely streamed, rest of them uses at least some sequences.
Not sure what's the deal with Mahjong Ganryuujima, both tone banks have all EFSDL values set to zero. And there's a third tone bank in the map file, but only two found on disc (well, there's a third one in SDDRVS.TSK, don't think that one counts). Maybe the game uses DSP only for the SFX? Pretty crappy music either way. laugh

http://ssf.hcs64.com/
Posted By: exolon2

Re: AO SDK release 1.4.8 available - 02/27/09 03:21 AM

Originally Posted By Knurek
Yuukyuu Gensoukyoku 3 - Perpetual Blue (1999)(Starlight Marry)(Media Works)

Some nice stuff there (e.g. "Burning Chase" is pretty interesting).
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 02/28/09 05:58 PM

Some minor http://dsf.hcs64.com/ update (well, minor as in only 1 GB wink ).

New sequenced rips there:

Ring, The - Terror's Realm (2000)(Tycoon)(Kadokawa Shoten) (yes, that's *that* Ring, and yes, it's creepy)
World Series Baseball 2K1 (2000)(WOW)(Sega)

New Saturn stuff:

Idol Janshi Suchie-Pai Special (1995)(Jaleco)
Kurubushi Kyoudai Gekijo Daiikkan - Mahjong-hen (1996)(Yumedia)
Simulation RPG Tsukuru (1998)(Pegasus Japan)(ASCII)
Slayers Royal 2 (1998)(Onion Egg)(Kadokawa Shoten)
Zork I - The Great Underground Empire (1996)(Infocom)(Activision)(Shoeisha)

http://ssf.hcs64.com/
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 03/01/09 08:11 AM


Shining Wisdom (1995)(Sonic! Software Planning)(Sega) minissf repack (shaves 4 MB smile ).

kingshriek, the tracks still pop at beginning, even when using the latest ssfmake.py. Another bug in DSP RAM zeroing or something non related?

http://ssf.hcs64.com/
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 03/02/09 06:27 AM

New Saturn rips:

Honkaku Pro Mahjong Tetsuman Special (1996)(Naxat)
RMJ The Mystery Hospital (1997)(System Sacom)(Bandai)
Tactics Ogre - Let Us Cling Together (1996)(Quest)(Riverhillsoft)
Virtua Call S (1998)(Fairytale)(KID)(KID)
Lupin the 3rd - Pyramid no Kenja (1998)(Tohoku Shinsha)(Asmik Ace)
Lupin the 3rd Chronicles (1997)(Spike)
Shinseiki Evangelion - Digital Card Library (1997)(Sega)
Tenchi Muyou! Toukou Muyou (1997)(Xing)
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 03/02/09 10:50 PM

Today's Saturn haul:

Real Mahjong Adventure - Umi he Summer Waltz (1998)(Seta)
Rox (1998)(Altron)
Tenant Wars (1998)(KID)
Tokimeki Mahjong Graffiti - Toshishita no Tenshi-tachi (1996)(Sonnet)
Virtual Mahjong (1998)(Micronet)
Yoshimura Shougi (1998)(Konami)
Posted By: kingshriek

Re: AO SDK release 1.4.8 available - 03/03/09 04:54 AM

Originally Posted By Knurek

Shining Wisdom (1995)(Sonic! Software Planning)(Sega) minissf repack (shaves 4 MB smile ).

kingshriek, the tracks still pop at beginning, even when using the latest ssfmake.py. Another bug in DSP RAM zeroing or something non related?

http://ssf.hcs64.com/


Turns out to be a legitimate bug in the driver when it initializes DSP RAM. I noticed something was amiss when I logged DSP reads from DSP RAM:
Code:
DSP->READ : SCSPRAM[54418]=0006
DSP->READ : SCSPRAM[5441A]=6000
DSP->READ : SCSPRAM[5F218]=0006
DSP->READ : SCSPRAM[5F21A]=6000
DSP->READ : SCSPRAM[56ACA]=6000
...


These should all be 0x6000 if the driver is initializing DSP RAM properly.

Next, I logged CPU writes to DSP RAM to see what exactly was being written here:

Code:
CPU->WRITE @ 02B20: SCSPRAM[50000]=66000
CPU->WRITE @ 02B22: SCSPRAM[50004]=66000
CPU->WRITE @ 02B24: SCSPRAM[50008]=66000
CPU->WRITE @ 02B26: SCSPRAM[5000C]=66000
CPU->WRITE @ 02B20: SCSPRAM[50010]=66000
...


And here we see values of 0x66000 being written in 32-bit chunks which agrees with the DSP seeing 0x0006 occasionally since it reads in 16-bit chunks. I logged the program counter so now it was time to disassemble the problematic code:

Code:
0x00002B0A: 0x303C 0x6000                       MOVE.W   #0x6000,D0
0x00002B0E: 0x2603                              MOVE.L   D3,D3
0x00002B10: 0x6718                              BEQ.S    *+0x1A [0x2B2A]
0x00002B12: 0x2445                              MOVEA.L  D5,A2
0x00002B14: 0xE88B                              LSR.L    #4,D3
0x00002B16: 0x6712                              BEQ.S    *+0x14 [0x2B2A]
0x00002B18: 0x5343                              SUBQ.W   #1,D3
0x00002B1A: 0x3603                              MOVE.W   D3,D3
0x00002B1C: 0x670C                              BEQ.S    *+0xE [0x2B2A]
0x00002B1E: 0x24C0                              MOVE.L   D0,(A2)+
0x00002B20: 0x24C0                              MOVE.L   D0,(A2)+
0x00002B22: 0x24C0                              MOVE.L   D0,(A2)+
0x00002B24: 0x24C0                              MOVE.L   D0,(A2)+
0x00002B26: 0x51CB 0xFFF6                       DBF      D3,*-0x8 [0x2B1E]
...


A quick glance at the disassembly shows that the DSP RAM init value is in register D0 (0x6000 is the DSP's floating point representation of zero) and the DSP RAM address is in A2. The values are written 32-bits at a time in a somewhat unrolled loop with D3 as the loop counter. The problem is clear - the init value in D0 is set with a MOVE.W instruction which only writes the 16 lower order bits of the register. The upper 16 bits is uninitialized data that just happens to have the value 0x0006 at runtime.

Fixing the code isn't hard. We just need to replace the MOVE.L instructions in the init loop with MOVE.W's so the DSP RAM is initialized in 16-bit (where we have a known value) chunks instead. The loop counter will need to be increased by a factor of 2 so the same amount of data is written.

Code:
0x00002B0A: 0x303C 0x6000                       MOVE.W   #0x6000,D0
0x00002B0E: 0x2603                              MOVE.L   D3,D3
0x00002B10: 0x6718                              BEQ.S    *+0x1A [0x2B2A]
0x00002B12: 0x2445                              MOVEA.L  D5,A2
0x00002B14: 0xE68B                              LSR.L    #3,D3
0x00002B16: 0x6712                              BEQ.S    *+0x14 [0x2B2A]
0x00002B18: 0x5343                              SUBQ.W   #1,D3
0x00002B1A: 0x3603                              MOVE.W   D3,D3
0x00002B1C: 0x670C                              BEQ.S    *+0xE [0x2B2A]
0x00002B1E: 0x34C0                              MOVE.W   D0,(A2)+
0x00002B20: 0x34C0                              MOVE.W   D0,(A2)+
0x00002B22: 0x34C0                              MOVE.W   D0,(A2)+
0x00002B24: 0x34C0                              MOVE.W   D0,(A2)+
0x00002B26: 0x51CB 0xFFF6                       DBF      D3,*-0x8 [0x2B1E]
...


Shorthand binary patch:
Code:
2B14: E88B --> E68B
2B1E: 24C0 --> 34C0 (x4)


Updated sw.ssflib:
http://h1.ripway.com/kingshriek/sw.ssflib

BTW, the tracks pop in the beginning in the actual game itself (tested out on a real Saturn) so the SSF set is technically more accurate as is.
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 03/04/09 05:03 PM

Thank you for looking at the stuff. Finally they play okay. smile

new Saturn rips:

Mezase Idol Star!! Natsuiro Memories - Mahjong-hen (1996)(Shar Rock)
Virtual Mahjong II - My Fair Lady (1998)(Micronet)
Shining Wisdom (1995)(Sonic! Software Planning)(Sega) - driver patched by kingshriek, finally no pops at track start

http://ssf.hcs64.com/
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 03/05/09 12:15 AM

Mysterious plugin guy, if you're reading this somehow, this 2SF file crashes the latest version of vio2sf:

http://www.sendspace.com/file/mxs9fr

Works fine in No$GBA and other emulators.
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 03/05/09 06:36 AM

Thank you, everything works now wonderfully. smile

BTW, RB, do check that track and see how many Namco games you can spot being referenced. :P

Also, dsf.hcs64.com was updated today, pretty much everything's streamed except for Nightmare Creatures II (2000)(Kalisto)(Konami). Just wait till you see what format it uses though. :P
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 03/05/09 09:43 PM

Oh, one more thing, Mysterious plugin guy: NTR-ANOJ-JPN-0000.mini2sf from Trace Memory [Another Code - Futatsu no Kioku] is not playable by current plugin.

Song has about 5-6 seconds of silence at the beginning, and the current code skips to the next song after only 3 or even less. Any chance to fix that one?
Posted By: R. Belmont

Re: AO SDK release 1.4.8 available - 03/05/09 09:55 PM

XM makes sense if there's also a Sony version - SCE Europe (of course) offers licensed developers an official XM player for I think all of their systems.
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 03/07/09 02:06 AM

New Saturn rips:

Baroque (1998)(Sting)
Jissen Mahjong (1995)(-)(Imagineer)
Kaitou Saint Tail (1997)(Access)(Tomy)
Mahjong Gakuensai (1997)(Make)
Mahjong Gakuensai DX Zenjitsu ni Matsuwaru Funsenki (1998)(Make)
Mahjong Hyper Reaction R (1996)(-)(Sammy)
Mahjong Kaigan Monogatari - Mahjong-kyou Jidai Sexy Idol-hen (1995)(Micronet)
Mahjong Tenshi Angel Lips (1996)(-)(Syscom)

http://ssf.hcs64.com/
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 03/13/09 05:41 AM

Mysterious plugin guy: vio2sf doesn't support _lib tags according to PSF specification:

#CaitSith2:

"I tried similar _lib / _lib2, and it does not seem to be implemented properly, according to the standards.

Proper procedure of _lib loading.

_lib = Main rom with everything required.
mini2sf = patch rom that changes the song. Usually one or two bytes patched.
_lib2, _lib3, etc.. = patch rom that changes other bytes, or loads in other data in place of existing data.

So basically, _lib is loaded first right into ram.
_lib2 is then patched into the memory that _lib takes up. If this would exceed boundaries that _lib took, reallocate the size of _lib.

Then mini2sf is applied on top of _lib, same procedures.

This really should have been implementted into the player even if it wasn't used at the moment. If you need some help, look at the source code of highly advanced. It is implemented there."

Also, vio2sf 0.18 has a severe bug in _lib loading, which makes every set unplayable:

"There's a bug in the xsflib loading code, the default behaviour loads mini2sf first and then overlays the 2sflib on to that.

Since mini2sf have the song select code, and the driver 2sflib has only a constant value for that, what you will get is song 0x00 playing for *all* files.

Adding _vio2sf_loader_type=1 tag to all mini2sf files will fix the situation, but isn't obviously the intended solution."
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 03/25/09 06:43 PM

Two new SSF rips, to relieve boredom from all the 2SF reripping:

Tactical Fighter (1997)(TamTam)(Media Rings)
Takuramakan - Tonkoudenki (1996)(Interserv)(Alfa System)(Patra)

http://ssf.hcs64.com/
Posted By: R. Belmont

Re: AO SDK release 1.4.8 available - 03/25/09 06:48 PM

Yay! smile

Are all the 2SF rerips on the real driver versions now?
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 03/25/09 07:29 PM

No, but they use newer version of the driver (which seems to have gotten rid of all the playback problems so far) and they use the new, savestate less format, so they should run on the real hardware (didn't actually check, but they work fine in NDS emulators).
Posted By: R. Belmont

Re: AO SDK release 1.4.8 available - 03/25/09 08:12 PM

Oh, they're self-booting? That's a major improvement.
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 03/25/09 09:22 PM

Here's how it works:

1. Depack the 2sflib into bin file - Neill's psf2exe won't work, but VGMToolbox (http://sourceforge.net/projects/vgmtoolbox/) handles it fine (Misc. Tools -> xSF Tools -> xSF2EXE).

2. Strip first 8 bytes of the bin file (4 bytes for load adress, 4 bytes for section size), rename to NDS.

3. It should default to song select 0x00 for most sets, if you want something else to play, change the two bytes at offset 0x0d0fc0 in the NDS file (of course, nongeneric drivers have the song select at different offset. Depacking mini2sf and checking the loading address should help). Valid values you can take either from a SMAP file (again, VGMToolbox can both extract the SDAT from the NDS file and generate SMAP from that) or by depacking the mini2sf files
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 03/28/09 07:46 PM

Two new SSF rips:

Irem Arcade Classics (1996)(Irem)(I'Max)(I'Max)
Winning Post 3 (1998)(Koei)

http://ssf.hcs64.com/

Irem set has Zippy Race, Spartan X and 10 Yard Fight, both in original PSG and some nice arranges.
Posted By: R. Belmont

Re: AO SDK release 1.4.8 available - 03/28/09 08:55 PM

Cool. I just found my DSTT again so I'll have to try self-booting some rips. Has anyone verified they do run on hardware?
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 03/28/09 09:50 PM

Yes. Supposedly, there's less hiss than the vio2sf outputs (though I think that may be just general winamp crappyness, haven't noticed much problems when using XMPlay, crappy samples excluded).

Works on my R4 too, so your cart should work as well. Best part? It doesn't support hinge, so you can close the lid, and music keeps going.
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 03/31/09 05:16 AM

New DSF set (and a bunch of streamed packs, I'm not gonna list here):

Hanagumi Taisen Columns 2 (2000)(Overworks)(Sega)

http://dsf.hcs64.com/

I just hope I didn't botch sampleset to sequence matching.
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 04/09/09 05:19 AM

New DSF set (and again, some streams):

Kidou Senkan Nadesico - Nadesico the Mission (1999)(Will)(Kadokawa Shoten)

http://dsf.hcs64.com/

RB, the set has some problematic tracks...
BGM20.dsf does click a lot in the beginning under AODSF, no problems with Deunan's player.
BGM03.dsf sounds like some samples are played a few BPM faster than they should be (the percussion loop doesn't really much the music all that well). Again, no problems with Deunan's player.
Posted By: Deunan Knute

Re: AO SDK release 1.4.8 available - 04/09/09 09:23 AM

Which is strange because it's all supposed to be timer-based. So one would expect it work or not but it's a situation where most instruments sound OK, except percussion.
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 04/11/09 06:00 PM

Special Naomi Dreamcast update:

Sequenced:

Confidential Mission (Naomi)(2001)(Hitmaker)(Sega)
Kuru Kuru Chameleon (Naomi)(2006)(Able)
La Keyboard XYU (Naomi)(2001)(Sega Rosso)(Sega)
Maze of the Kings, The (Naomi)(2002)(Sega)
Tetris Kiwamemichi (Naomi)(2002)(Success)
Usagui - Yamashiro Mahjong-hen (Naomi)(2003)(Warashi)(Sega)
Virtua Tennis (Naomi)(2000)(Hitmaker)(Sega)

Streamed:

Chaos Field (Naomi)(2004)(MileStone)
Jingi Storm - The Arcade (Naomi)(2005)(Atrativa Japan)
Karous (Naomi)(2006)(MileStone)
Lupin The Third - The Shooting (Naomi)(2001)(WOW)(Sega)
Psyvariar 2 - The Will to Fabricate (Naomi)(2004)(Skonec)(G.rev)
Puyo Puyo Fever (Naomi)(2003)(MileStone)(Sega)
Trigger Heart Exelica (Naomi)(2005)(Warashi)

SPSD (not playable currently in VGMStream):

Beach Spikers (Naomi 2)(2002)(Sega)
Monkey Ball (Naomi)(2001)(Sega)
Virtua Tennis 2 (Naomi)(2001)(Hitmaker)(Sega)

http://dsf.hcs64.com

Anything that was added lately in MAME and is missing here, has same music bitwise as the already ripped Dreamcast version (CRCs might not match since the Dreamcast files seem to have some 0x00 padding, but the ADPCM data is identical).

Enjoy, some real gems there (should tide you till next M1 build I hope :P).
Posted By: R. Belmont

Re: AO SDK release 1.4.8 available - 04/11/09 07:54 PM

Usagui has some real standout music for a mahjong game. Kudos to Warashi on that.

I was kinda hoping for AICA versions of the "traditional" songs that The Tetris Company recommends in Kiwamemichi but no such luck, it's just all trance-by-numbers smile
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 04/11/09 08:48 PM

Yea, Usagui is really nice.
Pity Exelica isn't sequenced, like you've written once. smile
Posted By: Phil Bennett

Re: AO SDK release 1.4.8 available - 04/13/09 10:22 AM

The Lupin III soundtracks are streamed? That's a bit disappointing.

They sounded like incredibly good sequenced renditions of the music from the TV show. I wonder why they didn't just use the original source music.

Confidential Mission reminds me of The Propellerheads, which is no bad thing smile
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 04/18/09 06:35 PM

Part deux of Naomi fiesta:

Cannon Spike [Gunspike] (Naomi)(2000)(Psikyo)(Capcom)
Heavy Metal - Geomatrix (Naomi)(2001)(Capcom Production Studio 1)(Capcom)
Outtrigger (Naomi)(1999)(Sega AM2)(Sega)
Power Stone (Naomi)(1999)(Capcom Production Studio 1)(Capcom)
Power Stone 2 (Naomi)(2000)(Capcom Production Studio 1)(Capcom)
Samba de Amigo (Naomi)(1999)(Sonic Team)(Sega)
Spawn - In the Demon's Hand (Naomi)(1999)(Capcom Production Studio 1)(Capcom)
Typing of the Dead, The (Naomi)(2000)(Smilebit)(Sega)

http://dsf.hcs64.com

Pretty much everything (sans Samba de Amigo) sequenced this time. Pity there's no autotimer for AM2 driver files...
Posted By: R. Belmont

Re: AO SDK release 1.4.8 available - 04/18/09 06:43 PM

Hurray for sequenced smile Weren't the DC Power Stones streamed though? Interesting they went to the work of AICAing the tunes and didn't carry it across.
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 04/18/09 06:52 PM

Yes, all of the game up there use ADX for DC version. Probably due to the 2MB vs 8MB AICA sample RAM size.
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 04/24/09 11:08 PM

Special Naomi Dreamcast update part 3:

2009-04-25

new:

Death Crimson OX (Naomi)(2000)(Ecole)
Dengen Tenshi Taisen Mahjong Shangri-la (Naomi)(1999)(Marvelous)
Derby Owners Club (Naomi)(1999)(-)(Sega)
Dynamite Baseball (Naomi)(1998)(-)(Sega)
Giant Gram - Zen Nihon Pro Wres 2 in Nihon Budoukan (Naomi)(1999)(Scarab)(Sega)
Giant Gram 2000 - Zen Nihon Pro Wres 3 Eikou no Yuusha-tachi (Naomi)(2000)(Scarab)(Sega)
Guilty Gear X (Naomi)(2000)(PicPac-Airreal)(Arc System Works)(Sammy)
Marvel vs. Capcom 2 - New Age of Heroes (Naomi)(2000)(Capcom Production Studio 1)(Capcom)
Quiz Ah! Megami-sama - Tatakau Tsubasa Totomo Ni (Naomi)(2000)(SIMS)(Sega)
Virtua NBA (Naomi)(2000)(-)(Sega)
World Series '99 [Dynamite Baseball '99] (Naomi)(1999)(-)(Sega)
Zombie Revenge (Naomi)(1999)(Sega AM1)(Sega)
Posted By: Deunan Knute

Re: AO SDK release 1.4.8 available - 04/25/09 09:28 AM

GGX really is eye, uh, ear candy smile
Posted By: R. Belmont

Re: AO SDK release 1.4.8 available - 04/26/09 03:31 AM

GGX is mostly just song fragment loops stitched together at runtime, and the guitar sounds are atrocious. But some of the sequences are good smile
Posted By: Knurek

Re: AO SDK release 1.4.8 available - 01/01/10 02:55 PM

Special Naomi/Atomiswave/Dreamcast update part 4:

18 Wheeler - American Pro Trucker (Naomi)(2000)(Sega AM2)(Sega)
Airline Pilots Deluxe (Naomi)(1999)(-)(Sega)
Club Kart - European Session (Naomi 2)(2002)(-)(Sega)
Crazy Taxi (Naomi)(1999)(Hitmaker)(Sega)
Demolish Fist (Atomiswave)(2003)(Dimps)(Polygon Magic)
Derby Owners Club II (Naomi)(1999)(-)(Sega)
Dolphin Blue (Atomiswave)(2003)(-)(Sammy)
Extreme Hunting (Atomiswave)(2005)(-)(Sammy)
Guilty Gear Isuka (Atomiswave)(2003)(Arc System Works)(Sammy)
House of the Dead 2, The (Naomi)(1999)(Sega AM1)(Sega)
Jambo! Safari (Naomi)(1999)(-)(Sega)
King of Fighters Neowave, The (Atomiswave)(2005)(SNK Playmore)(Sammy)
Knights of Valour - The Seven Spirits (Atomiswave)(2004)(IGS)(Sammy)
Net Select Keiba Victory Furlong (Atomiswave)(2005)(-)(Sammy)
Project Justice [Moero! Justice Gakuen] [Project Justice - Rival Schools 2] (Naomi)(2000)(Capcom Production Studio 1)(Capcom)
[Streams]
Ranger Mission (Atomiswave)(2004)(-)(Sammy)
Rumble Fish, The (Atomiswave)(2004)(Dimps)(Sammy)
Rune Caster (2000)(Noisia)
Salary Man Kintarou (Atomiswave)(2004)(-)(Sammy)
Sega Tetris (Naomi)(1999)(-)(Sega)
Sports Shooting USA (Atomiswave)(2002)(-)(Sammy USA)
Wild Riders (Naomi 2)(2001)(-)(Sega)
WWF Royal Rumble (Naomi)(2000)(Yuke's)(Sega)

http://dsf.hcs64.com

I know you're all just for the redneck songs from Extreme Hunting in this one.

Also, if kingshriek is still around-ish, Knights of Valour: The Seven Spirits does bad things with the autotimer.
Posted By: R. Belmont

Re: AO SDK release 1.4.8 available - 01/01/10 03:07 PM

Redneck songs from Extreme Hunting? Oh hells yes smile
Posted By: nZero

Re: AO SDK release 1.4.8 available - 01/01/10 07:05 PM

THE HOUSE...

OF THE DEAD
Posted By: oppomix13

Re: AO SDK release 1.1.1 available - 11/26/11 05:10 AM

Fantastic
Posted By: Misty

Re: AO SDK release 1.1.1 available - 01/21/13 11:48 PM

Awhile back I asked about S98, and R. Belmont mentioned that he'd look at including it in the next AOSDK. Just wanted to check in on that. I have a project that uses AOSDK for some other formats already, so getting S98 support in AOSDK would definitely be the easiest way for me to add support for it.

(Sorry for the necrobump, but I assumed posting in the AOSDK thread would be better than bumping another or making a new one.)
Posted By: R. Belmont

Re: AO SDK release 1.1.1 available - 01/22/13 12:56 AM

Sorry, yeah. It's been a slog getting the new AO itself together so I haven't bothered with the SDK, but please keep bugging me smile
Posted By: Misty

Re: AO SDK release 1.1.1 available - 01/22/13 02:34 AM

Haha, makes sense. I'll check in again later wink AOSDK is waiting on the new AO then?
Posted By: Misty

Re: AO SDK release 1.1.1 available - 03/28/13 06:03 AM

Ping wink Have you had a chance to look at this yet?
Posted By: R. Belmont

Re: AO SDK release 1.1.1 available - 03/31/13 03:50 AM

Sorry, no smile
Posted By: MetalliC

Re: AO SDK release 1.1.1 available - 02/24/15 01:09 PM

sorry for necroposting, but does anyone have http://www.neillcorlett.com/etc/myaica.txt mentioned in this topic ? sadly its not available on Neill's site anymore.
Posted By: R. Belmont

Re: AO SDK release 1.1.1 available - 02/28/15 06:48 PM

I used to, but that was several HDDs ago and search doesn't show it now. And unfortunately his robots.txt kept the Wayback Machine out.
Posted By: MetalliC

Re: AO SDK release 1.1.1 available - 03/01/15 12:06 PM

no need to, thanks to D.K.
if someone else may need it - http://pastebin.com/9TbKLGPs
Posted By: MetalliC

Re: AO SDK release 1.0 available - 04/11/15 08:03 AM

Hi.
is someone still interested in researching AICA filter EG ?

have some progress with this:
at first I've taken this filter formula http://www.musicdsp.org/showone.php?id=185 , because using Neil's I can't get any resonance.

as for coefficients: I think FEG values (both filtering coeff and Q) uses the same dB logarithmic volumes as AEG but with 3 more LSB added. So in short - Neill was one bit wrong, it have 9 fractional bits and 4 exponential (not 8 and 5).
In the case of Q it must be <<=6 so it become in same dB range as FEG level.
this assumptions also kind of approved by old AICA implementation http://sabia.tic.udc.es/gc/Contenidos%20...CA_E.HTM#no6_17 , when at some stage of development Q register was full 13 bits, not just 5bits as in final version.

so currently I have this (messy) code:
Code:
#define F_FRAC_BITS 6
#define F_ALL_BITS 10
		// FEG_Level (13 bits -> 10 bits)
		u32 c_db = (chan->feglevel) >> (13 - F_ALL_BITS);
		// FEG_Level - (Q - 3dB), add/sub of dB values equal to mult/div of linear R and C coefficients
		s32 rc_db = (chan->feglevel - ((chan->q << 6) - 0x100)) >> (13 - F_ALL_BITS);
		LIMIT(rc_db, 0, ((1 << F_ALL_BITS) - 1));
		s32 c_lin = (((c_db & ((1 << F_FRAC_BITS) - 1)) | (1 << F_FRAC_BITS)) << (F_ALL_BITS - F_FRAC_BITS - 1)) >> ((c_db >> F_FRAC_BITS) ^ ((1 << (F_ALL_BITS - F_FRAC_BITS)) - 1));
		s32 rc_lin = (((rc_db & ((1 << F_FRAC_BITS) - 1)) | (1 << F_FRAC_BITS)) << (F_ALL_BITS - F_FRAC_BITS - 1)) >> ((rc_db >> F_FRAC_BITS) ^ ((1 << (F_ALL_BITS - F_FRAC_BITS)) - 1));

		s32 inv_rc_lin = (1 << F_ALL_BITS) - rc_lin;
		chan->feg_v0 = inv_rc_lin * chan->feg_v0 + c_lin * s - c_lin * chan->feg_v1;
		chan->feg_v0 >>= F_ALL_BITS;
		chan->feg_v1 = inv_rc_lin * chan->feg_v1 + c_lin * chan->feg_v0;
		chan->feg_v1 >>= F_ALL_BITS;
		s = chan->feg_v1;


which gives IMO nice result "close enough" to real thing smile
here few recordings for comparison:
BIOS sounds:
Demul http://rghost.ru/7862ZRCJb
real DC http://rghost.ru/8ctcKWMtb

Sega GT sound test track 01
Demul http://rghost.ru/665QFjwl8
real HW https://www.youtube.com/watch?v=oH6gW2bxaJk


But... there is some problem in algorithm. by design it makes sound a bit off/quiet (then C 1 and Q 0 output becomes = input minus previous output), so with Feg_Lv 0x1FF8 and Q 4 output is not the same as input.

is there anyone good at DSP processing and may give advice to look at some another filtering algorithms/formulas ?

Posted By: R. Belmont

Re: AO SDK release 1.0 available - 04/11/15 10:56 AM

I'm definitely interested in getting the right filter EG, but I'm not a DSP expert. That'd be Olivier smile
Posted By: MetalliC

Re: AO SDK release 1.0 available - 04/11/15 12:50 PM

ok,
as for filter envelope generation part - it looks the same as AEG in the term of change rate (as noted in html docs).
so time for full 0-0x1FFF change is aproximate 8x longer than AEG times tables, not ~4x like DCDBSysArc990907E.doc says.

but correct EG rate formula is still unknown, for both AEG and FEG (if KRS!=0x0F).
docs says its (KRS[0:15] + OCT[-8:+7]) * 2 + (FNS>>9) + RATE*2
some SCSP/AICA emulators calculate it this way, other like AO uses
KRS[0:15]*2 + OCT[-8:+7] + (FNS>>9[0:1]) + RATE[0:31]*2, so octave isnt *2
others calculate (KRS+OCT)*2 but add it only if value >0 (I currently use this)
but sadly its really unknown for now how exactly EG rate value calculated, in both SCSP and AICA.
Posted By: KotCzarny

Re: AO SDK release 1.0 available - 10/22/17 06:54 PM

hello, i've integrated aosdk in my player (oscp, http://talk.maemo.org/showthread.php?t=94590 ), it works, but i have some tunes not playing on my arm build (will report which ones later once i check the x86 build too. what is the status of aosdk? is it still supported/worked on?
Posted By: R. Belmont

Re: AO SDK release 1.0 available - 10/22/17 08:06 PM

aosdk hasn't been updated in approximately forever, but we're still interested in bugs smile
Posted By: KotCzarny

Re: AO SDK release 1.0 available - 10/23/17 10:01 AM

just checked on the x86 and the bugs are the same as on arm. maybe it's my integration that is failing but c&d tune is completely silent and ps2 file sounds like it is wrong byteorder or wrong buffer size. i've put those tunes here: https://31.135.195.151:20281/aosdk/xsf-bugs.tar.gz
btw. can i talk to you on irc?
Posted By: Richard Bannister

Re: AO SDK release 1.0 available - 10/24/17 05:38 PM

Damn, people still remember AO?
© 2019 Forums