Forums GAMERGEN

Hey, as you might have noticed, I resumed my work on nulldc-360 and libxenon not long ago.

I’m currently working on 3 things: compatibility/sound/speed.

6 months ago I was badly stuck on 2 bugs, one texture endianess problem, and one random crash/infinite loop in the dynarec.
First thing I did was to look at that texture bug, in a few days I found the exact case where it happened and fixed it for good.
Then I fixed the dynarec one, it was quite an awful one: I forgot to save/restore the SH4 condition flag on dreamcast interruptions, so it was randomly corrupted as the emulated console handled its IRQs!
I fixed a few more bugs until it was clear I needed proper sound emulation for more games to boot.

Adding sound was relatively straightforward, of course there were the usual endianess related bugs, but I guess I’m getting used to it ^^
The Dreamcast sound chip (AICA) is a complex design, it has an ARM processor core, a 64 channel sound generator, and a DSP.
I don’t emulate the DSP for now, many games don’t really need it.
Main problem with sound is the induced emulator slowness, though thanks to the 360 multicore cpu, I was able to make it almost free.

Updating peripherals in the dynarec works that way: each code block knows how many SH4 cpu cycles it emulates, and each time a fixed number of cycles (448) is reached, it calls a procedure that updates those peripherals.
To multithread sound, and by the way, other peripherals, I run parts of that update on a separate core.
It runs concurently with the dynarec, and, basically, every 448 SH4 cycles both get sychronized. so as long as peripherals emulation takes less time than SH4 emulation, the dynarec doesn’t have to wait for them!
So that makes them almost free to emulate, almost because they still stress the 360 L2 cache and memory controller a little.

Anyway, compatibility seems pretty good now, sound works, speed is more or less the same it was before sound emulation, a proper binary release *might* not be that far