Symbian emulator?

Umm... I was originally planning to keep the b version up to date along with the d version but haven't done so as you probably have noticed. Main reasons for this are that

i) I had to write a completely new launcher UI for the d version and I felt it was unnecessary work to port that code to the b version which already has a working launcher UI but as a side effect of this the b and d versions are rather different because the launcher code also contains the code which acts as the emulation core's interface towards OS services, and
ii) as many recent phone models have more processing power, I also added some level of complexity to the emulator architecture in the d version allowing a bit nicer internal architecture and thus enabling some things which would have been very tedious to implement previously - while I believe these architectural changes shouldn't cause too big performance hits they nevertheless do have an impact and on some older phone models this might not be worth the extra features the new architecture brings.

The S80 port of the emulator is very close to the d version of fMSX/S60 so it is definetely not impossible to have all the same stuff running on older Symbian OS. I'll think about it -- of course releasing v1.15 as d and b versions would mean delaying the release for some time to allow porting of the d version code to the b version and along that the b version would need to adopt the not-so-nice-looking launcher UI of the d version. Anyway I still have some new stuff to develop for v1.15 which I have been thinking about but have not yet had the time to implement. It would naturally be nice to update the b version to 1.15 to include some bug fixes which have only been done to the d version branch such as the save/load state fix and the upcoming VDP search command fix.

Allright D-Tail (and others), v1.16b and v1.16d are available now. If you experience too much slowdowns with the 1.16b version you can always switch back to 1.10b. It is important to note that the two versions are now identical in features otherwise except for the display resolution support: 1.16b only supports the "legacy" 176x208 resolution whereas 1.16d supports also the double resolution 352x416 and QVGA, both in landscape and portrait orientation. In practice this means for example that you need to move your game files and system ROMs to the new location if you're upgrading from 1.10b and switch to using a 48kB MSX2+ sub ROM.

To justify the d release, I made some small bug fixes in the launcher UI and added support for cheating -- you can access it through the MSX state menu while the emulator is paused. Being the lazy guy I am, I didn't implement any possibility to manually enter cheats (yet) but instead the emulator is able to import blueMSX's .mcf cheat files and trainer procedures from openMSX's trainers.tcl file. The parser is rather simple so there may be cases where it does not recognize the cheat data correctly, especially for the TCL file I am only supporting straight poke's, no for-loops or other "advanced" things I also had to make some (educated?) guesses about the .mcf file format as there appears to be no explanation for it in blueMSX help -- especially the first and fourth digits which seem to be always zero so at the moment those fields are simply ignored. Just place the .mcf files or trainers.tcl in the same folder with your game files and the emulator should find them.

Something that I already did in v1.15 or v1.14 (I forgot which one) for my emulator that I would really like to see support for in openMSX which I use on my Mac: when using zipped files, it would help a lot if the emulator would see if there is a proper file inside instead of taking the first file in the archive. For example many of the MSXdev'06 entries do not have the actual .rom file inside the zip as the first file so the zip cannot be used as such with openMSX but instead you need to extract the .rom file from it to be able to use it. It would be rather simple to check the zip directory for a *.rom pattern and pick the correct file if one is found. Perhaps it's just my machine acting weird but I'm guessing this simply hasn't been implemented in openMSX. I realize this is not the correct place to for openMSX feature requests but since I started to write about it I decided to finish the text Thanks, over and out.

jr, can you please say a couple of words in the Sansa/Rockbox topic ? Thank you in advance.

Does this happen in all file selector screens or just the save state list?

Good catch I only tested the 1.16b version under S60 emulator in Windows, where it works correctly. The problem is in the GCC compiler which generates incorrect code for certain inline expressions in C++ class constructor's initializer list. The Windows version is compiled with a different compiler so the bug does not appear there. Also the "d" variant of the emulator is compiled with another compiler so no problems visible there.

I made a workaround for it, and now at least after a quick test the screens seem to work correctly on my 6630. I'll upload a new version (1.18b) to my website later today. It contains some other smaller internal fixes as well.