Updated the CD-Rom image code to handle the various read modes (Bug #59), including raw reads (using libedc to generate the EDC/ECC data on the fly), as opposed to the old code which really only handled mode 1 and mode 2 form 1 sectors - CD-Roms are much more complicated beasties than one typically imagines. I haven’t validated it yet, but I don’t think I’ve broken any of the cases that previously worked either *crosses fingers*.

In other news bhaal22 has contributed an ALSA sound driver which is now in svn, along with some initial (long overdue) work towards tidying up the audio subsystem.

Real Life(tm) has been a little bit hectic lately, so there’s isn’t much to report for last week for lxdream. The render split is mostly done now, and will probably be merged back to trunk this week (as soon as I reintegrate the trans poly sorting). Unfortunately I didn’t really get any performance improvements out of it (well, I was probably a little hopeful there), but at least I didn’t lose any performance either, and it was worth doing for other reasons. Once that’s merged I’ve got a few small non-render issues to sort out, and then I’ll get back to the annoying rendering bugs…

In other news, dclinux 010605 is now hosted locally (as long as the bandwidth holds out), including a self-booting NRG image (thanks to The Gypsy), check it out on the wiki. Note that you’ll need the latest svn trunk to boot the nrg image properly.

And finally, I see that MAME now has a mostly complete AICA driver, thanks to ElSemi, kingshriek, dknute & R.Belmont. *jaw drop*. That… will _really_ help ^_^.

Trunk Changes

• Fixed a couple of d’oh-level SH4 bugs (thanks to dknute for pointing them out)
• Quick hack to get the dclinux nrg booting. Full update to follow soon.

Still working on the render rewrite which is now in the lxdream-render branch (which may or may not even compile, and certainly won’t work at the moment).

The frontend stage to extract the poly+vertex data out into a nice array format is working now, and it runs in just about negligible time. Current task is to execute the rendering from the vertex buffer, which should be pretty straightforward. So… once this is done we should have a renderer which is a) much cleaner/extensible, b) much faster, and c) about the same or even less code.

If only all software engineering was like that ^_^.

Trunk Changes

• Fix inverted mouse button sense
• Fix incorrect error response size for maple get_condition buffers
• Fix keypad keycode translations
• Fix SLEEP timing fubar introduced in 0.8.3

It turns out that the lc2000.iso link that was posted (btw, thanks for that! ^_^) is an earlier version of linux-dc (it identifies as running the 2.4.0-test8 kernel) than the one I’d been testing with, and it exposed a few issues that needed fixing. These are now fixed in svn, except for the keyboard issue, for which source [0] would be very helpful if anyone has it?
Unfortunately this does mean I’m still looking for the original dreamcast-linux-010605.tar.bz2 (and the associated pre-built CDI and NRG images) - so if anyone has them, or knows where to find them, please let me know. I’m quite happy to host them locally, at least until the bandwidth runs out ^_^.

Btw for the BSD fans, there was supposed to have been a live netbsd disc floating around somewhere (the link from gxemul is dead) - has anyone seen it?

Edit: Nevermind, the NetBSD 3.1 image is actually included in the main netbsd mirror… having a look at it now.
Changes

• Fix LDS/STS FPSCR/FPUL instructions to raise FPU disabled exceptions (wasn’t very well documented in the original SH4 manual)
• Fix IDE dma read looping forever if the disc was removed or failed in the middle of the operation
• Fix crash when changing maple peripherals (this one was just boneheaded)

[0] The image itself does have quite a bit of source on it, but I can’t find the associated linux-sh-dc kernel patches against 2.4.0-test8. Which, of course, is the bit I actually need…

Updated 13 Feb: I don’t need the 2.4.0 source patch anymore - turns out its not a bug, that version was just hard coded to expect the keyboard on the 4th maple port, and I had it on the 3rd. Although, it would still be good to see it for the sake of the history.

I’ve started fiddling with the vertex shader, which has been fairly educational. It hasn’t actually fixed any of the bugs yet, but I’m hoping it will eventually give much better rendering accuracy. (Thanks to dknute for some good suggestions on the z-buffer problem) Unfortunately turning on the VS (even with a trivial program) gave me a big performance hit on my (admittedly relatively old) hardware, so it remains to be seen whether this will be viable for said hardware.
Also did some work to get osmesa support up and running, which is mostly done now but doesn’t quite work correctly (there’s some weird texture bugs, as well as the occasional projection matrix screwup). Unfortunately it’s also _really_ slow on any kind of real scene, so I’m not sure how much effort it’s worth spending on it at the moment[0].

Currently I’m working on reworking the renderer to use vertex buffers (or client-side arrays in the absense of VBO support), which are purported to be outrageously faster than immediate mode. We’ll see if that’s true, but even if there’s no big difference, the resultant data structures should be a lot easier to work with for processing purposes (saves traversing the tilebuffer repeatedly).
After the dust settles on that, the next priority is to fix the known outstanding blatant render bugs:

