openMSX post-0.7.0 build available for beta testing

I'm not sure if this qualifies as a bug, but the included C-BIOS roms have the high bit of 002b set, so those machines may get identified as 50Hz, while they run at 60Hz.

Other than that, runs fine on Windows XP.

As promised, I have tested openMSX on Vista 32-bit edition.

It runs stable and smooth. I have noticed that with the SDLGL-PP renderer the CPU usage is significantly higher then with standard SDL renderer (70% CPU usage versus 20% CPU usage), which I find strange. As far as I know, the work is offloaded to the graphics card by the GL renderer (I have an nvidia geforce 8600M GS graphics chip).

I have also tried keyboard support with my Azerty keyboard. It works less well then under linux. For one reason or another characters that must be entered with the right-alt key pressed, do not get entered. Seems to be some issue in the SDL library; openMSX does not receive any event.

I have also tried to copy&paste characters through the text-input window of catapult. It works fine for normal characters but not (yet?) for special characters (accented characters, katakana/hiragana characters). Though, special characters that I can enter on my keyboard (e.g. accented characters) work fine in the openMSX console itself. Have not managed to enter japanese characters on my keyboard under windows. Must still figure out how to get the SCIM support under windows enabled, so I could not test the katakana support in the openMSX console.

Ps: regarding SDL versus SDLGL-PP: under linux (freshly build from SVN), when using the SDL renderer, openMSX uses more CPU then when using the SDLGL-PP renderer (70% respectively 50%), though with the SDL renderer, a scroll-text in a 'heavy' demo (SME3 Promo 1, opening screen with music playing on MSX Audio, MSX Music, one SCC and the PSG) runs more smoothly then with the GL renderer, despite the lower CPU load in the GL renderer.

Alex: thanks a lot for testing (you should join our IRC channel some time again!).

- The catapult/keyboard problems: we'll ask mfeingol when he's back from holidays
- About CPU usage: this might be a driver problem as well (see page 1 of this thread for some hints regarding this). If everything went OK, SDLGL-PP CPU usage should be a lot smaller than SDL usage. E.g. running your SME3 Promo 1 on turboR with SDLGL-PP and 4x scaling (with several effects) takes about 3% CPU on my Linux box. With SDL renderer (3x scaling, which is the max): 7.5% CPU. (But this is a fat PC (Intel 9450) with fat videocard (nVidia 8800GT)...)
- About smooth scrolls: try setting the 'maxframeskip' setting to 0. Better comparisions are time comparisons for a fixed amount of rendering by the way, see also page 1 of this thread.
- About the assert: we can reproduce it and Wouter is investigating.

Thanks for reporting in any case We need more feedback like this

I have downloaded the latest linux version. Sound bug is indeed fixed :-)

Regarding the problem with the GL-renderer on linux (the less smooth scroll that I reported): the problem is not only with the scroll but also with the sound. At the moment that the scroll gets shortly halted, the sound is also shortly interrupted. I suppose it is some issue in the nvidia driver itself that keeps the CPU occupied for a too long period. Hard to trace down, those kind of issues :-(

... Or let us know how this works: openmsx.sf.net/temp/catapult-0.7.1-dev9271-VC-Win32.zip