The big change this week was the cutover to subversion for source control, otherwise things are fairly quiet at the moment. Also looking into a few homebrew games that are black-screening at the moment (damnit…) which would be nice to fix…
Changes

• Converted source repository to subversion
• Handful of minor bugfixes
• Add support for CDI v4 (I think), and NRG 5.5+ images.
• Add quick-n-dirty set of debian control files
• Fix make install to include system rc file and exclude intermediate tools.
• Start fixing up the unit/system tests to actually run properly
• Added brazilian portugese and german UI translations (thanks to arthonis and linuxdonald)

The current plan for 0.9 looks like this:

1. Fix the renderer
2. Implement MMU address translation.

The big focus for 0.9 obviously has to be the rendering module - we need to speed things up a lot (at least 5-10x faster than it is currently), deal with a bunch of bugs (most of them cases where GL and the PVR2 don’t quite see eye-to-eye), and implement about half a dozen missing features (none of them trivial).

The AT is something I’ve wanted to have working for a while but it just hasn’t been a high enough priority compared to everything else (especially as it’s going to be a pain to get it to run fast enough). I suspect that no one else cares, but personally I’m very keen to see linux-dc running inside the emu…

In any case, everything after that is just gravy, and really depends on how I go for time. Unfortunately November is looking to be very busy IRL, so we’re looking at a January release at this point. But it will _rock_, so there ^_^

I’ve also finally gotten around to putting my “status” list up on the wiki. To be honest it’s a depressing list, as it seems to change at a glacial pace, but… there you are.

Changes  (what, you want changes already?)

• Implement full-screen mode (scaling based)

Finished off the GUI changes for the next release, and fixed a few audio issues. Still trying to figure out wtf is happening with the channel volume though, something’s not quite right there…
Changes

• Finished rewriting the debug GUI to cooperate with the new main window - last remnants of glade-generated code are now gone.
• More work on the controller settings dialog - it’s useable now (well, useable as in “it’s possible to use it” anyway), works, etc.
• Fixed freelist bug in texcache (I don’t know how its gone so long without being triggered before, but…)
• Fixed AICA save state data (wasn’t saving the channel or IO data)
• Implemented AICA channel status registers

It’s been a GUI kind of week…

Changes

• Maintain aspect-ratio when resizing window
• Simplify command line - “lxdream disc-image” now boots off the specified disc.
• Config file now loaded/saved from home directory by default, with system defaults in the sysconfdir.
• Improve keyboard support to use unmodified key values (ie z and shift-z are now interpreted the same way).
• Add initial controller settings dialog
• Add path settings dialog
• Unbreak the debugger (although the translator still doesn’t play well with it)
• Add CDI V3.5 support (0×80000006) - looks to be barely distinct from V3 anyway.

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?)
• Add support for output scaling
• Clean out a batch of obsolete cruft from the video driver.

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.
• Fix save state loader bug (SH4).
• Add command-line opt to change the SH4 speed scaling
• Remove instruction counter in ESI (change to constant loads where needed)
• Suppress redundant flag loads

[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.

Worked on some minor translator related optimizations this week, for some decent gains. If I can knock off another 10-20% I should be just about in the “real-time” ballpark at long last. The big candidates are memory accesses (sh4_read_long is nearly 20% of the total runtime at the moment by itself), and PVR2 status updates (close to 20% under at least some loads). It’s not that either is particular complex or expensive, they’re just called a lot. I can probably knock another 1-2% off the main translate-and-execute loop too.
Changes:

• Fixed heap smash in the translation cache
• Added initial GLSL shader support
• Rewrote translation exit block (Gained ~10% performance out of it and freed up EDI in case it’s worth using elsewhere). The system also seems to build correctly with -O2 now, which gives another 10% improvement.

As of this morning the system successfully runs all the way through the boot sequence using the translator core. Currently performance is around 66% of full speed on the dev machine - a huge improvement over the emu core. In fact, it’s almost playable…

I’ll do some testing tonight, and as long as I don’t find anything critical there’ll be an M3 tomorrow (pretty much just M2 + SH4 translator)
Changes

• Added tests for another group of opcodes
• Fixed several broken instructions (translator)
• Finished translation cache invalidation

Many bug fixes later (mostly dumb errors of either the cut-n-paste or pure braino variety), the translator is almost running correctly. At least now it runs well enough at least to start to collect timing information - at the moment it looks to be running at around twice the overall speed with the translator running (compared to with the pure emu core) on the BIOS startup. Which is a nice start, but not really nice enough unfortunately. On some tight test loops it actually executes at 10x emu speed - closer to where I’m aiming for.
The next step (other than clearing out the remaining bugs) is to start collecting some statistics, and see if there’s some simple peephole optimizations we can apply.

After much umming and ahing, I’ve scrapped the translator generator for the time being - it’s become far too complex for its own good, and just wasn’t going to be finished in a reasonable time. I will be keeping the original (much simpler) decoder generator though as part of the lxdream source tree. So, instead I’ve been working on finishing the instruction-at-a-time translator (ie, the simplest thing that could possibly work) with a view to getting it working and seeing what the performance is like, before getting into anything more complex.

The translator is now in an early testing form, which is to say that it’s mostly complete, and you can actually run it on real code, but it doesn’t work very well yet. I’ll be spending the next few days polishing things and getting the test suite running correctly, and then we can start testing for real.
Changes:

• Committed decoder generator for SH4 core, disassembler, and translator
• Committed instruction-at-a-time translator and hooked up via a command-line option
• Merged i386 disassembler from binutils (for debugging purposes)
• Fixed mac.l and mac.w opcodes in the emu core (they look to have been completely broken)
• Fixed some edge cases with float and ftrc (still checking other FP opcodes)
• Fixed crash when video driver failed to initialize (now degrades a little more gracefully)
• Hooked up video shutdown call for the GTK/GLX driver so that it actually works now
• Fixed rendering in headless mode (now it just doesn’t render anything, rather than crashing)
• Added ability to terminate after a specified period of emulated time (useful for time trials)
• Added many more SH4 test cases