List of DOS games that can run on V20 but cannot on 8088

[ArbysTPossum]

To confirm, software that runs on a V20 but is impossible to run on an Intel 8088? Not just running poorly, but impossible?

Jill of the Jungle claims to need a 286, but my own NuXT 2.0 board (With a V20) runs it, though it prompts me that the CPU is too slow to use the Adlib card. I can't confirm if a regular 4.77 8088 will do Jill anyway.

 

[Plasma]

Yeah hardly anything post 1993 runs in real mode.
It's all about when 32-bit chips became widely affordable ... at about 92-93. I think nobody anywhere bought a new PC in 1994 that wasn't 32-bit.

There are quite a few games such as Strike Commander, TIE Fighter, Dragon Lore, MegaRace, etc. that require 386+ but still use real mode. (Using EMS or XMS is a dead giveaway.)

For many games, the main benefit of a 386/486 was simply more performance, from both increased IPS and 32-bit registers. Protected mode was a nice bonus to simplify memory access, but it came with a learning curve and required additional development tools.

 

[george]

Protected mode was a nice bonus to simplify memory access

You are wrong. It actually complicates the memory access due to CPU initialization, exception handling, linear to physical memory mapping, and in 386+ setting and usage of the paging unit. But is a base of multitasking, multiprocessor architecture designed to assist such operating systems at CPU level.

BTW: I am not much of a game player, never had to reverse such DOS extended game, but I met information throughout the years some games used 16-bit DOS extenders. Among them Jazz, Tyrian? This does not mean they aren't using 16-bit segments with some 32-bit executable code, of course.

 

[Plasma]

You are wrong. It actually complicates the memory access due to CPU initialization, exception handling, linear to physical memory mapping, and in 386+ setting and usage of the paging unit. But is a base of multitasking, multiprocessor architecture designed to assist such operating systems at CPU level.

All of that is abstracted away from the developer by the compiler and extender. If it actually "complicated memory access" for them, there would be no protected mode DOS games.

 

[george]

All of that is abstracted away from the developer by the compiler and extender. If it actually "complicated memory access" for them, there would be no protected mode DOS games.

No pain, no gain. It may be complicated but has significant advantages. It is not the simplicity that dictates the creation of new software.
BTW: The compilers and DOS extenders are software too. With their developers too.

 

[Plasma]

No pain, no gain. It may be complicated but has significant advantages. It is not the simplicity that dictates the creation of new software.
BTW: The compilers and DOS extenders are software too. With their developers too.

This thread is about DOS games. From a game development perspective, the only reason to use protected mode over real mode with XMS/EMS is simplified memory access.

 

[Makefile]

This thread is about DOS games. From a game development perspective, the only reason to use protected mode over real mode with XMS/EMS is simplified memory access.

Perhaps it falls under the umbrella of simplified memory access anyway, but don't 386 DOS-extended games also get into the era where they were developed on larger machines, then ported down to the PC (eg DOOM on NeXT)

 

[Plasma]

Perhaps it falls under the umbrella of simplified memory access anyway, but don't 386 DOS-extended games also get into the era where they were developed on larger machines, then ported down to the PC (eg DOOM on NeXT)

Not sure how many companies besides ID Software were doing that, but yes. It was also easier to port a protected mode DOS game to Windows 95. A real mode game using EMS would require significant changes to the memory management.

 

[george]

This thread is about DOS games. From a game development perspective, the only reason to use protected mode over real mode with XMS/EMS is simplified memory access

You don't sound like a software developer either? It is very narrow minded to separate software games from other application software, in fact they usually are very resource demanding.

 

[Plasma]

You don't sound like a software developer either? It is very narrow minded to separate software games from other application software, in fact they usually are very resource demanding.

I have been developing DOS software for 30 years. It is not "narrow minded" to stay on topic. You are trying to take something that I posted, about games, and apply it to something else. Nowhere did I say that protected mode simplifies anything for a compiler.

 

[Zare]

You don't sound like a software developer either? It is very narrow minded to separate software games from other application software, in fact they usually are very resource demanding.

I am a software developer, why are you dragging this topic in this direction?

Look this has nothing to do with CPU modes of operation and how/easy hard is to program under them.
This has to do with a simple fact, when somebody replaces i8088 with V20 in an XT, he gets to run programs that actually use 80186 instructions.

It also tends to be, most of those programs are games.

So we're talking about games that will emit an illegal instruction to 8088 but not to V20. It is in the title. Simple as that. There are many of them, dozens.
Do you argue that some of the games mentioned are not fit for this scenario, in some way, like runnable on 8088 or needing 386? Please do note that.
But all this other discussion is completely offtopic.

 

[george]

This thread is about DOS games. From a game development perspective, the only reason to use protected mode over real mode with XMS/EMS is simplified memory access.

Would you explain how the 286 protected mode simplifies the memory access? What is exactly is more simple/easier for a DOS application? I anticipate your answer would lean again on "abstraction" by a compiler/runtime, which is simply narrow vision on the whole process. With the same logic one could conclude you just lack a good compiler/runtime that makes the memory access in real mode simple enough for your programming skills.

 

