Quote:

And how about openMSX? Is an openMSX version of an MSX emulator for Symbian a reasonable option?

Series60 proccesor is a Risc ARM at 104 Mhz. It is enoguh to handle fMSX emulator, but I doubt that it could handle openMSX at reasonable speed, since openMSX is a much heavier emulator (also much more powerful...)

Yeah, but openMSX is very modular, right? So it is easy to make some kind of minimal configuration?

Well... If you take into account openMSX uses sub-instruction accuracy on the Z80 (It emulates every T-state seperately, and not just the whole instruction), and that's just one example.
fMSX is a piece of cake, compared to that.

GuyveR800: So you think a Symbian version of openMSX which runs on current Symbian OS based phones is a no go? First, the phones must have more powerful CPUs?

Latok, the logic of the fMSX core is almost intact. Perhaps the biggest difference is that the original fMSX is C code but in my version the core is rewritten in C++ and I don't have any static global data like in the original where almost all data is static global.

I don't know enough about the internal working of openMSX but I suppose it is more complex like GuyveR800 said and thus probably it would be slower. My original goal with the emulator was to be able to play MSX games, not perfect MSX emulation, and that's why I chose fMSX as the base (and also because I knew it had already been ported to numerous platforms successfully before). Perhaps someone who understands openMSX architecture well enough can comment on its possibilites on Symbian OS. It's not just the CPU power but also what other special requirements it has on the underlying OS (like timing for example).

Sousuke, the directory structures for the emulator are the same in a and b version. Like already pointed out by Latok and karloch, direct file transfer from/to the emulator is not really necessary as it is possible to transfer files with the phones' PC suite software. Nevertheless, I feel that the ROMPackager is a necessary tool for those that do not wish to handle files directly and prefer SIS packets. The use of separate UIDs for the ROM SIS files would definetely make things easier from dependency point of view so if you have time to implement that I think it would be a good enhancement. Thank you for your continuing interest in the emulator and your development efforts with the ROMPackager, I'm sure the users of the emulator have found it useful!

Quote:

(..) the ROMPackager, I'm sure the users of the emulator have found it useful!

You can bet for it

I really would like to see a reaction from the openMSX team on my openMSX for Symbian (series 60) phones question

MTH, please?

Quote:

Perhaps someone who understands openMSX architecture well enough can comment on its possibilites on Symbian OS. It's not just the CPU power but also what other special requirements it has on the underlying OS (like timing for example).

The short answer: it is possible, but it will take some work.

openMSX was developed on Linux and has been ported to Windows (stable port by Reikan, part of release) and Mac OS X (experimental port by Jalu). It has not been ported to embedded systems yet. All changes made in ports are integrated into the main CVS archive; by using a single source tree, all ports can profit from bug fixes, optimizations and new features that are added to the core.

