In the interests of making it easier to contribute (as well as being easier to maintain), the Lxdream source repository and issue tracking been migrated to http://github.com/lxdream/lxdream .

I recently discovered that there is in fact a very nice ISO9660 library out there already called, oddly enough, libisofs. I’m not sure why I didn’t come across it earlier, but in any case I’ve ripped out my half-baked ISO support and added a dependency on libisofs instead. It looks to be available prebuilt for most systems, so hopefully no major dramas there.

The on-the-fly ISO-building support is in now as well (mainly thanks to the above), at least for executables. You can now load binaries from either the gdrom dialog (which packages it into a MIL-CD disc image), or the ‘load binary’ dialog (which does what it always did). The command-line is also changed slightly – “lxdream mygame.elf” loads the program as a disc, and “lxdream -e mygame.elf” executes it directly.

Additionally, loading “binary” files (i.e. as generated from “sh-elf-objcopy -O binary”) is now supported (seeing as it turns out that this wasn’t working previously). Since there’s no reliable way to identify them from content, they have to end in “.bin” to be recognized though.

So with that out of the way, I think I might go back to poking at the renderer the next time I have a few free moments. One thing at a time…

The (hopefully last) major refactor of the cdrom host subsystem has finally landed in trunk – this shouldn’t be particularly user-visible at this point (unless I’ve broken something, which is entirely possible), although it does fix a few long-standing bugs that no-one ever ran into. Mostly this is to make things more flexible, so that I can add features without it becoming an even more tangled mess.

The first of these is the ability to boot from disc without actually needing the Dreamcast boot rom. This is in now, and is working for dclinux and (I think) most homebrew. As far as I know it doesn’t work for any commercial titles at the moment though. As a nice side-effect it boots faster too (as it doesn’t have the flashy logo  screen).

The other piece of work that this supports is on-the-fly construction of cdrom images – for example, taking a binary program and encapsulating it automatically in a bootable image. Also of interest is support for SBI “images”, which are basically filesystems-in-a-zip. This also makes it easier to add image formats like BIN/CUE and BIN/TOC, so I’ll probably add those in the near future as well.

In unrelated news, OS X 10.6 has been giving me a lot of grief – exception unwinding support seems to be subtly broken (worse, in a way that’s hard to detect with a simple configure test). I wasted far too much time trying to track down a memory corruption bug that eventually turned out to be coming from the unwinder as well *sigh*. So for the time being I’m going to settle for building on 10.5, and hopefully it’ll work on 10.6 as well. Incidentally, I’m intending to drop support for 10.4 for the next version unless someone screams really loudly – trunk hasn’t actually built on 10.4 in quite some time, and no one has complained  yet…

What’s new

• CDROM host subsystem finally properly separated from the Dreamcast bits. Much better now
• BIOS-less booting of discs. Most homebrew should be able to run now without the actual boot rom.
• New -b command-line option to run without the BIOS even if it’s configured

Not much really got done last month, seeing as I was away for nearly all of it, but I did get a few small tidy ups done. The new translation core is definitely on hold now for a while so I can get some other things done – I’ll get back to it at some unspecified point in the future.

So… I suppose what everyone’s waiting for: There will be a 0.9.1 in the next few weeks (also known as the “what do you mean we haven’t had a release in 8 months?!” release), which will be more or less current svn trunk + one more feature I’m working on at the moment.

Changes

• Wahrhaft sent in a patch to add hotkey support, quick-save-states, and an LIRC input driver, thanks!
• Refactored the gdrom support module to be a lot cleaner, and make it easier to add other MMC-based native drivers. I think a fixed a few bugs in the process as well.
• Added ability to build drivers that require 3rd-party libs as dynamic objects rather than statically linked – this should make binary packaging a bit saner. On by default for now, configure –disable-shared to turn off.
• GTK: Added GNOME desktop entry for more convenient desktop integration
• OSX: Added fullscreen support (“er wait, the OSX port doesn’t do fullscreen?”)

I was distracted by Anthony Green’s Moxie blog this last week and a bit, specifically by the bit about qemu gdb support. This seemed like a really good idea, not to mention being fairly simple to implement, so it’s in now for both the SH4 and ARM. The actual debug support just hangs off the existing debugging framework, so the work needed was really just to implement the protocol.

If you want to have a play with it, run lxdream with -g <port> to start an SH4 GDB listener on the given TCP port, or -G <port> to start an ARM GDB listener. Or both for that matter, although gdb is likely to be confused if you actually connect more than one debugger at a time. To note the obvious, you’ll need to build an sh-elf-gdb or arm-elf-gdb (respectively) for this; your system debugger is just going to get confused. Also worth noting is that GDB tends to default to big-endian if there’s no file loaded – you need to explicitly force it to little endian (“set endian little”).

It supports all the usual bells and whistles except watchpoints, which I’m looking into at the moment. They should be reasonably straightforward to implement now, and will have zero cost when they’re not being used. And as a nice side-effect of all this I can finally do a full implementation of the on-board UBC.

I probably should have done this a long time ago – It’s nice to have a full symbolic debugger without having to actually write one from scratch ^_^

There’s not going to be a February release as originally scheduled – there’s just not enough ‘stuff’ ready to make it worthwhile in my opinion, and anyone looking for the latest has probably already pulled it from SVN. At the current (depressingly slow) velocity, there may be something releasable in April. We’ll see – I need to make sure the new SH4 translation core is solid, and make some decent headway on the PVR2 performance problems first.

Update-wise, we have a new SDL audio driver now, thanks to Wahrhaft, but otherwise not much of note to report at the moment. However, this might be a good time to note that there’s lot’s of other work that would be good to see done, but I’m simply not going to have time for any time soon – so if anyone out there is interested in contributing in any way, please let me know. There are some obvious areas that might be a good place to get started with lxdream –

• OS X port – The base port is fairly stable, but there’s a number of outstanding issues, and the UI could no doubt be improved.
• GTK UI – for that matter, the GTK UI isn’t very pretty either and could use some good UI design attention.
• Audio subsystem – Current audio is almost obnoxiously bad, with plenty of bugs and missing features. Fortunately MAME has a fairly complete implementation that could be used for comparison and testing.
• Translations – we have partial translations to german, spanish, italian, and portugese so far, which need to be updated for 0.9, and it would be great to support more languages as well. There are still some untranslated strings that need to be fixed as well.
• SBI ‘image’ support, not to mention the many other bugs/enhancement requests in the issue tracker.

And of course, anyone interested in working on improving lxdream in any other way would be eagerly welcomed too ^_^.