openMSX 0.5.0

A new edition of openMSX and Catapult, its user-friendly GUI/launcher were just released. The new version of openMSX introduces new functionality, significant speedups and many bugfixes. In this newspost the most important updates are listed, you can read the release notes for details. You can download openMSX 0.5.0 here.

This release includes a complete redesign of the hardware configuration XML files. This means that you will have to update your old configuration files. More information on this can be found in the release notes. The new hardware configuration XML files contain the SHA1 sums of the required system ROMs, so you can put all your system ROMs in a ROM pool directory and openMSX will automatically find the correct ones. Settings can now be saved. By default, settings are automatically saved when openMSX exits, but you can also turn auto-saving off and save manually.

The changes you're most likely to notice:

Use of MMX to speed up video scaling considerably (mainly simple scaler)
Big speed up of scanline effect
Enabled blur effect in the SDLHi renderer (simple scaler)
Scale2x and hq2x scalers now also work in hi-res modes (screen 6 and 7)
Improvements in the 'type' command, you can use it in Catapult to copy-paste for example BASIC listings into openMSX
Improved geometry detection of disk images; MSX1Mania disks work now
MoonSound fixes
Added slotexpander extension
Emulation of the Tetris II Special Edition dongle
8kB BASIC ROMs supported and auto-detected
Added simple DC filter for cassette images: .wav files created by MicroWAVer should work now
Fixes for TC8566AF FDC (used in turbo R)
Force PSG portA to be input port. This fixes joystick and mouse reading in games that write illegal values to the PSG (Match Maniac and others)
Many other bugs were fixed, including long-standing bugs such as a VDP bug causing glitches in Andorogynus and CPU bugs causing glitches in Pennant Race and Fony Demo Disk 1

The openMSX team would like to thank everybody who contributed to this release, giving special mention to blueMSX developer Daniel Vik, who reported several bugs and offered useful code. To increase video rendering performance on Windows, the openMSX team are looking for a DirectX programmer who would like to help improving the Windows version of openMSX even more.

Relevant link: openMSX Home Page

Comments (22)

By IC

Hero (538)

18-10-2004, 23:35

I would thank the openMSX team too for this release. Good job guyz

By dvik

Paragon (1517)

18-10-2004, 23:44

Congratulations to another great release !

By Sonic_aka_T

Prophet (2365)

19-10-2004, 00:07

Yeh! Go openMSX! Next stop, V999999990!!!

May I add, I feel sorry for the poor sob that gets to translate this post... :/

By snout

Ambassador (5382)

19-10-2004, 00:09

It's great to see some speed-optimizations have been implemented. I hope someone would like to help out with implementing DirectX, that would really help increasing Windows performance.

By BiFi

Prophet (3142)

19-10-2004, 07:43

The Tetris II Special Edition dongle is either not working correctly yet, or there's something wrong with joystick port emulation. In the game the screens where you need to press a direction of trigger key (start of level, end of level statistics and password) gets pressed immediately causing the game to be resumed without you having the time to write down the password.

8 KB ROMs containing MSX-BASIC text is not conform the MSX standard.

@sonic: happy translating since you're one of the dutch translators afaik

By DarQ

Paladin (844)

19-10-2004, 13:30

great!! its time to create a deb of it

By GuyveR800

Prophet (3057)

19-10-2004, 14:45

kewl

By Manuel

Enlighted (5675)

19-10-2004, 16:58

DarQ: Maybe it's not necessary: Joost is working on complete debian package building scripts, so when he finished it, one can do
cd openMSX
debian/rules binary

and one has a complete Debian package, which can be installed right away

By NYYRIKKI

Prophet (2220)

19-10-2004, 17:18

It would be really cool, if openMSX developers could fix 8bit PCM output. (Sound is badly disortered) I just noticed, that this is not only MSX tR PCM output problem, but also SIMPL/Covox problem... I'm starting to think, that it must be then also Konami's Majutsushi and Synthesizer problem as well...

By NYYRIKKI

Prophet (2220)

19-10-2004, 17:20

Hmm... actually I just though, that key click is not syncronized either, so this problem is propably also key click problem...

By dvik

Paragon (1517)

19-10-2004, 18:28

