With many thanks to GucciPAPA for sending us his Korean Lumines UMD, and to everyone else who offered to send theirs (including NeofaN, KkalKkal, Jabum, www.yourpsp.in ), we're proud to present an updated version of the v3.50 Lumines HEN and downgrader.

The only change in this version is support for the Korean version of Lumines (ULKS46005). This now means that the downgrader should work on all unpatched versions of Lumines, on all regions of PSP, and all current PSP hardware, on firmware v3.50. If you have a lower firmware, you can upgrade to v3.50. If you have v3.51, then there is no way to downgrade at this time.

For various further information about the downgrader, please read our other articles:

Original downgrader release post
Downgrader FAQs
More downgrader information
Information about patched Lumines versions

Jas0nuk and lan.st admin, have just told us of the construction of a new 3.51 Custom Firmware.

A team of around 10 coders, who want to remain anonymous for the moment, have started, as for the 3.51 M33, to reverse the DA firmwares, to create their own CF 3.51.

Unlike the 3.51 M33, they do not wish simply to make a “3.51 OE”, as the 3.51 M33, but they wish to improve it, to make a version of a quality equivalent or higher than the Firmwares of Dark_AleX.

Currently under development, a date of release is not in talk.

This update fixes a secondary effect that 3.51 wlan.prx caused in 1.50 wlan.prx,
which made wlan homebrew not to work.

Ths issue was caused by sony code of 3.51 wlan.prx, and not by M33 code.
It doesn't happen replacing 3.51 wlan.prx with 3.40 one.

- M33 Team

it use TA-085 PCB
it has 64MB main memory
(PSP-1000 main memory is 32MB)
it can use USB to charge battery
1200mAh battery can play about 3-6hours
(same as PSP-1000, but PSP-1000 use 1800mAh battery)
can't use PSP-1000 remote in PSP-2000
TV output
WLAN switch on top

Tracking down the SSB Dynarec Bug

Yesterday I said I'd provide some more details about the Super Smash Bros. dynarec fix. The actual fix is fairly straightforward, but I thought the process of tracking down the issue was quite interesting and worthy of a couple of blog posts.

When I first started looking at SSB I noted that although the game ran fine without dynarec, it would always hang when trying to enter the main entry with dynarec enabled.

I've been programming professionally for around 6 years now and I can safely say that debugging dynarec bugs is one of the hardest categories of problems I've ever had to work on. For a start, because the code is generated on the fly, you don't have the luxury of source level debugging, and without spending time reverse engineering the original rom image, you don't even know what the generated dynarec code is meant to be doing. It's very much like working blindfolded.

And it gets even worse. I've fixed dynarec problems in the past which were the result of generating incorrect code for a fragment over 500 million instructions into emulation. This would be bad enough, but it can be many thousands of instructions later before this causes emulation finally diverges from the correct path. Just identifying the exact point at which the emulation starts to diverge from the correct sequence of instructions can be like finding a needle in particularly large haystack. While blindfolded

Over the years of trying to debug problems like these I've built up a set of tools and learned a few tricks along the way which you might find quite interesting. Although I'm going to talk about them in the context of tracking down this dynarec issue, I've found some of the techniques useful in solving other problems so you might find other ways of applying them too.

One of the first things I do when trying to identify a dynarec issue with Daedalus is to see if the problem is reproducible on the PC build of the emulator. Although it is possible to use GDB with PSPLink, I've never got this up and running and I'm much more comfortable debugging with Visual Studio. Also, working with the PC build is usually much faster than working with the PSP build (debug builds run around 10x faster on the PC, and build times are much quicker.)

Not all dynarec issues can be debugged in this way - the PSP and PC builds have different code generation back-ends (i.e. MIPS and x86 code generation respectively) so bugs in the MIPS code generation won't usually be reproducible in the PC build. The dynarec system in Daedalus shares a common frontend (trace selection and recording) between the two platforms, which means that if I can reproduce the problem on both platforms, I can narrow down the likely location of the bug to this area.

Fortunately this particular bug manifested itself in both the PC and the PSP builds, so I knew that if I fixed the bug on the PC build, it should fix the PSP build too. What I needed to find out next is what the emulator was doing differently when dynarec was enabled compared to when it was disabled.

If dynarec is running without errors, then the sequence of executed instructions should exactly match that executed with dynarec disabled. If I could log details about all the instructions executed with dynarec disabled, and again with dynarec enabled, I should be able to compare the two logs to figure out the exact point at which dynarec is going out of sync. This all relies on the fact that the emulator is totally deterministic, i.e. that running the emulator twice in succession with the same settings should give exactly the same results.

Unfortunately, for a variety of reasons my dynarec solution doesn't produce identical results to interpretation, the main reason being that for performance reasons I can only handle vertical blank and timer interrupts on the boundaries between fragments. For example, with dynarec disabled, the first vertical blank interrupt might occur exactly on the 625,000th instruction, but with dynarec enabled with might not occur until the 625,015th instruction. This means that the logs diverge at the instant the first VBL fires, and never regain synchronisation.

When I was originally developing the new dynarec system I put a lot of effort into writing a fragment simulator, the idea being that rather than executing the native assembly code for a given trace, I could keep track of the instructions making up the trace and interpret these individually instead. Theoretically fragment simulation is identical to dynarec code execution, even down to the way I handle VBLs and timer interrupts, and it's been very useful at identifying bugs in the dynarec code generation. What's particularly useful about fragment simulation however is that I can enable a setting which