Posted By
IstvanV
on 2008-09-11
16:52:12
|  Re: plus4emu 1.2.9
> the CPU load in the new version dropped to a 82% (together with SID emu) from the proevious 95-100%. I tried the buffer setting issue, but no difference, the biggest load I could notice is the Quality setting of Display, setting it to 3, the output looks real PLUS/4, but CPU is 100% ) I need a stronger one...
Reducing the Sound sample rate to 44Khz from 48, switch off quality setting, directly mapping to sound driver chip, having Quality setting as 1, the 82-85% is a good result.
Well, for comparison, here are some CPU usages on my machine (Athlon64 3200+ (2000 MHz), nVidia 6500) running the 32-bit Linux build of the 1.2.9 release, which should perform similarly to the Windows version (at least it does for me): Disp. q. = 3, reSID, 1541/high accuracy, 48 kHz sound/high q.: 49% (280%)
Disp. q. = 1, reSID, 1541/high accuracy, 48 kHz sound/high q.: 40% (310%)
Disp. q. = 0, reSID, 1541/high accuracy, 48 kHz sound/high q.: 37% (315%)
Disp. q. = 0, reSID, 1541/high accuracy, 48 kHz sound/low q.: 34% (315%)
Disp. q. = 0, 1541/high accuracy, 48 kHz sound/low q.: 27% (415%)
Disp. q. = 0, 1541/low accuracy, 48 kHz sound/low q.: 25% (460%)
Disp. q. = 0, 48 kHz sound/low q.: 17% (690%)
No display, 48 kHz sound/low q.: 13% (825%) All the above were measured in single buffered OpenGL mode; the values shown in parentheses are the speed percentages in full speed (Alt+W) mode. Note that measuring CPU usages can be somewhat tricky, so I used a setting of a small number of very large sound buffers to minimize inaccuracies due to OS scheduling.
The 44.1 vs. 48 kHz sound sample rate should not make much difference, unless there are driver related problems. The default MME sound device is also normally OK, and I do not recommend using the DirectSound devices, because the timing is then done entirely by the sound output (= ugly jittery video), while in the case of the MME devices Sleep() is called to synchronize with real time, dynamically adjusting the speed so that the sound buffer is about 50% full on average, but the jitter is much lower.
Software video mode should not be much slower that OpenGL if the screen is not changing much; but when it does, then it can indeed be slow, and the speed depends largely on the resolution.
> By the way, one of the best testers of EMU accurcy is the Genesis Project demo (very old one), when the raster scroller is fluently moving, then is is like on real Plus/4.
Anything that does not do something really tricky or unusual should run exactly like on the real machine. In fact, I have tested reading and writing all TED registers in all possible cycles, and the modeling of hardware is based on the results of the tests (running similar tests on YAPE can easily reveal various small bugs). The main areas where there are still some inaccuracies compared to the real machine include writing to the $FF1E register at some specific times (it is mostly complete, though, and other emulators are worse), some "analogue" aspects of the hardware - including "random" behavior under some circumstances, DRAM losing data when not refreshed, etc., and the exact details of switching the TED off with the $FF07 register (it is implemented, but not 100% correct).
Here are a few very simple tests to try on various emulators  . Type these in the TEDMON, each one after Run/Stop+reset:>FF06 9F
>FF06 3F 0F
>FF07 48
>FF07 28
>FF14 FF
>FB 0A In this program, the bright green dots should not move with the scroll: http://www.sharemation.com/IstvanV/scrolltest.prg.
|
