According to this: http://x86.renejeschke.de/html/file_mod ... d_290.html , if operand size is 16-bit, the base address for SGDT is 24-bit.

- nerd73: I think you might have faulty copies of the OS'es. I got NT 3.1 and 4.0 working without problems in PCem, and SA1988 did the same with NT 3.51. Remember, that first, a lot of NT 3.x copies floating around on the internet are patched to make NT auto-assume a Pentium II. or something like th...

DEBUG.EXE single-step doesn't work on dynamic recompiler. I tried to add the trap stuff, and got it to work for one instruction, and then it complained that CS is not present. Now, if EMM386 isn't loaded, and DEBUG does everything in real mode, it works fine, but when it is loaded and DEBUG does its...

I notice the source code says it supports 8 MB video RAM but the Bahamas64 BIOS is buggy. I noticed that this site: http://www.vgamuseum.info/index.php/component/content/article/185-s3-vision-864 has a real S3 864 BIOS. I am going to try if this one works correctly. Maybe the Bahamas64 has proprieta...

This suggests that the emulator is running slow, your machine obviously isn't fast enough to emulate the system you've chosen on the emulator at this stage in development. Actually, it seems Direct3D has a lot to do with it. Switched video to DirectDraw now and LBA 2 flies on the emulated Pentium 2...

- truth: That LBA 1 issue turned out to happen only when OAKCDROM.SYS (or possibly any other CD-ROM driver too) is loaded into a segment between B000 and B7FF, and it might have happen on real hardware too. I never tested loading OAKCDROM.SYS into that segment on real hardware or orther emulators or...

- SA1988: Did you try the same discs on a real machine running an old OS? To presume it should play correctly there just because it does on your host OS is wrong.

- SA1988: Most probably something just reports the wrong starting time for the first tracks to PCem. Remember, pretty much all Audio CD's start with a 2 second pause, the Red Book standard says they must, so all CD player software is most probably designed to skip those 2 seconds. Most probably when...

To be honest, I see his reasoning to sync the clock with the host. However, I think someone should implement a configuration option to optionally disable it. I can try doing that myself if needed.

More information about the issue: turns out the issue with OAKCDROM.SYS only occurs if the I=B000-B7FF parameter is used with EMM386.EXE in CONFIG.SYS, thus assigning that memory block to upper memory. As soon as that parameter is removed, the issue no longer occurs. However, with VIDE-CDD.SYS the i...

OK, turns out the bug is actually in OAKCDROM.SYS and not in the game. Changed CD-ROM driver to VIDE-CDD.SYS version 2.15, and not only does LBA 1 no longer hang now, but it also transfers the speech file instantly while it took ages to do it with OAKCDROM.SYS.

Added the fatal() now, this is the log: New ATAPI command 28 506389625 void loadseg(uint16_t seg, x86seg *s): Bigger than GDT limit 8000 0177 1 void loadseg(uint16_t seg, x86seg *s): Bigger than GDT limit 8000 0177 1 PIC1 : MASK 98 PEND 00 INS 00 VECTOR 08 PIC2 : MASK 1D PEND 00 INS 00 VECTOR 70 EAX...

- TomWalker: It's not if the instruction pointer is at 0F000h for example, and you try to jump 2000h bytes ahead. that would yield 11000h which is outside the segment. Though, the reference I'm using says you're right, and jump only triggers the GPF in protected mode. Plus, it didn't fix the problem...

OK, this is the log: New ATAPI command 28 495631137 Note by Battler: there is a whole series of these new ATAPI command 28's at this point Bigger than GDT limit 8000 0177 1 INT to higher level 2 Double fault 495892778 INT to higher level 2 Triple fault - reset PIC1 : MASK 98 PEND 00 INS 00 VECTOR 08...

So has it been discovered what causes this yet? If not, I'll have a go at it myself. I guess I need to enable logging again and see what instruction it freezes/hangs/restarts at.

Yep, it does. Except rather than hanging or fataling, the interpreting version of PCem hard-resets itself.

I just tested this on Virtual PC 2007 with the exact same drivers I use on PCem (VIDE-CDD CD-ROM driver, SHSUCDX, etc.), and it doesn't have the same problems there - the speech file transferred fine, and I could continue playing. So I guess it's indeed a bug in PCem.

Well, no idea how to measure the overall emulator speed. All I know is, LBA 1 and LBA 2 are perfectly playable on an iDX4/100 but sluggish as heck on a Pentium. Whether it's limited to these two games or it affects the entire emulator, though, I have no idea. But it even affects the MIDI (OPL3) musi...

True, you're right.

BTW, are you sure PCEM correctly enables the dynamic recompiler on the emulated Pentium? LBA 2 and LBA 1 are both much faster on an emulated iDx4/100 for some reason than on any emulated Pentium.

It starts normally, everything works, but as soon as it displays the "Speech files transfer" box, it hangs. I guess something regarding the CD-ROM doesn't work right. Edit: Nevermind, works fine. There was just eMule hogging the CPU on the host, slowing everything down, PCem included. Edit...

Well, I enabled PCem logging, and noticed that the instruction that triggered the FATAL was a xor. So I assumed that's where the problem was.

OK, I just discovered even more - that the CPU executes an instruction anyway, even if a GPF is triggered. I just tested this in Virtual PC 2007, which, being a virtualizer rather than an emulator, pretty much executes the code on the host CPU directly. Which means the CPU behavior shown in Virtual ...

I'm having a go at fixing it myself. I found out it has to do with the segment limits not being implemented at all on arithmetic operations. Edit: OK, it's not limited to arithmetic operations. Seems jumps and calls are also affected. For some reason, LBA 2 seems to be deliberately triggering the li...

If it helps, this is the log: Bad getpccache 000B8000 PIC1 : MASK 98 PEND 00 INS 00 VECTOR 08 PIC2 : MASK 1D PEND 00 INS 00 VECTOR 70 EAX=0000DE0C EBX=0058107C ECX=0000107C EDX=000021CE EDI=00540140 ESI=00524E8E EBP=00004E76 ESP=000021A2 PC=7FF0 CS=3EE0 DS=0038 ES=0020 SS=0020 FLAGS=0006 3EE0:7FF0 0...

The lack of segment limits is back with the emulated Pentium. Crashes the exact same way. But only with the non-MMX Pentiums. With the MMX ones it runs fine, but has render problems (as you said there's a MMX bug). And with a 486 it runs without any problems.

Any particular reason why the patch hasn't been accepted yet? If it's not a proper fix, I would at least like to know why.

As I said in this other thread, I found the proper fix for the 32bpp render bug with the S3 Trio64. It is attached as a patch file.

I just tested and it's not working properly on any emulated VGA or later card. What happens is, when you switch from full screen mode to windowed mode, the window incorrectly displays only empty (black) characters, until you either type something (at which point you see the character you just typed ...

No idea about what format IMD is, however TD0 is the Teledisk format, and is a compressed raw image but with also some sector data IIRC to get around some copy protection schemes. DDI is the DiskDupe format and is also a compressed raw image. And a Kryoflux stream records the actual magnetic flux of...

Maybe I should look into PCem's floppy image handling and add support for td0 (I do have some source code for a decompressor), ddi (DiskDupe, I have some decompressor source code doo), and even Kryoflux streams if someone gets me any code or documentation thereof, as an optional add-on.