VOGONS


PCEm. Another PC emulator.

Topic actions

  • This topic is locked. You cannot reply or edit posts.

Reply 882 of 1046, by leileilol

User metadata
Rank l33t++
Rank
l33t++
vvbee 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.

apsosig.png
long live PCem

Reply 884 of 1046, by vvbee

User metadata
Rank Oldbie
Rank
Oldbie

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

Reply 885 of 1046, by SarahWalker

User metadata
Rank Member
Rank
Member

Some of those aren't issues :

vvbee 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.

Reply 886 of 1046, by vvbee

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 888 of 1046, by vvbee

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 889 of 1046, by vvbee

User metadata
Rank Oldbie
Rank
Oldbie

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)

Reply 890 of 1046, by Malik

User metadata
Rank l33t
Rank
l33t

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..

5476332566_7480a12517_t.jpgSB Dos Drivers

Reply 891 of 1046, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

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.

Reply 892 of 1046, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

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...


my important / useful posts are here

Reply 896 of 1046, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

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*/
}
Show last 21 lines
                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;
}

Reply 898 of 1046, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

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?

Reply 899 of 1046, by Scali

User metadata
Rank l33t
Rank
l33t
hail-to-the-ryzen 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.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/