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

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.

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...

LPSLNK looks good as it is. EGHOLD was nowhere to be found.

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?

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 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.

Look at it on the bright side. You fixed it.

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.

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

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.

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.