openMSX ARM without X-Window | MSX Resource Center (Page 2/3)

By Manuel

Ascended (19314)

19-03-2006, 22:09

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???

By Manuel

Ascended (19314)

19-03-2006, 22:10

(oops, wrong post)

By karloch

Prophet (2159)

20-03-2006, 20:07

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.

By Chardson

Champion (411)

21-03-2006, 04:43

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.

By Manuel

Ascended (19314)

21-03-2006, 14:52

Is the sound really to slow, or does it just skip parts? AFAIK it should skip parts and keep in sync. But wouter probably knows more about this.

Note that although the codebase is the same, there are some assembly routines for x86 with MMX and/or MMXext. So, if that is available, those routines will be run and not the compiled C code It's only (AFAIK) for scalers though.

You could apt-get the sources, but compiling openMSX from the original sources would work just as easily. You can even use the debian/rules script to build the package with some modified compiler flags, e.g. This script is in CVS, but is not shipped in the release, by the way.

By karloch

Prophet (2159)

22-03-2006, 01:15

Is the sound really to slow, or does it just skip parts? AFAIK it should skip parts and keep in sync. But wouter probably knows more about this.Nope, it's not skipping parts. It sounds correctly, but just slower. I prefer that than skipping parts.

Note that although the codebase is the same, there are some assembly routines for x86 with MMX and/or MMXext. So, if that is available, those routines will be run and not the compiled C code It's only (AFAIK) for scalers though.Well... since it's ARM and not x86, it won't be of use, but no scaling needed on the Jornada 720

You could apt-get the sources, but compiling openMSX from the original sources would work just as easily. You can even use the debian/rules script to build the package with some modified compiler flags, e.g. This script is in CVS, but is not shipped in the release, by the way.I know that I can autobuild from Debian sources packages (I already did it in order to install qmail on my server), but I don't like to compile on the device since it uses a CF type 1 card as storage and these cards have a limited number of writes... Compiling too much stuff (and big stuff) will short the CF card life. If some day I get a Microdrive, I won't have to worry about that anymore.

By jr

Champion (379)

22-03-2006, 18:44

ummm... if you don't mind me asking, why aren't you running the emu under Windows? I thought the Jornada 720 comes with MS Windows and openMSX should run on it as well... :-) Just curious.

By Chardson

Champion (411)

22-03-2006, 19:16

Isn't there a way to cross-compile it on a desktop?

By jr

Champion (379)

22-03-2006, 19:35

For MS Windows, I think so. At least some years ago MS offered the Windows CE cross-compiler (for PC) for free on their website. For Linux, I'm pretty sure it's possible but I'll let someone wiser give the details

By turbor

Hero (519)

22-03-2006, 23:10

Is the sound really to slow, or does it just skip parts? AFAIK it should skip parts and keep in sync. But wouter probably knows more about this.

No, you're mistaken here Quibus.
If it is SCC/PSG it should sound correct since we generate the waves correctly as requested by the SDL audio buffer. and not as most other emu's create an amount of samples depending on the emulated chips number of T-states.
if our wave creator get new settings to late (due to slow emulation) then the music will be slow but the tone should be correct.
This btw, was one of the main objectifs of our sound system when we started out .