Reply 880 of 1046, by DosFreak
- Rank
- l33t++
Sounds like a feature
Sounds like a feature
I don't have the modified source handy, but I'm guessing it was the DDSCAPS_VIDEOMEMORY flag in ddraw_init() (win-ddraw.cc/win-ddraw-fs.cc) that had to go.
wrote:The linux version of pcem v11 wasn't optimal for usability, mainly for having no pre-built executable.
That's more of a responsibility of a distro's downstream package manager in a repository. There's lots of source-only releases and binary compatibility is never guaranteed.
Hence my case for mending the windows version.
My observations of running pcem for win v11 in wine 1.6.2 on ubuntu 16.04.
See reference video there. If legally possible, obtain a local copy of the video for continued access.
https://www.youtube.com/watch?v=K4KvWN6Ov1s
Immediate issues:
- release version crashes, modified version runs
- flickering in the right-hand corner with directdraw coupled to activity, doesn't happen with d3d; had the same issue in virtualbox
- switching on the fly from directdraw to d3d and/or d3d to directdraw is unstable; can't remember it being so in virtualbox
- window upscaling in directdraw produces a blurred image, can't remember this happening in virtualbox; d3d mode doesn't blur here because I'd changed it in the source
- the alt key doesn't work - depending on the keyb layout, can't type 'special' characters like \ or :
- pressing the middle scrollwheel button on the mouse unreleases pcem's mouse lock
Some of those aren't issues :
wrote:- flickering in the right-hand corner with directdraw coupled to activity, doesn't happen with d3d; had the same issue in virtualbox
That's a disc activity indicator. Deliberate feature.
- window upscaling in directdraw produces a blurred image, can't remember this happening in virtualbox; d3d mode doesn't blur here because I'd changed it in the source
Wine's DirectDraw implementation is probably just performing filtering - this isn't a bug.
- pressing the middle scrollwheel button on the mouse unreleases pcem's mouse lock
Deliberate feature.
Thanks for the clarification. I should also specify for clarity that the modified v11 here isn't based on the release but on an interim version off the repository from around october last year. I'm fairly sure however that I removed the videomemory flag off the release version source as well, and that it worked. Those that have extra time can test it of course, but that's my assumption.
Maybe the activity indicator is more of a debug thing, or failing to render properly here. And indeed maybe it's failing to render at all in d3d.
If the middle mouse button releases the mouse lock (which is how I meant to put it earlier), how do you middle-click? I have a dos program in which the middle click works not well for this reason.
v11 only emulates 2 button mice...
v12 does emulate the Intellimouse, and disables the middle click to release when using this mouse.
I tested the v12 release in wine, and found that while the shipped exe crashes immediately, a simple recompile with mingw 5.3.0 without changes produces an exe that runs fine. This of course implies the same for v11, though doesn't necessarily mean it's the toolchain.
With basic testing in dos, the only immediate issue with the recompiled v12 in wine is that the (right) alt key still seems to not work. Hooking to win-keyboard.cc, it seems that pcem is receiving the alt press, but doesn't correctly emit characters that for my layout require alt; e.g. $ (alt+4) just puts out a 4. In dos, neither the keyb su (native) nor keyb us layout emits anything for the scandinavian öäå keys; however, setting the linux session's locale to us via 'export LANG=us_US.UTF-8' does allow typing out those characters in both su and us dos layouts in pcem.
Some further observations along those above.
- d3d doesn't always repaint after portions of the pcem window have gotten clipped by other windows, need to either give mouse lock or toggle to ddraw and back to get the screen to clear
- mouse lock doesn't prevent certain ubuntu (mate) hotkey combinations going through, e.g. ctrl+alt+arrow to switch workspaces, but this isn't too surprising
- voodoo 1 doesn't get detected at all in win 95, while voodoo 2 shows up as 'voodoo graphics' or the like, which sounded to me like voodoo 1, but I don't know
- with 3dfx reference drivers at least, the tomb raider 1 3dfx demo crashes pcem if launched with voodoo enabled (tried different compile settings for o, march, and msse, turning off the pcem recompiler, and reducing voodoo render threads, but no go)
Just started using PCEm, and using v12 in Windows 10. I'm impressed with the Windows 95B running on it.
I seem to notice the audio (wave) lag both when hearing the windows default 'ding' alert sound, and in the game I'm currently trying - Entomorph : Plague of the Darkfall. CD Audio works fine, but the sound effects have slight but noticeable delay.
Using VX430/Pentium 200MMX (and also tried Pentium 90) settings + S3 Virge DX Card with AWE32, all drivers loaded.. Host is running on i7 4790K @ 4GHz.
I wonder if this lag is fixable, since I remember reading at PCem forum some time back about a similar audio lag topic, but there was no conclusive fix yet.
And FX Fighter Turbo crashes after choosing the character..
If all the statistics in the status window are not necessary in a release build, then it may be worthwhile to define the win32 high resolution timer code with preprocessor lines (#if defined HIGH_RES_TIMER). Some of this code is in the inner loop, although I didn't note any obvious effects from the current implementation.
Also, a non-MMX interpreter only core is showing ~20% performance difference over a build with the combined cores, although I haven't tested enough to be certain of the difference (or a cause, if true).
Developed further on the Allegro build, but in win32 for convenience. Some findings include that Allegro 4.4.2 has win32 code which captures some 3-key combinations. This may be commented out to work further on the menu code. The main obstacle was a full implementation of the mouse capture in windowed mode and some performance loss overall, although ports to other platforms may not have these issues.
I tried V12, it's the first PCem I ever tried.
The sound lag is unbearable.
EDIT:
Fixed by recompiling a custom build.
I'm emulating Pentium 133MHZ on an i7 3.9GHz and Duke Nukem 3D is stuttering, the i7 3.9Ghz can't provide enough juice for P133 emulation...
https://www.youtube.com/watch?v=s9f9r0ah7VA
https://www.youtube.com/watch?v=pz0vgv9wShE
Surely to do with timers.
Are you registered on PCem forums?
You should make the developer aware of that.
Aware that DOSBox is better?
In x86_ops_misc.h, there are several cases of CPU division (x86) which have a higher cycle cost in 486/Pentium. Did the time to complete a division operation increase between the 386 and the 486 design?
case 0x30: /*DIV AL,b*/
src16 = AX;
if (dst) tempw = src16 / dst;
if (dst && !(tempw & 0xff00))
{
AH = src16 % dst;
AL = (src16 / dst) &0xff;
flags_rebuild();
flags |= 0x8D5; /*Not a Cyrix*/
}
else
{
x86_int(0);
return 1;
}
CLOCK_CYCLES(is486 ? 16 : 14);
...
case 0x30: /*DIV AL,b*/
src16 = AX;
if (dst) tempw = src16 / dst;
if (dst && !(tempw & 0xff00))
{
AH = src16 % dst;
AL = (src16 / dst) &0xff;
flags_rebuild();
flags |= 0x8D5; /*Not a Cyrix*/
}
else
{
x86_int(0);
return 1;
}
CLOCK_CYCLES(is486 ? 16 : 14);
...
case 0x30: /*DIV AX,w*/
templ = (DX << 16) | AX;
if (dst) templ2 = templ / dst;
if (dst && !(templ2 & 0xffff0000))
{
DX = templ % dst;
AX = (templ / dst) & 0xffff;
setznp16(AX); /*Not a Cyrix*/
}
else
{
// fatal("DIVw BY 0 %04X:%04X %i\n",cs>>4,pc,ins);
x86_int(0);
return 1;
}
CLOCK_CYCLES(is486 ? 24 : 22);
...
case 0x30: /*DIV AX,w*/
templ = (DX << 16) | AX;
if (dst) templ2 = templ / dst;
if (dst && !(templ2 & 0xffff0000))
{
DX = templ % dst;
AX = (templ / dst) & 0xffff;
setznp16(AX); /*Not a Cyrix*/
}
else
{
// fatal("DIVw BY 0 %04X:%04X %i\n",cs>>4,pc,ins);
x86_int(0);
return 1;
}
CLOCK_CYCLES(is486 ? 24 : 22);
...
case 0x30: /*DIV EAX,l*/
if (divl(dst))
return 1;
setznp32(EAX); /*Not a Cyrix*/
CLOCK_CYCLES((is486) ? 40 : 38);
break;
...
case 0x30: /*DIV EAX,l*/
if (divl(dst))
return 1;
setznp32(EAX); /*Not a Cyrix*/
CLOCK_CYCLES((is486) ? 40 : 38);
break;
Edit: and here
static int opENTER_l(uint32_t fetchdat)
{
uint16_t offset = getwordf();
int count = (fetchdat >> 16) & 0xff; cpu_state.pc++;
uint32_t tempEBP = EBP, tempESP = ESP, frame_ptr;
PUSH_L(EBP); if (cpu_state.abrt) return 1;
frame_ptr = ESP;
if (count > 0)
{
while (--count)
{
uint32_t templ;
EBP -= 4;
templ = readmeml(ss, EBP);
if (cpu_state.abrt) { ESP = tempESP; EBP = tempEBP; return 1; }
PUSH_L(templ);
if (cpu_state.abrt) { ESP = tempESP; EBP = tempEBP; return 1; }
CLOCK_CYCLES(3);
}
PUSH_L(frame_ptr);
if (cpu_state.abrt) { ESP = tempESP; EBP = tempEBP; return 1; }
CLOCK_CYCLES(3);
}
EBP = frame_ptr;
if (stack32) ESP -= offset;
else SP -= offset;
CLOCK_CYCLES((is486) ? 14 : 10);
return 0;
}
Yes, there are a handful of instructions that are slower on 486 than on 386. RCL/RCR are more examples of this.
Thank you for the information. The MIPS rating of the emulated 486 CPUs seems to also agree with real benchmarking. However, the Pentium CPUs have a much higher MIPS rating than the 486. Doesn't this indicate that the Pentium is processing instructions at a higher rate and that the cycle count does not fully model the overall CPU speed? If this is true, then are there any software that would be affected?
wrote:Thank you for the information. The MIPS rating of the emulated 486 CPUs seems to also agree with real benchmarking. However, the Pentium CPUs have a much higher MIPS rating than the 486. Doesn't this indicate that the Pentium is processing instructions at a higher rate and that the cycle count does not fully model the overall CPU speed? If this is true, then are there any software that would be affected?
The Pentium is a superscalar pipeline with two parallel execution pipes (the U-pipe and the V-pipe), so in theory it can process about twice as fast as the 486.
I assume PCem emulates the two pipes correctly, resulting in the much higher MIPS rating, as expected.
See also here: https://en.wikipedia.org/wiki/Instructions_per_second
486DX2-66: 25.6 MIPS
486DX4-100: 70 MIPS
Pentium 100: 188 MIPS
Normalize that for clock speed:
486DX2-66: 25.6/66 = 0.39
486DX4-100: 70/100 = 0.70
Pentium 100: 188/100 = 1.88
Advances in caching and memory technology probably explain why it's far more than twice as fast in the Dhrystone test.