LOL, i just started to run.

btw you ppl haven't recognized atarulum ?

Quote:

*sigh* People, please... Peace, love, and J-War running naked through a field of flowers... okay?

Oh dear... mental picture

>Liar!

>Maybe I should post the logs of the time when you changed nicknames and >seriously pretended to not know Quibus in order to infiltrate in the openMSX >team, just after you started a propaganda war against it.

Hey, crazy boy.

I'm not the atarulum.

I'm a friend of atarulum by Email.


According to him, he decided not to be active on MSX emulator related site anymore.

I become to be MSX emulator fan thanks to atarulum.

I'm the MSX emulator user on Windows.


This is last Warning.

If you should say (or blaim) about atarulum to me continuously, I'll say (report) to other bbs about your problem on Japan.

If you want to say about atarulum, write it to other place.

Here is MSX Emulation forum.

(No place for blaim or comment of non MSX emulation.)

If you want to say with me, say about MSX emulation only.

j-war, running naked through the field

Where are the flowers again?

I think that j-war is also running in the Vector Scroll demo of IC

By the way, an excellent demo with great Moonsound music (also the case of the Revival demo, but I prefer Vector Scroll) !

As openMSX is not multi-threaded (and I think will not be, it is a design decision?) it will not see any real improvement on a HT CPU. Of course, it will still run somewhat smoother because it should be less influenced by other system processes which can be scheduled on the other processor.

~Grauw

There are indeed some design differences between blueMSX and openMSX and they can be explained by different starting points : openMSX is first an emulator conceived for the programmers, blueMSX is first an emulator conceived for the end-users. The evolution of both emulators will make them closer to each other, but there will be always some differences, maybe not in the performances, but certainly in the general design.

Maarten or Wouter should correct me, but AFAIK openMSX was also multithreaded (video in a different thread), but this gave some problems with SDL, especially on Windows. So, we put all of it in a single thread again. The sound is produced in a separate thread still, because SDL works like that. Again: I may be wrong, this is what I remember.

fs5500: openMSX runs pretty well in Windows, so, I wonder why you don't mention it

hyperthreading is irrelevant anyway...

sorry, but I just have to take back the remark about the 0.1%.

Imho the cpu counter that bluemsx is using isn't accurate. Atleast, the taskmanager gives a 5% cpu usage.

The cpu counter in blueMSX measures only the cpu usage of the emulator thread and it is using the High Performance Counters but on a very fast PC the resolution may be to low (it is usually somewhere between 1 and 2 MHz)

The cpu usage of blueMSX should be somewhere between NLMSX and openMSX, probably closer to openMSX...

When I set the sync mode to 1ms blueMSX reports ~40% cpu time while taskmanager still reports the same as when then sync mode was set to Auto (actually, only 1-2% higher). With sync mode Auto, blueMSX reports about 50% lower values than taskmanager (on amd64 3200+).

It could also be that using the current algorithm for determing the cpu usage doesn't work at all for HT processors.

Quote:

The cpu usage of blueMSX should be somewhere between NLMSX and openMSX, probably closer to openMSX...

mostly blueMSX + moonsound support (mbwave) runs @ 5%, openMSX runs at 12 - 16% (in mbwave).
And I have a 2.6 Ghz P4 here atm.

>> fs5500penMSX runs pretty well in Windows, so, I wonder why you don't mention it


manuel: BlueMSX runs pretty well in Windows, so, I wonder why you don't mention it.