NullDC-360的進展 - 模擬器

停掉的東西再開( ￣ c￣)y▂ξ

http://www.homebrew-connection.org/nulldc-360-the-dreamcast-emulato
r-project-is-back-on-the-road/


NullDC-360 : the dreamcast emulator project is back on the road

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
︸one, but according to GliGli

http://www.youtube.com/watch?feature=player_embedded&v=dYWGTBvzd38


Here is his blog message :

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


--