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

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.

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.

Uhh, Makaron *can* boot GDRom dumps.
Stuff with *.gdi, *.raw and *.bin files.

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

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?

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.

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

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

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.

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.