As someone who looks forward to new Ubuntu releases twice a year, I was disappointed to find that I couldn’t get psptoolchain to compile under version 8.10, which includes a new version of GCC. The only workaround to this is to downgrade to a previous version of GCC, and I’m still looking for a way to regress without breaking default Ubuntu packaging. If you’re a PSP developer running Ubuntu, I’d advise against upgrading to 8.10 for the moment.

UPDATE Please see the workaround

There’s a new strangely sycophantic article on Slashdot, regarding the start of pre-orders for Pandora, a new open-source handheld console that a number of gaming sites have already mentioned. The article spawned a number of comments regarding the other handhelds currently available (such as the PSP and the GP2X), and the “openness” of those systems to “homebrew” development. I left the following comment, which I feel fairly well summarizes the state of development on the PSP:

I’m a PSP developer, and I must admit that while getting documentation for the SDK is tough, there are more than enough examples around for anyone with common sense to pick up on the API fairly quickly. Plus, the folks at the ps2dev.org forum are exceptionally helpful (as long as your question isn’t along the lines of ‘what’s a for loop?’)

PSP development at this point (and probably forever) is very much an exercise in reverse engineering, even for the client C/C++ developer (as opposed to the brilliant minds who reverse-engineered the SDK). This explains the handful of applications/emulators that actually make use of WiFi and/or the ME processor. That said, PSP development is highly rewarding, if only in a personal sense.

That said, I wish the Pandora folks good luck. I’m a huge proponent of open-source software, and if Pandora succeeds, perhaps Sony will be persuaded to make the PSP more open to development, and maybe release an SDK.

Comments are welcome.

Flavor recently posted news that he considers RACE! PSP the official PSP port of RACE, and that he doesn’t plan on continuing another port. He also mentioned a new undocumented button (not present on the consumer handheld) discovered by FluBBa, the author of an NGPC emulator for GBA that enables hidden debugging features in several NGP games (namely, Card Fighters’ Clash, Card Fighters’ Clash 2, and Dokodemo Mahjong); this feature will be added in the next release of RACE! PSP; ideally, with the ability to save state.

For a while now, I’ve been seriously considering utilizing PSP’s Media Engine (ME) processor in fMSX PSP, to (potentially) enable full-speed emulation with MSX Audio and MSX Music enabled. Currently, enabling any of the two requires emulation at 333 MHz, while enabling both makes the emulator near-unplayable. Of course, utilizing the ME opens up a whole new slew of issues, not the least of which is the challenge presented by parallel programming. If fMSX/ME succeeds, Handy may be finally coaxed to run full-speed.

RACE! PSP was one of the emulators I reported to be working on; another one is still in the initial stages. If things pan out, there may be another pre-release riddle, which should give you an idea of which system it will emulate. Thankfully, I received my replacement video card yesterday, so I can finally continue work again.

Finally, I’ve added a new poll; if you have some time, please take it.

CORRECTION The discoverer of the undocumented button was not porting RACE to NDS, he’s actually writing a new emulator for the GBA (thanks Flavor)

UPDATE The poll should now be fixed

In the process of making changes to psplib’s video rendering routines, I came across a strange problem - calling a certain library function resulted in screen and palette corruption. Since the function was used to access contents of the VRAM, I figured it was because I was writing to the wrong location in memory somewhere.

The strange thing was that I had a similar function already in place, and except for some minor semantic differences, the code was the same. Even more surprisingly, commenting out the code that called the function did not help - the only thing that did was completely removing the function’s definition.

I finally tracked down the problem to the compiler’s optimization flag (O2). Completely disabling optimization with (-O0) got rid of the corruption. I’m not sure if this will have any detrimental effects on the rendering library in terms of speed (I doubt that it will, as psplib’s renderer is extremely frugal), but I suppose that I’ll eventually find out.

UPDATE It looks like optimization (much like the proverbial chinaman) is not the main issue here. While I haven’t completely resolved the issue, it is fairly certain that it’s related to reading/writing to VRAM. The issue seems to be commonplace, and I’ve found possible explanations here and here (see section marked Important).

After some discussion at worldofspectrum, I learned that the problem with Fuse PSP is psplib’s restrictive disclaimer, which prohibited commercial use of the code. psplib is the library that I initially wrote for fMSX PSP; it is common to all the ports I’ve done to date. While the disclaimer wasn’t actually meant to serve as a legal document (as I mentioned in the forum, I’ve always considered psplib public domain software), Philip’s argument is that it went against GPL, which prohibits user restrictions.

To resolve this incompatibility, I’ve decided to license psplib under the GPL. The library is already undergoing structural changes (parts of it have needed tweaks for a while now), so now seems as good a time as any. The updated library is in the trunk branch of Fuse PSP’s repository.

Fuse PSP binaries are once again downloadable.

One feature that both fMSX and Atari800 could use is auto ROM type selection, as I’m sure I’m not the only person who finds selecting correct type of ROM an annoyance. I’d like to ask those of you who are dedicated fans of fMSX or Atari800 for help.

The method I have planned involves mapping a ROM CRC32 value to specific cart type, maintaining the settings in a growing list. Bunch of these lists would eventually be consolidated into a larger “super list” that would be included with the emulators, effectively eliminating the process of cart type selection (for vast majority of carts, anyway).

If anyone is interested in working to create such lists, please let me know by leaving a comment. Alternatively, if you’re aware of an existing list (perhaps for a different port), it would be great if you could point out the location. Thanks

If you’re a PSP developer and/or considering developing wifi-enabled applications for the PSP, you might find this Adhoc Matching Diagram helpful. While it doesn’t explain everything in detail, it provides general idea on the steps that the generic PSP wi-fi enabled application takes, when setting up matching.

Ad-hoc matching is the initial step of setting up communication between PSP units - selecting which machines are going to participate in a communication session. It generally entails sending connection requests, and simultaneously listening for connection-related events (such as incoming connection requests). Because communication is peer-to-peer, the notion of host/client is implied - usually the machine requesting a connection is considered the client, while the machine receiving the connection request is the host.

The recent drought of new releases may have some of you wondering if development has stopped. The answer is no, not really - though if you want someone to blame, blame Microsoft and the XBOX 360 - it’s been sucking up more of my free time than my trusty old PS2 (for those who may be wondering, I rarely use the PSP for anything other than emulation). That, and the heavier workload (at work) are the reasons why development is sluggish.

Good news, however, is that development hasn’t stopped - look forward to some interesting releases in the time to come.

Oh, and Happy New Year. Let’s take this time to thank the generous souls behind the PSP SDK for continuing to provide us with many hours of coding (and classic gaming) goodness. If it wasn’t for them, the PSP would be just another portable gaming console. Thanks, guys.

I’ve been spending some time researching the Media Engine processor lately, to see how it can be incorporated into any of the current emulators. The gist of it is that the sound engine would be running in a separate process on another processor, freeing the main processor to do other tasks.

Gut feeling suggests that in the case of Handy, the emulator would run at full speed at 333MHz (since at that frequency, performance is almost borderline already — for most games, anyway).

Ultimately what makes programming the ME a challenge is a) interprocess communication (which can quickly become a nightmare), and b) lack of good documentation. Here’s to hoping.

As what should be great news to all PlayStation Portable emulation fans, various developers are taking it upon themselves to port various “inactive” (on hiatus or permanently stopped)  classic PSP emulators to the new PSP Slim. dcemu.co.uk reports that at least two emulators have already been ported by someone other than the original author - Snes9xTYL 0.4.2 and NJ’s various emulators.