PCEm. Another PC emulator.

[hail-to-the-ryzen]

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?

Code: Select all

                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

Code: Select all

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;
}

[SarahWalker]

Yes, there are a handful of instructions that are slower on 486 than on 386. RCL/RCR are more examples of this.

[hail-to-the-ryzen]

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?

[Scali]

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.

[SarahWalker]

I'd take the measurements on that wiki page with an enormous pinch of salt - no way is there that much difference between a DX2/66 and DX4/100!

But yes, PCem does emulate the Pentium's dual integer pipelines, hence the major performance difference. Have a look at codegen_timing_pentium.c.

[Scali]

I'd take the measurements on that wiki page with an enormous pinch of salt - no way is there that much difference between a DX2/66 and DX4/100!

True... at least, if both CPUs were tested in an otherwise equal system.
Then again, if the DX2-66 had no L2 cache, but the DX4-100 did, perhaps that would explain these numbers somewhat.
Anyway, bottom line is: the leap from 486 to Pentium was one of the largest in x86 history.

[hail-to-the-ryzen]

Testing UT99 non-mmx software renderer in PCem and noted the lighting issue which was previously documented. However, even though the cause is likely the gouraud-shaded triangle routines, it doesn't seem that the colors are mistakenly mismatched. This can be verified by the working mmx software renderer which shows that the light sources are reflecting off models across a greater area than the non-mmx artifacts. I think it is more likely that the artifacts are from insufficient precision in those routines.


Edit: the PCem author is correct. The non-mmx software rendering lighting issue is a color mismatch in the gouraud-shaded triangle routines. However, the blue and green are mismatched:
dRY = (R2-R1) / dY
dGY = (B2-B1) / dY
dBY = (G2-G1) / dY

Tested in v400 and v428.

[hail-to-the-ryzen]

Descent 3 (3dfx) runs with the Winchip dynamic recompiler. However, with Winchip interpreter cpu emulation the "ship" spins continuously at game start. This occurs independent of the Voodoo recompiler setting.

Also, there was a change with the introduction of Voodoo SLI emulation (vid_voodoo.c):
- voodoo->dirty_line[real_y] = 1
+ voodoo->dirty_line[real_y >> 1] = 1;

Is this change effective for both cases of SLI and non-SLI?

[Danfun64]

As much as I'd love to use this program, the seeming inability to access PCEm virtual drives from the Host PC and add or remove files from it is a major setback... or is there a way to edit PCEm .img files?

[vvbee]

I seem to be able to mount and access the img in linux with mount -o loop,offset=xxxxx, which if it's a raw disk image isn't too surprising. A quick google confirms this, so just google around for how to access the raw disks of either pcem or some more popular software like virtualbox in your operating environment.

[Danfun64]

I'm running Windows ATM.

edit: Found out about OSFMount. It's embarrasing to say this, but thanks for the suggestion to do a better google search!

[DosFreak]

I use winimage. ImDisk would probably work too.

Also that's a very dirty version of Windows.

[vladstamate]

I use OSFMount in Windows and on macOS I just double click the .img file.

[hail-to-the-ryzen]

Descent 3 (3dfx) runs with the Winchip dynamic recompiler. However, with Winchip interpreter cpu emulation the "ship" spins continuously at game start. This occurs independent of the Voodoo recompiler setting.

I think this same issue was fixed in the dynamic recompiler code at or after the time that these instructions were added: PUSH [mem], PUSH seg, NOP, CLD, STD, JMP indirect, CALL indirect.

[hail-to-the-ryzen]

Tested further with Descent 3 demo. With the mouse and joystick code active in pcem, the demo has shown keyboard errors such as a phantom pressing of the 'shift key'. Confirmed that this is a bug in the demo itself, and not related to the emulation. Presumably this was fixed in full version.

The previous issue with the uncontrolled ship spinning may be partly related to the above, but occurs in the interpreter cpu core and has occurred in the recompiler core in pcem v10.1. Testing commits in the relevant time interval had no effect, so it could be a subtle emulation issue or a specific issue with the demo and timing. Supposedly the demo and possibly the full version are dependent on the time between video frames to gather input from the mouse/joystick. I don't have a reliable test other than finding a faster host system, but the bug may be from a comparatively slower cycle rate in the interpreter core.

I tried to fully explore the REP instructions as the cause, but reverting this code in the dynrec had no effect on the above issue. Also, did disable the gameport and joystick code in pcem without much effect. However, it would be a helpful pcem option to allow for disabling this device for testing in games like this and to test for an improved mouse input response (either related to game code or otherwise).

[leileilol]

PCem does show symptoms of a phantom left-shift with some games when in pure DOS. Spectre VR is impossible to play with the arrows

[hail-to-the-ryzen]

Does it interrupt gameplay soon after starting? I recall briefly testing it with serial mouse but no mouse driver loaded in DOS, so used keyboard arrows for movement, in a recent pcem version.

[Jo22]

Good morning everyone,

I've got a little issue with PCem.
- I'm running it with a generic XT PC clone setting.

For some reason the maximum memory is limited to 640 KiB.

The video system is set to CGA, so there should be enough space to allow
for 704 KB or even 736 KB of conventional memory.

Still, I can not figure how to apply that setting.
Manually entering 704 seemed to work at first glance, but when I click "OK"
and afterwards come back to settings dialog, the selection is back to 640.

What did I do wrong ?

[SA1988]

Because it's the highest supported in a generic XT clone.

[Jo22]

Ah, okay, I didn't know that, sorry. I choosed the generic type, because I assumed that
this famous anonymous XT BIOS would be smarter than the normal XT BIOS.

Anyway, my knowlegde about XT machines is a bit sketchy.
I believe I did read that the IBM 5150 determined the total amount of random access memory
via DIP switch settings, while the IBM 5160 was a bit smarter already and counted the actual memory.

So could it work, by any chance, if I select the IBM 5160 model in PCEm ?
I mean, hardware-wise, 640KiB never was the true limit of any PC model,
since even then it was possible to exchange 64K chips with 256K chips.
The main thing was, as far as I know, that the additional memory was contiguous.

(Btw, sometime ago, I read something about an ancient mod for these old IBMs.
Back in time, people did exchange/modify some of the address decoders (U4?).
Another trick was to use the sockets meant to be used for the ROM BASIC for additional RAM.
I believe the old terminology of that extra memory was High Memory, not to be confused with the HMA.)

Edit: Found again one of these articles I was reading. ^^