[rastepanyan]

george, please stop trolling my thread! I'm a software developer too, and if you'd like to discuss the game/software development, please open a new one.

 

[george]

george, please stop trolling my thread! I'm a software developer too, and if you'd like to discuss the game/software development, please open a new one.

Степанян, what kind of software developer are you when an empirical list is sufficient for your knowledge? This is not trolling, this is discussing things more deeply. Don't further disappoint me with our local "IT" situation (I am Bulgarian, so I can judge your/our resident country's present computer science deficits quite well). Still expecting you, being a software developer, to enlighten me about revisions of 8087.

 

[Plasma]

Would you explain how the 286 protected mode simplifies the memory access? What is exactly is more simple/easier for a DOS application? I anticipate your answer would lean again on "abstraction" by a compiler/runtime, which is simply narrow vision on the whole process. With the same logic one could conclude you just lack a good compiler/runtime that makes the memory access in real mode simple enough for your programming skills.

First of all, my post is not about 286 protected mode. You either lack basic reading comprehension, or you are purposely continuing to argue in bad faith.

On a 386 in real mode, game developers access memory with near pointers, far pointers, XMS, or EMS. XMS requires keeping track of handles and offsets, and must be copied to conventional memory to access. EMS requires keeping track of 16K pages, and in most cases juggling access through a 4-page window. There are significant performance differences for each type of access, making blanket abstraction not suitable for games.

On a 386 in protected mode, game developers access all memory directly with 32-bit pointers. It should be obvious to you that this is simpler.

Now stop derailing yet another thread with your absurd obsession to prove everyone "wrong."

 

[george]

First of all, my post is not about 286 protected mode. You either lack basic reading comprehension, or you are purposely continuing to argue in bad faith.

On a 386 in real mode, game developers access memory with near pointers, far pointers, XMS, or EMS. XMS requires keeping track of handles and offsets, and must be copied to conventional memory to access. EMS requires keeping track of 16K pages, and in most cases juggling access through a 4-page window. There are significant performance differences for each type of access, making blanket abstraction not suitable for games.

On a 386 in protected mode, game developers access all memory directly with 32-bit pointers. It should be obvious to you that this is simpler.

Now stop derailing yet another thread with your absurd obsession to prove everyone "wrong."

Plasma said:
This thread is about DOS games. From a game development perspective, the only reason to use protected mode over real mode with XMS/EMS is simplified memory access.

The whole topic discusses instruction set similarities between V20 and 286, which allow removal/patching of 286 CPU checks to allow the real mode 286 software to run on V20, but when it became convenient (not to me) the 386 was added Derailing is not mine by switching from 16-bit CPUs to 32-bit CPUs in order to defend a wrong thesis And even accusing of "lacking basic reading comprehension" 286 introduced protected mode, why should it be excluded on someone's convenience?

 

[Makefile]

Another place where this comes up is the Windows 3.0 VGA driver has "286" (really 186) instructions in it, discussed here in this forum where someone patched it back to 8086: https://forum.vcfed.org/index.php?threads/windows-3-0-vga-color-driver-for-8088-xt.35866/ but people can use the stock driver after replacing the 8088 with a V20 in their turbo XT clone. (I wasn't there; was that hack known in "period correct" times or is 3.0 real mode too much of a novelty to matter then?)

 

[Plasma]

The whole topic discusses similarities between V20 and 286, removal/patching of 286 CPU checks to allow software to run on V20, but when it became convenient (not to me) the 386 was added Derailing is not mine by switching from 16-bit CPUs to 32-bit CPUs in order to defend a wrong thesis And even accusing of "lacking basic reading comprehension" 286 introduced protected mode, why should it be excluded on someone's convenience?

This thread is about games. There are no 286 protected mode games. Any reference in this thread of protected mode games, except by you, is 386 protected mode. Again, you haven't proven anyone "wrong" and continue to derail the thread with nonsense.

 

[MennoJoshua]

For some extra fun, the NEC V33 has a bizarre “extended memory” mode where it drives a 24 bit address bus. When this is enabled, a set of page mapping registers maps each 16KB of the normal 20 bit 8086 memory range onto the 24 bit physical memory. This includes being able to remap the IVT and anything else.

Obviously this makes it possible to easily implement EMS but it’s also interesting since it makes a certain degree of task switching and virtualisation possible.

 

[sqpat]

For some extra fun, the NEC V33 has a bizarre “extended memory” mode where it drives a 24 bit address bus. When this is enabled, a set of page mapping registers maps each 16KB of the normal 20 bit 8086 memory range onto the 24 bit physical memory. This includes being able to remap the IVT and anything else.

Obviously this makes it possible to easily implement EMS but it’s also interesting since it makes a certain degree of task switching and virtualisation possible.

This is pretty much just EMS 4.0; AMD's system on a chip 286s did the same thing and so did a few of the later 286 chipsets. If you delve into chipset datasheets you find weird possibilities like VLSI supporting page frames in A000, C000, etc.