Quote:

Samor: the performance depends heavily on which renderer setting you use and what kind of graphics card you have. The SDL renderer works on almost any video card, but uses more CPU. The SDLGL-PP only works on modern (OpenGL 2) cards, but uses a lot less CPU. I have an Athlon XP 1600+ myself and with SDL it uses about 60% CPU for a scale factor of 2 and with SDLGL-PP (on a Radeon 9700Pro) using all possible effects about 50% with a scale factor of 4. So, CPU usage should not be very high on your system, but it heavily depends on the graphics card.

I have a Geforce 4 ti. SDLGL-PP does not work with that.

Quote:

You could also make your sound buffer larger, if you experience sound skips (I assume that is what you mean with skips). In the console type "set samples" to see what the current value is. Try to double the value and see if that helps.

it was 2048. Seemed pretty high already to me, but it could help.
(for example, I needed to set BlueMSX at 150ms with my current soundcard, which is also higher than the default)

Quote:

I'll ask the sound specialist (wouter_) to look at the PSG code. You're sure it's only the PSG and not a general problem? Or is the Quarth thing an SCC problem? In the latter case, is it the same bug as this?

The Quarth problem is the same as described there; I think that's a different bug from the PSG one.

OK, so you use SDL. What video settings are you using?

Btw, you can buy a cheap OpenGL 2 compliant card to replace your old one: the GeForce 6200 is quite popular under openMSX developers and costs only about 40 euros and is completely silent!

I don't know... the geforce 4 ti was (emphasize on was) a pretty high-end card... new cards have more features, but the 6200 isn't a top model... maybe it could be slower in games/emulators that don't require dx9 specific functions for example. For 40 euros it's a tempting investment, but I want to make sure I get a speed boost in other programs too

I was using SDL on the default settings, and also SDLGL (that works, just SDLGL-PP doesn't).

The soundcard I'm using has a C-Media chip. It's not onboard, and cheap, but I got that because I got very tired of Creative's inability to ship decent Windows drivers with their cards (In the case of the sblive, I used the ms ones, the creative ones AND the kx project ones, but I think the card was also a bit broken in the end). After that I tried an SB Audigy but that thing couldn't do anything right and caused a huge performance hit on my system, so it didn't stay long.... again, crap drivers.
This C-Media card has given me very few problems ever since I got it... if I found any issue at all it was usually one that happened with my previous soundcards too (meaning it's usually an error in a program rather than the drivers or the card).
Dunno what is is with creative, but if those cards are supposed to be high-end... ah well, I'm going offtopic now

Anyway, I'm very picky with sounds, but I also realise that things like soundskipping could be caused by many reasons.
There used to be one such error in bluemsx which was really the cause of the emulator (something with the sound buffer gradually shortening IIRC), but it's been fixed in recent versions.
OpenMSX seems to do soundskipping entirely randomly, so in that case it should really be something with the performance... it gets a bit problematic though if it stays even after you optimize everything you can... ah well, it could be the gf4 maybe..

anyway, I'll try to do some more tests and see if I can find out why it's happening.

Wouter checked out the sound and it seems the noise has a too high frequency... I'll keep you updated.

Your CPU load should not be 100% (see previous examples) when running SDL without any effects in x2 scaling mode, e.g. Can you try that?

Actually, openMSX implemented according to the datasheet: the noise freq is the same as the tone freq. But blueMSX has the noise freq twice as low as the tone freq... This is also done by http://bulba.at.kz/emulator_e.htm

We're checking on real hardware now.

I think you are mistaken manuel. Although I'm not 100% sure, I know I wrote the PSG emulation in blueMSX from the spec. I took a look at the code and I can't see that the noise freq would be different than the tone freq.

Are you sure openMSX just doesn't do conversion to 44.1kHz correctly? I know many emus (including blueMSX) have had problems with high frequency PSG sounds.

Quote:

Actually, openMSX implemented according to the datasheet: the noise freq is the same as the tone freq. But blueMSX has the noise freq twice as low as the tone freq... This is also done by http://bulba.at.kz/emulator_e.htm We're checking on real hardware now.

well, I'm really positive that on real hardware it sounds like it does in BlueMSX. That's comparing with a VG8235 and an NMS8250. If it's different on other MSX machines, that would be very strange, I think.

dvik: I was merely reporting what wouter_ told me. But you provided some nice info, I hope it's useful for him. Will keep you updated.

Wouter fixed something. Samor, please visit us in Nijmegen tomorrow or send me an e-mail, so I can double check it with you. Thanks! (manuel at msxnet dot org)

A few videos added.... SD snatcher intro demo and SD snatcher gameplay are the longest videos.

Hmm, cool! THey didn't show up in the openmsx query tho on Google Video.

Once again... google needs time to sync with all the servers

I take requests, let me know which video you want on there.

* can't be arsed to browse back to check,

but uhm.. 'The Swiss Demo'