Hi,

As I told several weeks ago at the IRC, I have a Handheld PC device (HP Jornada 720) with Debian Etch ARM installed and running like a charm. The ARM branch of Debian has also the openMSX package ready to use on ARM devices and I'm just curious of how would it works on the Jornada 720. I apt-getted the package and it installed perfectly. There are several considerations to make before:

• Jornada 720 proccessor is a StrongARM at 206 mhz, it should be capable of at least run the emulator.
• The RAM memory of the machine is 32 MB, without any swap partition available. Although lightweight kdrive X server work really well on it, I prefer to not use the X-Window to have more resources and memory available for the apps of my system.

So what I want to know:

• Is it possible to run openMSX without X-Window, by just ussing the framebuffer? (like links2 does, for example) If it is possible, how I do that?
• If I run openMSX right now from the console it exits with an error that tell me that the 640x480 resolution is not supported in my system. That is absolutely true, since the handheld screen is just 640x240. How do I change the screen resolution?

Greets!

There is an export variable that makes SDL run on framebuffer, instead of on X. I don't remember it, but google is our friend...

There is also a "window manager" program called Screen. It's just an extension to the console. I have tried it out for a few minutes just to experiment but supposedly it can run SDL applications in full screen.

Try something like:

export SDL_VIDEODRIVER=fb
(or something similar). YOu need to tell SDL to use the framebuffer videodriver.

Also, you should edit your settings.xml and set the scaling factor to "1", which will give you a 320x240 rendering output.

It works with the following:

export SDL_VIDEODRIVER=fbcon

However, I'm not able to use the scale_factor to 1 (the emulator still exists telling me that it's unable to use 640x480). Is not there any settings.xml example configuration file? Mine looks like this:

<settings>
<video>
<scale_factor>1</scale_factor>
</video>
</settings>

create this file:

/home/karloch/.openMSX/share/settings.xml

with this content:

<!DOCTYPE settings SYSTEM 'settings.dtd'>
<settings>
  <settings>
    <setting id="scale_factor">1</setting>
  </settings>
</settings>

This is the minimal settings file if you only want to override the default scale_factor, assuming that you're using openMSX 0.6.0.

Ok, the emulator finally, at least, runs. But it looks like the SDL doesn't manage well the console display. The display is duplicated along the screen (one display to the left and another to the right). Also, it's only long to half weight of the screen. It's like the resolution would be 220x120 or something like that. Of course, the CBIOS text screen can't be even read, although the blue screen and the letters are there.

karloch: I suppose it's easier to talk to us on IRC: #openMSX on Freenode.net. (I have no clue what's going on, and wouter and mth are probably capable of investigating it with you!)

Running the emulator from the X (I'm using kdrive server) will make it run like a charm, it's a lot faster that I would expected. It's a bit slower than fMSX, but this one is unable to play sound correctly on the device while openMSX does this correctly. Although openMSX is slower, Nemesis 1 was still very playable. A little speedup would make it perfect.

I have took a look to the tunning tips of the manual, but I don't know how to apply them since I don't know the settings.xml syntax and the emulator console is not very readable... Help would be appreciatted

Cool! Just get on IRC and we can give you some direct tips on how to work things out.

One thing you can do: run openMSX on a normal PC, set it up for optimal performance according to the performance tips section (simple scale_algorithm, scale_factor 1, set maxframeskip to a higher value (like 10), set the 'frequency' setting to 22050), save your settings and then copy the settings.xml file to your other device. (Or type it over...)

I suppose you don't have hardware accelerated OpenGL on that machine, which could have made some imporovements

Karloch did it

Yeah, there are still some minor problems, but this proves that openMSX is very usable on a 200MHz ARM based handheld

So, why do people keep porting fMSX???

(oops, wrong post)

Setting up openMSX on the handheld was actually easy. Just apt-get install openmsx will do most of the trick. After that, the only thing needed was to bring up the X and set the correct parameters on the settings.xml.

I must say that I tested openMSX on my handheld just for curiosity, as I though that it would be a very heavy application for it, so I was planning to use fMSX/Unix. The tests have proven me wrong. fMSX run nice but was unable to output sound correctly in my device. openMSX does this perfectly. The performace is something like this:

• MSX 1 - PSG. Game: 100% speed. Sound: 100% speed.
• MSX 1 - SCC. Game: 100% speed. Sound: near 100% speed.
• MSX 2 - SCC. Game: 100% speed. Sound: 75% speed.

It's noticeable that this is achieved using the general Debian ARM build of openMSX the it's the very same C code than the PC version.

Try compiling the sources. It might give even more speed, so that MSX2 games get right sound speed. There is a way to compile with APT, made almost as automagic as a normal apt-get install.