• Bug #29: Texture coordinate problems.
• Obviously wrong colours in some scenes
• Issues with misplaced (or incorrect geometry) in some scenes (the pre-render data is demonstrably correct in these cases, so it’s either a misread of the scene data (probably), or cases that need to be handled specially).
• Various hw specific issues with certain texture types (my favourite thus far is a scene that breaks on both ATI and NV but in quite different and distinct ways…)

And then on to shadow volumes (interesting), RTT (easy), pixel-level transparency sorting (hard) and all the other fun stuff ^_^.

[0] It should be possible to take just the sw rasterization engine out of mesa, and blow away the front end more or less completely. This would be a fair bit faster than it is currently, but it still probably won’t be fast enough. It also looks to involve quite a bit of work as well.

Last 0.8 point release, I swear. Just for a change, this one actually has some new features too. Specifically, it now runs linux (now some may argue that that’s not actually a _useful_ feature, but it’s a nice milestone)

With that out of the way, I think it’s finally time to rip the renderer apart and fix it all up, don’t you? ^_^

What’s New

• MMU Implementation - As previously noted, linux-dc now runs quite well, albeit slowly.
• Dreamcast mouse and keyboard controllers (also rather essential for running linux-dc)
• Support for real joysticks and gamepads (linux host only)
• Various bug fixes

Other Changes

• Change timer (TMU) interrupts to be precise (within the bounds of a code block anyway)
• Implement SLEEP op properly in translator
• Clamp run speed in the GUI if it’s running too fast
• Run event loop more frequently to avoid missing keyboard events

After fixing some boneheadedness in the ASIC event code (and a whole passel of translator caching and other bugs), I’ve finally gotten to the login prompt:

(to clarify, this is the dreamcast-linux-010605 ISO that Takeshi Yaegashi put together several years ago, running a modified 2.4.5 kernel)

Unfortunately (after the happy dance), it was at this point that I realised I haven’t actually implemented the keyboard yet, so it’s impossible to do anything useful with it. It’s also admittedly painfully slow to start, but I was expecting that (TLB lookup is currently near pessimal).

Anyway, working on the keyboard driver now ^_^.

PS: If anyone has a working link to this image, please let me know where it is (I’d like to keep a link to it) - my google-fu has utterly failed to turn up a good version as yet, and my own copy is only on a somewhat scratched CD…
Changes

• Add VMA support to the SH4 disassembly functions
• Handle out-of-page delay slot execution with emulation single-step
• Finish translator breakpoint implementation
• Fix a pair of long standing ASIC event bugs
• Fix xltcache forgetting to clear references to blocks before overwriting them
• Fix recovery + backpatch records not being position independent (big duh!)
• Fix yet another translate block bounds overrun
• Fix MAC.L/MAC.W exception handling (broke the stack if the second arg caused an exception)
• Fix various other minor bugs

Update: Just hacked together a quick keyboard driver, able to login and launch X now. Excellent…

Now that the mmu branch is running on all three platforms, I’ve merged it back to the trunk. Which is not to say that it’s _finished_ (it still doesn’t fully boot linux-dc), just that it doesn’t break anything that was previously working (to the best of my knowledge).

I’ve also working on some preliminary joystick/gamepad support (linux /dev/input/js*) - the driver itself is nearly trivial (the linux input interfaces are pretty nice), but I need to refactor our input event handling a little (currently it expects all input events to come from the UI).

Changes

• Add support for breakpoints in translated code (about time)
• Add MMU store-queue support
• Handle dreamcast_stop() and dreamcast_reset() properly from translated code
• Fix MMU build on OSX and x86-64
• Fix testsh4×86 compilation
• Fix TRAPA in emulation core
• Fix MMU support in emulation core
• Fix ITLB
• Fix delay slot exception translation issues

Hope everyone had a good christmas ^_^.

Second iteration of the MMU implementation is nearly done - it’s now slightly faster with MMU off than 0.8.2, which is nice (MMU-on is still rather slow, but I’ll worry about that later). The (old) version of linux-dc I’m using is still not booting yet though (odd IRQ errors now). Hopefully not much further now…

Change of plans - because svn looks likely to become unstable for a little bit with recent work (mmu changes are fairly invasive, and there’s quite a performance penalty that I haven’t optimized away yet), I’m releasing 0.8.2 as it is now (without TLB) for the benefit of those who need the fixes since 0.8.1.
Note: There are no significant changes to the emulation (ie no change to compatibility) - If 0.8.1 runs properly for you, you don’t need 0.8.2

Changes from 0.8.1

• x86-64 architecture support
• Preliminary Mac OS X support
• Pbuffer support (to support OpenGL drivers without EXT_framebuffer_object)
• Support for more recent CDI and NRG image file versions
• Minor bugfixes