0xff

The recent issue with fMSX 3.5.3 (fw 1.50 version) prompted me to rethink future support for 1.50/kxploit executables. One option was to regress to an earlier version of the library, dropping any of the adhoc functionality; another was to simply stop working on versions for 1.50.

I (grudgingly) decided to stop providing support for fw 1.50 - reasons for this being threefold - a) the ps2dev community recommends moving away from this firmware, as continuing support for it is getting more challenging (flash0 memory being one reason); b) running simple applications in kernel mode seems counter-intuitive, and c) it’s becoming exceedingly more difficult to cope with two distinct programming models.

The emulators that are currently up will probably be the last ones with support for firmware 1.50; all future emulators are likely to only run on firmware 2.00 and greater.

UPDATE Wow, what a coincidence

As promised, ColEm has been updated. Here are the changes:

• PSP version brought up to date with the official release (changes are mostly internal)
• Replaced the rendering engine with a more stable one
• When switching games, latest save state will be automatically highlighted

Download

While I continue waiting for days on end for my next GameFly rental, I wanted to let you know what’s been going on lately.

First, fMSX 2.5.1 release is coming up tomorrow. This release should fix mostly sound issues, and bring fMSX PSP up to par with the official distribution.

Second, a ColEm release should be around the corner, though it will mostly be a maintenance release.

Finally, it may interest some of you to know that I’m currently trying to implement adhoc gameplay for one (and then many?) of the emulators. Things are going well so far, so here’s to hoping…

UPDATE Gaah, I meant 3.5.1, not  2.5.1

As many of you may have noticed, fMSX has recently been updated to version 2.5. For us PSP folk, the importance of the release is mainly in its fix of sound playback when loading save states. This is a great fix, as I often saved two separate states when playing SD Snatcher, to prevent this sort of issue.

Another great feature of this release is that the source code now includes full Unix code, which may help others port this great emulator to other platforms.

Stay tuned!

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.

When I was just starting to program for the PSP, I envisioned first doing a port of fMSX, then a port of an emulator specifically for emulating arcade versions of Mortal Kombat games 1-3. Since I don’t think any emulators other than MAME support the games (and MAME’s source is a tangled mess), I doubt that phase will ever come to fruition.

Most recently I’ve also considered porting older games, however, and if someone else doesn’t do them first (I hope they do), I just might do a port myself. Two obvious choices right now are OpenTyrian, a rewrite of Tyrian, and Wargus, the Warcraft II-compatible RTS engine based on Stratagus. I prefer not to port these projects myself, as they’re both based on SDL, and I happen to have an inherent dislike for hardware abstraction frameworks.

If you’re looking for an interesting port project, both of these games should be a welcome distraction from the many flavors of DooM already ported to the PSP.

One question that I’ve been asked time and time again (and most recently by zx-81) is “why bother porting an emulator when there are other ports already?” This question was beaten to death when SMS Plus PSP was first released, and still comes up occasionally.

The number one reason is simply that I enjoy porting software to PSP, especially classic computer emulators. I like pushing the limits and capabilities of the (yet unnamed) psp library that I’ve been developing since the first fMSX release. The fact that another emulator may already exist (and may, in fact, be better) is a non-issue for me, as I don’t do it for any reason other than my personal satisfaction.

Second reason is that I believe having a choice in emulators is great. The only reason I got into programming for PSP is because I thought that the MSX emulators of the time could be a lot better.

I attempt to port in a manner that makes it possible to merge the PSP port with the main branch of the emulator, and I’m happy to let any interested maintainer of the emulator merge my code with theirs. I don’t generally touch emulation code, unless it results in significant optimization—the only exception to this rule has so far been fMSX and inclusion of SCC/MSXMusic/MSXAudio - and it’s largely thanks to the efforts of Vincent van Dam and his excellent fMSX SDL port.

When possible, I attempt to port a different emulator than one that’s already available. For example, as mentioned earlier, Caprice32 was not my first choice for a CPC emulator. Unfortunately, Arnold’s performance was nowhere near “acceptable,” so Caprice was my second choice.

And finally, there are a number of ported, working, but unfinished emulators that are currently littering my svn repository’s trunk branch, some of which may eventually see the light of day.

Hope this was enlightening. Comments are welcome.

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.

While porting an emulator, often times it’s helpful to see how authors of other ports handle certain challenges. Over time, a number of small issues have prompted me to look for possible answers in other applications.

Quite often, source code for a similar port is freely available. Too often, however, it’s not. The surprising thing is that the people who hide the source code aren’t the authors of the emulator - it’s the authors of the port.

As someone who works off of open-source (not necessarily by any official definition) projects, I welcome all private developers to use my code and learn from it–my only request is that copied code is given proper credit.

I would like to see all authors that port open-source software release their code. This is especially relevant to the PSP subculture, as the availability of documentation is relatively scarce. Your work will help others, and will gain your port more popularity, as others will acknowledge your contribution.

Hiding code for a pending “cleanup” (which frequently, never happens) shouldn’t be reason enough to hide it. Even kludgy code is better than no code.

One of the advantages of using a detailed visitor reporting service, like Google Analytics, is the ability to get a better idea of the popularity of specific sites with specific countries.

For those who are interested, here’s a breakdown of various emulators, in order of popularity, then by country (top 5):

1. Neopop (Japan, U.S., France, Germany, U.K.)
2. fMSX (Japan, U.S., Singapore, Spain, Germany)
3. SMS Plus (U.S., Japan, France, Singapore, Germany)
4. Atari800 (U.S., Germany, Singapore, U.K., Poland)

ColEm is by far the least popular, even edged out by the listing page (psp.akop.org). Some of the odder trends (at least in my opinion):

• fMSX is the second most popular emulator in the U.S. (it was barely released here, and is virtually unknown)
• Singapore appears in the top 5 for 3 emulators
• Russia is in the number 7 spot for Atari800. Judging by the emails I receive, quite a few of the users are Russian. I first came across the Atari 130XE in the former Soviet Union, where it was quite popular at one point

Perhaps the least surprising trend of all is that Japan and U.S. are usually the top 2 countries for visits.

Of course, this doesn’t take into account the number of people who download emulators directly from other sites, such as dcemu.co.uk