AuthorTopic: NullDC-360 : the dreamcast emulator project is back on the road (Read 1865 times)

The talented coder and hacker GliGli, mostly known for his work on the RGH and libxenon (Mupen64-360 : N64 emulator for Xbox 360...), seems to back on the scene. Indeed, since a few day some commits have been made on GliGli's NullDC-360 github and a post on his blog too. For those who didn't know, NullDC-360 is a WIP NullDC (dreamcast emulator for PC) port for Xbox 360 using libxenon library.

So what's the news .... since the lastest version, sound support have been added and some core code improvement done. A lot of work have still do be done, but according to GliGli "a proper binary release *might* not be that far "

Here is a little example how the emulator run actually, there is some slow down in the menu or when it's loading, but ingame it's very fine :

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