doesn't matter if any of the two extensions are in. As soon as one of the two is in, the minor problem is noticable. Could be the CPU just not having enough juice.
EDIT: Definetly not emulator related so you can breath in ease Manuel I have just tested the entire setup on a imensly fast machine and its 99,99% the real thing. very very very smooth. So this is definetly a CPU thingy what I haven't tried so far is to pump up the process priority to -20 and see what happens then. Stay tuned.
EDIT2: Pumping up the process priority did the trick. I can finish HERO and for that I need the real thing so it feels like the real thing. The chopiness I am seeing now is propably caused by my monitor. I get the same effect when I hook my laptop onto it. It doesn't do this with the real MSX but I am nearly 100% sure its the monitor
@Parn: i send you the image with instructions along. openmsx-18 is in there precompiled as well. Just head to the openmsx-18 directory and do $sudo make install
It should replace openmsx17 with version 18.
OK, good news
Might be nice to distribute this setup somewhere so many users can enjoy the results of your work!
OK, good news
Might be nice to distribute this setup somewhere so many users can enjoy the results of your work!
Working on it lets have a few test this image and see how it works for them.
@Manuel:
About problem nr1. The emulation is plain perfect but I can't help to notice that the emulator very gently slows down the longer it runs. The faster the machine the longer it takes for this effect to kick in. I currently use HERO as a reference because I know this game by hard. I very subjectivly meassure emulation using this game by simply playing and reaching stages. On laptop (i7 @ 4Ghz) The emulation runs perfectly up until level 15. On the pi it runs perfectly until level 4 and up. What I witness is (explained before but lets explain again) a feeling as if 1 out of lets say 100 frames slows down or speeds up. The screen starts running choppy. Some can see the effect some don't I have asked a few people to watch and feel for themselves. The effect worsens by time but eventually stabilizes and stays at the level of maximum worseness. This max level is machine independent.
I must say this is on openmsx 17 though so maybe something has changed in the meanwhile so I will test on 18 too. This is really hard to get a hand on because its supersubtle. Need to test this on windows yet to rule out kernel/library related stuff.
@Daemos, thank you very much for sending the image. I currently have no way of improving my Pi's heat dissipation, so I won't be able to do any testing, but it's nonetheless an interesting blueprint that I will use to make my own investigation on the topic of OpenMSX's performance on Raspberry Pi. I personally suspect Raspbian isn't the most adequate environment for OpenMSX on Pi, but I still have to set aside some time to better investigate this. I've been stifled by a driver bug in my Windows machine that causes system crashes when writing non-Windows disk images to memory cards (including Linux disk images).
@Daemos can you check the openMSX memory usage over time? Also, did you keep reverse enabled, or is it disabled?
reverse is disabled. Will check memory usage and see what comes up there.
Ok memory usage is stable. Climbs up to 1 gig max then never goes above that number. Funny thing is that with reverse enabled there is no difference unless I reverse a few steps. At that moment the problem seems to reset.
@ren: good one, will investigate that one too.