The key click is not synched because the audio buffer is quite large. I think it is set to 2048 or 4096 samples which is about 100ms. It should be possible to use a buffer that is less than 20 ms. Then the key click will be (almost) synchronized. (I have not tried to reduce the audio buffer size though so what the limit is I don't know) More professional audio programs have a delay of 4ms or less on a fast PC.)

The other problem is probably a more generic timing bug. Sound with bad timing happens in other cases as well, for example some Moonsound demos. So it is not only a PCM bug.

By DarQ

Paladin (844)

19-10-2004, 19:08

manuel: that would be much better! ...will it end up in the debiantree?

By Manuel

Enlighted (5675)

19-10-2004, 19:31

DarQ: that's the idea. Will try to push it in.

dvik and Nyyrikki: WOuter told me he wants to try out some new methods to create the samples. So, hopefully next release it will be better.
About the delaly: I don't notice it at all on my not too fast system... 2048 samples is the default on Windows. I'm using 1024 on my system. If you set it lower, you get choppy sound (audio buffer gets empty when there are CPU load spikes...)

By dvik

Paragon (1517)

19-10-2004, 19:51

I'm not sure how the emulator is synched against the PC clock. I would think it uses 'select' or something similar somewhere (since the emu does not use 100% CPU I guess it is not polling). select has a minimum delay of 10ms so the audio chip registers are updated in 10ms bursts (probably with occasional 20ms delays). So get correct playback of samples the sound buffer needs to be larger than 20ms. This does not explain the change in tempo of audio samples though.

I tested the windows installation and I need 2048 samples @ 22.05kHz which gives a 100ms delay which makes the key klick delays more obvious. This is also a small problem when playing games like Arkanoid where it is quite important to have the sound synched to the video.
But on my Linux PC I can set the sound buffer smaller which gives better audio synchronization.

I'm looking forward to see (and hear) the new implementation of the samples.

Until then I'm very happy to use 0.5.0 which runs perfect for all other needs I have

By Manuel

Enlighted (5675)

19-10-2004, 22:00

hehe, thanks. Try 44100 with 2048. Doesn't give delays on our tester's WIndows machines. 22050 is too low anyway.

By GuyveR800

Prophet (3057)

19-10-2004, 22:37

Yeah, 22050 sucks.. You get really ugly aliasing on FM instruments and especially the cymbal drums sounds noisy... Also the keyclick sounds really bad at 22050 and there's a lot of latency... 22050 with 512 samples was ok, but with 2048 there's already a noticable lag of about half a second.
At 44100 these lags are much less noticable and the sound quality is acceptable, even though some FM instruments (try Aleste 2) still sound bad due to undersampling.

By dvik

Paragon (1517)

19-10-2004, 22:59

manuel: There will always be a delay between when the sound is generated and when it is played. With your configuration the delay is probably acceptable low but you should also be able to hear that the key click does not sound when you press a key. It will be slightly delayed. Maybe the betatesters haven't tried this. When playing demos and most games it does not matter that the audio is slightly delayed (20-50ms) so maybe they haven't noticed.
This is the way it works, so it is not a bug. It is just a configuration thing.

GuyveR800: Have you tried to use oversampling on the FM synthesizers? I'm just curious about how much better the result may be. It is not that hard to do oversampling on the FM synths and if the result is better, I think it would be nice to have the oversampling factor as a configuration parameter.

By Grauw

Paladin (1010)

20-10-2004, 00:55

I'm using a samplerate of 44100 with 2048 samples delay now... A delay of 1024 won't work, unfortunately. Overall though I notice a great performance increase in openMSX on my system! Great work guys.

By NYYRIKKI

Prophet (2220)

20-10-2004, 15:47

"syncronized" was actually a bit wrong word as in R800 mode it is not only delayed, it might be totally lost. If you just try, you'll notice, that almost every other key click will be totally disappeared.

I think, that the problem is, that in this case the whole key click "sample" is written to same address in playbuffer... I think, that it should newer happen with 44K samplerate. I think, that there is some serious trouble while sycronizeing play buffer with CPU cycle counter.

By Manuel

Enlighted (5675)

20-10-2004, 16:11

Note that these issues are already known:
http://sourceforge.net/tracker/index.php?func=detail&aid=670625&group_id=38274&atid=421861
http://sourceforge.net/tracker/index.php?func=detail&aid=656395&group_id=38274&atid=421861

The key click thing on R800: as far as I understood from Wouter, the click lasts shorter than some cycle, so, it's getting lost. Making an envelope of it should fix it. Ask wouter in #openMSX on irc.freenode.net for more details

By dvik

Paragon (1517)

20-10-2004, 18:11

A tiny little suggestion for Catapult:

When I installed openMSX 0.5.0 and Catapult, my 0.4.0 Catapult started to use openMSX 0.5.0 instead of 0.4.0. It would be nice to be able to use an older and a newer version of Catapult/openMSX at the same time without changing the configuration everytime. I noticed this when I wanted to compare how the TNI bounce entry ran on the two versions.

By GuyveR800

Prophet (3057)

20-10-2004, 21:01

Hey! Don't do that ^^; :\

Related content

Comments (22)