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

I see we all follow the same source when it comes to calculating AICA volume levels 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.

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.

KS: sorry about that, I guess I messed up patching.

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)

Much appreciated

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

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

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

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

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 :-)

How is that not user friendly, compared to, say, vi?

My ARM code is apparently based on obsolete specs 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

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.