Saturday, December 04, 2010

It works ! I can't believe it !! ...

Wo, dudes. It sure has been an odd week at work, but it was even weirder after office hours when I tried to figure out what prevented Apple Assault to work... I wish I had actually typed "svn copy trunk branch/dkp-r32" before I started "fixing" the code for the new release of devkitarm.

After spending hours contemplating fifosystem.c and other hours digging into the source of DesMuME, I found no heroïc bug to fix, gained more confidence in the new tools and finally figured out that some of the assumptions I was working with (e.g. "thou shall call irqInit() before you invoke swiWaitForVBlank") were no longer true in the latest release ... and actually weren't true anymore for a while.

Migrating to the new libnds requires you to switch to the new everything ... including the latest desmume where the way to support "emulated filesystem" had changed. After I inserted a fake register whose content is dumped immediately on both ARM processors (I'm pretty sure there is similar features already, but it's faster to redo it than to locate it :P), I got capable of tracking the execution of the program ... Another modification enabled register dump after haltemu was called, which "explained" that the emulator shutdown was due to a new policy for handling not only exit(), but also abort() -- and C++ exceptions, which I had used in a tweaked way with the "devkitarm-21-based" setup I used so far.

The good news is that I now have Apple Assault running -- in a degraded mode, but running. And I have plenty of developer-friendly stuff added to my emulator to help me fix (hopefully) quickly the remaining things... It was about time : I nearly got discouraged yesterday.

Vous avez vu ? j'ai réussi à réavoir de l'Apple Assault qui s'affiche. C'est pas encore complètement rétabli, mais ça remarche de nouveau. Tout le reste, vous l'avez déjà lu dans les posts précédents :P

edit: I even managed to get sound running, although TrackSequences aren't working yet (missing the get-current-position ? no : curpos() do not rely on FIFO : it's just shared memory ... Or maybe I should ensure the oops[] array is accessed through un-cached addresses it looks to work fine the way it is, but it constantly compares against "pos == 0" ... ) That means the "trunk" is now definitely for "devkitpro-r32" (whatever it means) and that the devkitpro-r21 old things are archived once for all in tags/apple-assault-release.

3 comments:

PypeBros said...

it looks like I branch to another track, but not the right one >_<

PypeBros said...

So,
* I managed to point out that TrackSequence is created and correctly polls the current position in the module.
* I observed that the "change track" command is properly sent and that the ARM7 reacts to the command.
* but arguments of the command are all scattered: it try to start at row 25 of pattern 1 rather without looping rather than starting at row 0 of pattern 25 with looping >_<

PypeBros said...

okay. It's just that 0xt0b hadn't used the same argument ordering as I did when he also introduced support for potpos and row in libntxm :P

I'll have to check that we're on the same carrier with PLAY_INST command, then ...