openMSX is written in C++. Our main compiler is GCC 3.x, but we also added support for ICC 8.0 (Intel's compiler) recently. It seems the compiler for Symbian is based on GCC, but I couldn't find the version it is based on. Using a GCC 2.95-based compiler would require some workarounds, since the standard library implementation (libstdc++) of GCC 2.95 is incomplete.

The libraries we use are SDL, SDL_Image, libpng and zlib. SDL_Image and libpng are used for the console background and screenshot features, which you probably don't really need on a phone, so you could disable those features and get rid of the library dependencies. zlib is used to read ROMs and disk images from ZIP and gzip files. I don't know whether the ROMPacker tool already takes care of compression, or whether it is installation only. But in any case, it is possible to drop support for compressed ROM/DSK images if needed.

For SDL, the situation is different. Currently, there are many parts of openMSX that depend on SDL. You could try to use SDL for Symbian (koti.mbnet.fi/~haviital/), but it's a work in progress, I don't know how useful it is right now. Alternatively, you could help us remove the SDL dependencies from openMSX, so that SDL becomes optional instead of mandatory. I want to do that anyway, but so far it had a low priority.

Requirements on the platform are relatively simple. For video, we need some kind of framebuffer to render to. We can also render to OpenGL, but that's not an option yet on embedded systems, I guess. For sound, we need a mono or stereo PCM channel to write the samples to; openMSX does all mixing internally. A timer is needed for syncing emulation speed to realtime speed; it should be possible to get ticks at 50 and 60Hz. openMSX does not use threads for emulation, only the sound callback is a separate thread (provided by SDL).

The executable size of openMSX on desktops is rather large: about 2MB currently. It can be reduced a lot by disabling features: no debugging, no console, using only 1 of the 2 OPLL cores. For rendering, you only need the low-res renderer (no GL rendering, no scalers, no scanline emulation) and if you know your graphics device is 16bpp, you can get rid of the 8bpp and 32bpp rendering code. And then there are parts which can be coded more efficiently, for example we use a bit too much inlining currently; inlining could be disabled for any routine of more than 1 line that is not critical for performance. Also the number of STL template expansions could be reduced probably. I'm convinced the executable size can be reduced below 1MB, but I'm not sure how much smaller it could become. Note that the size mentioned is on x86, maybe compiling for ARM will reduce the size already. Also compiling with "-Os" saves about 20% in size compared to "-O2".

I don't know the exact memory use of openMSX, but I don't think it's very large. Ofcourse the RAM use depends on the emulated MSX: if you want 1MB of sample RAM in the MoonSound, openMSX will use 1MB more. Memory is only allocated when needed, so for example if you emulate MSX1, just 16K of VRAM is allocated; if you don't use MSX-AUDIO, no sample RAM will be allocated for it etc.

About performance: by far the most performance critical part is the rendering; it will help a lot to write an optimized renderer. If there are a lot of channels, sound emulation can take a lot of CPU time as well, but unless you have a game with MoonSound (24 channels) or MB stereo (19 channels) music, it's probably not critical. There is some inefficiency in the handling of VRAM updates, this can lead to slowdowns, especially when emulating a turbo R. This can be solved either by improving the VRAM update code or by disabling the display caching mechanism. If the scanline conversion routines are fast enough, cache administration may take more time than converting every frame (like fMSX does). Also disabling the cache will save some memory.

So I think using openMSX for an embedded system is possible, but it will require some to the openMSX core and ofcourse system dependent code will have to be added. I'm willing to help with the changes to the core, but I don't have a fancy mobile phone, so the platform specific code would be up to you.

The advantages of using openMSX:

• accurate emulation
  
• lots of MSX hardware supported
  
• open development process
  

The disadvantages of using openMSX:

• will require some changes to make it suitable for embedded systems
  
• code is more complex compared to fMSX
  

Anyway, if you're interested in discussing the options, you can reply here, post a message to the openmsx-devel mailinglist or talk to the openMSX developers on #openmsx on irc.freenode.net. Our home page is openmsx.sourceforge.net/.

Thanks for your lengthy explanations. Firstly, the GCC used with current Symbian OS releases is based on v2.95. The C++ STL is not supported/present at all. Standard C/POSIX library (stdlib) is included, but all functions are not supported and normally native Symbian OS applications don't use it. In my fMSX port, for example, I didn't link to stdlib because it increases the executable size significantly and more or less corresponding functions can anyway be found from Symbian OS's own APIs. Things like string and memory handling for example are very different from standard C++ approach. An adapted version of zlib is a part of Symbian OS.

To me it seems like some work indeed would be required...

BTW, as I mentioned before I don't have any global data in fMSX/S60... that was not completely a design choice I made but something that Symbian OS enforces on all applications -- there is a way to have writable global data in applications but it means that the application must be divided into two separate processes.

Well, if anyone should feel confident enough to pursue a Symbian OS port of openMSX, I will be glad to help if I can but at the moment I think I will concentrate on putting some of the missing things to fMSX/S60 instead. Today I implemented my autorun feature for disks -- that is, you can select a single file from an MSX disk and the emulator will automatically feed the correct BASIC command to load&run that file when you launch the emulator. This is something I've had for tapes already and I think it's rather useful since typing commands on a phone is a bit difficult

Jr, first of all: great work you're doing! Keep up the good work!

About that autorun feature: I have also been thinking about it... If you have good ideas about how to implement this, and you would like to share them, please let the openMSX team know. I hope you will help us to implement it on openMSX too

But, a question first: what do you mean with 'select a file from a disk'? You also have a disk image browser?

Anyway, I think that autorun features would be nice. Autoloading a tape e.g. is also a good idea. Or a basic program (be put automatically on a disk image, e.g.) ... or...

Manuel, thanks for your kind words. I feel the same about openMSX even if I don't have the time to make a Symbian OS port right now

To answer your question, yes, as a side track to the disk autorun I also had to implement a disk image browser. It's a simple one, I don't try to parse copy protected disks or such, I just read the disk metrics from the boot sector and then read in the first FAT and root directory. For each file in the root directory I detect the type of the file and finally I present the user of the emulator a list of files on the root directory to choose from. At the moment only files that can be RUN or BLOADed from BASIC can be selected because I haven't had time to implement this for MSX-DOS yet.

For tapes, I don't have a tape image browser yet, although I'm thinking about doing it as it would also enable a "fast forward" and partial rewind (currently you can only rewind to the beginning of the tape) feature for tapes. So at the moment for tapes the emulator will always launch the first file on the tape, if it can be RUN, CLOAD & RUN or BLOADed.

I know you can do the same kind of thing using AUTOEXEC.BAS that prints a small menu where you can choose from the games present on the disk using numbers but this autorun is a bit more general and you don't need to write that AUTOEXEC program.

This saves space on the phones as they have limited storage capacity and it is better to store multiple games on one disk image than have a separate disk image for each of them.

There is no secret about the implementation, even if I'm not distributing my source code for the emulator. I already revealed it earlier on this forum when I did the autorun for tapes. I simply hook the PINLIN routine in the BIOS that BASIC uses for reading one line of input from the user. When this routine is called for the first time, I know that the system has booted and has now entered the BASIC prompt. Then I fill in the BASIC keyboard buffer with the command(s) needed to load&run the selected file. And that's it. As I said, for MSX-DOS I haven't yet taken a look at how it reads user commands but I presume it is something similar that can be hooked.

Quote:

This saves space on the phones as they have limited storage capacity and it is better to store multiple games on one disk image than have a separate disk image for each of them.

An alternative to storing multiple games on one disk image to save space, would be decreasing the size of a disk image itself. A simple way would be to defragment it and leave out all empty sectors. Or you could compress the image, which has the advantage it also works for sector loaders.

Another approach is to use "dir-as-disk", meaning that a directory on the host machine is represented as a disk in the emulated MSX. openMSX implements this by building a virtual disk image in memory. The first MSX emulator that had this feature was the CJS emulator (veteran emulator users will remember this one), which implemented it by capturing calls to the BDOS routines, in the same way fMSX handles sector I/O. You could even combine "dir-as-disk" with compression, by using an archive (ZIP/LZH/PMA) per disk instead of a directory.

In fMSX/S60 I already support GZipped disk/tape/rom images directly, and I suppose reading from "partial" disk images should also work (i.e. if the empty sectors in the end of the disk are not present in the disk image file at all) but when creating an empty disk file I currently create a full empty disk image and writing to a non-existent sector might not work (I haven't tried).

However, even compressed disk images waste some space if you only have a few files per disk and that's why I implemented the possibility to run a specific file from a disk in BASIC.

The support for a "dir-as-disk" using an archive per disk sounds tempting since some of the software is distributed as normal archives and at the moment you would need to create a disk image to hold the files if you wanted to use the files with fMSX/S60. I'll append that on my to-do list... I might have to go in the CJS direction in the implementation, though, as there is no memory to "waste" on a phone for a virtual disk image.