PDA

View Full Version : Make Machine Lie about V86?



Raven
June 17th, 2010, 08:57 PM
I have run across ONE game that will not run in my current DOS configuration - Turrican II. This game wants the CPU to be in proper real mode, not V86.

I am currently running with QEMM 97, which won't turn off on command due to there being "high ram" and "mapped ROM". The mapped ROM I understand, but I don't think I can magically un-use high ram, so this seems to not be an option.

Is there some way I can get the machine to lie about V86 mode, tricking the game into at least attempting to run?

Here's a snippet of a post by one of the developers of the DOS version of Turrican II about it's memory usage and V86 mode, etc.:



1. SMSW ax should return that the 386 is not in V86 mode (bit 1)
2. XMS handler must be installed
3. It must be possible to load the Descriptorcaches with
cli
mov al, 80h
out 70h, al
lgdt descriptor...
mov eax, cr0
or eax, 1
mov cr0, eax
4. Turrican uses a Realflat model, so it might be enough to ignore this commands (3) and enable the 0x66 opcode prefix to address the whole 4 GB of memory.


Any ideas?

Raven
June 18th, 2010, 10:43 AM
More relevant information:
http://www.programmersheaven.com/download/1364/0/ZipView.aspx

"realflat" is the same as "Unreal" mode which is a more common term today. Basically you jump to protected mode, set up the larger addressing, then jump back.

Edit: Someone more versed in ASM than I could crack the program to skip over the offending bit of code, but it's a bit too complex of a file for me to do it seems, as I can't even locate the relevant part. I can send or link you the file if you think you can do it, just shoot me a PM.

digger
June 20th, 2010, 03:58 AM
I don't think it works that way. The whole point of DOS extenders was that it would be possible for an application to run in 386 mode with full memory addressing regardless of conditions. So the DOS extender would work in "real flat" mode if the CPU was not in V86 mode (switching back to real mode whenever necessary, for instance, to handle BIOS and DOS Int calls), but would automatically cooperate with the likes of EMM386 and QEMM386 if those were detected. See VCPI and DPMI for details.

Anyway, without a DOS extender to arbitrate the various modes and maintain DOS compatibility throughout, a "real flat" application simply won't work in a V86 environment. That's why the game instructions clearly stated that it would not run with EMM386/QEMM386, which sucked, because I had to boot separately just to play that game, and MEGAEM (an MPU-401 GM/MT-32 emulator for the Gravis Ultrasound) would not run in real mode. Later on I heard that a later revision of Comanche: Maximum Overkill included a DOS extender, which solved that problem.

Didn't they ever release an updated version of Turrican II that included a DOS extender?

BradN
July 20th, 2010, 06:02 PM
I think the only way to fool this detection without altering the program is with a CPU that supports virtualization extensions (not even 100% sure on that), or by emulating the CPU.

Raven
July 20th, 2010, 06:21 PM
Turrican II was released in 1995 (for DOS), so if they had wanted to use a DOS extender they could have at time of release.. I searched around anyway and came up with nothing.

Agent Orange
July 20th, 2010, 08:10 PM
FWIW: DR-DOS has a nice little feature which lets put a "?" in the CONFIG.SYS entry and then lets you select whether or not to load that line.

Raven
July 20th, 2010, 08:27 PM
What the heck does that have to do with anything? lol.. I'm confused.. or maybe you are? :P

*a few seconds pass*

Ah I now understand what you mean, but multiple config is even easier and I still try to avoid that. The reboot is the part I'm not fond of - it takes a while.

Agent Orange
July 20th, 2010, 09:24 PM
Pressing (Y)/(N) seems kind of easy to me.

Chuck(G)
July 20th, 2010, 10:37 PM
QEMM implements VCPI, doesn't it? Why not create a VCPI PM task that gets you back to real mode? ISTR that VCPI PM tasks run in Ring 0, so it should be that anything goes...

You might think that if you had a DPMI server, you could use the API to switch to real mode, but the DPMI spec makes it very clear that if you started in V86 mode, that's the same as real mode as far as they're concerned.