Archive for October, 2007

With the work done in the last month both for performance and usability, it seems worthwhile to release a new version. And since this version is actually (hopefully) useable by people who aren’t me, lxdream now has a real version number rather than a milestone. W00t!
Download it and enjoy. And of course, let me know how it goes.

Note: Please do not report rendering problems at this stage – there are many known bugs and unimplemented features, and it’s looking like the whole rendering stage may need to be rewritten for the next version.

I tracked down an ugly bug that only appeared in optimized builds to some highly dodgy code that’s probably been there since nearly the start of the project. As a result, it seemed like it might be a good idea to start building with -Wall, and actually fix the warnings (shock horror). Fixed a couple of real bugs in the process too. I also dug a little bit into the sound system (for the first time in nearly a year) and got the boot sound to play. Well, for a couple of seconds before it breaks into noise at least – there’s still some issues there.

The biggest performance problem now appears to be the rendering code. For some typical scenes it’s taking 30-40ms/frame, where the original budget was around 25% cpu, or <5ms per frame. Yeah, it's bad. Working on it ^_^.Changes

Fix (nearly) all of the compilation warnings gcc was generating under -Wall. Including a couple of actual bugs, which was nice.

Fix ADPCM sound to at least sort of work.

Fix AICA key-on/key-off behaviour.

First draft of shiny new GUI (unfortunately debugger is broken at the moment, not sure if its worth fixing – does anyone actually want it?)

Fixed some minor bugs and improved the speed a little more – overall core speed is now roughly double that of M3 – not bad for a couple of weeks work. For certain use cases the system now runs at nearly 100% speed (under the unlikely assumption of 100,000,000 instructions/second[0]). Unfortunately I think I’ve just about tapped out the low-hanging fruit – further performance gains are likely to be obtained inch by painful inch.

My plan for the moment is to get a decent user UI up and running, fix some of the nastier audio + video bugs, and shoot for an interim release later this month. It’d be particularly nice if the bootup sound was approximately correct (now that things are fast enough that you can actually tell that its b0rked).

Changes

Fix more translation cache bugs

Fix controller triggers (sense was inverted)

Remove MMU AT checks from sh4mem.c (needs to be in core anyway for exception correctness). Also #define out the trace checks by default – slight performance gain.

Add explicit branches in sh4mem.c for main memory access – it’s actually faster this way, if less flexible.

[0] Bloody complicated superscalar pipeline design… real code could run at anywhere between 10 MIPS and 400 MIPS for a 200Mhz clock. Getting even approximate cycle accuracy would be nice, just as soon as I have an efficient way to implement it.