Let’s do another article about weird code in video games.
The original 1992 Comanche release is extremely picky about memory managers. The game refuses to work with EMM emulators and crashes when EMM386 is active. The game may also hang or reboot the system when HIMEM.SYS is not loaded (the problem seems to be system configuration dependent).
These issues are clearly noted in the Comanche documentations, but at the same time they’re also all signs of a substandard DOS extender.
On top of that, the game authors accomplished a remarkable feat: By only loosely following Intel’s instructions on how to enter protected mode, NovaLogic managed to write a game which worked on the then-existing 386 and 486 processors, but under some circumstances failed to run on Pentium and later processors.
↫ Michal Necasek at OS/2 Museum
As usual, a great read from Michal Nacesek.
For those interested into the voxel algorithm used : https://github.com/s-macke/VoxelSpace (web demo available)
The article vaguely reminds me of some of my original assembly protected mode projects.
I like these deep dives into archaic technologies 🙂
This article is an excellent example of how Intel’s x86 architecture is a total mess.
Intel really screwed up the design of x86 but due to the market the x86 cpus kept selling like hotcakes.
One problem is Intel tried to switch to a totally new architectures like iAPX 432, so x86 “wasn’t the priority”.
They also got distracted by the Itanic disaster as well.
In 1970, IBM introduced System/370 with 24bit paging. Also I believe the PDP-11 had paging mmu in 1972.
Let’s pretend Intel were actually focused on x86 after release of 8086 in 1978. I reckon they could have designed the 286 cpu as a 16bit 8086 + 24bit/32bit paging MMU + 32bit registers + small number of 32bit instructions for pointer arithmetic/mmu management. As an extended 8086 it would mostly be 16bit with minimal change to the 8086 instruction set. My totally uneducated guess it would have fitted in the 120,000 transistors that the 286 ended up with.
tom9876543,
Yep.
Backwards compatibility was the driving force behind x86’s demand. Both for intel and later AMD’s 64bit extensions. x86 is not optimally engineered and nobody would make this architecture starting from a clean slate. But every competing desktop architecture failed because x86 had a monopoly on software and it turns out to be extremely difficult for new architectures to break into the market because they can’t solve the chicken and egg problem. x86 was “good enough” and had the entire industry behind it. This only changed with mobile giving an opening for ARM where x86 didn’t have an established monopoly.
There was the 68020 with 68881 (FPU) and 68851 (PMMU) is they really wanted to do serious business. Imagine if Intel chose this ISA and improved over it. Thankfully AMD gifted the world with AMD64.
Another point about Intel’s poor performance:
Intel manual should have provided assembly code listing showing exactly how to enter protected mode.
And for 386 exactly how to leave protected mode.
The Intel engineers were lazy in writing a manual with unclear information (as stated in the 0s2museum article).
This sort of reminds me of an article I once read about graphics driver developers having to jump through so many hoops to get games to work, because many games, even those from top studios, were an absolute nightmare of awful code. One specific issue I remember was a custom code path in a driver to support a game where the developers just failed to call glEnd() at the end of the rendering pass.
Issues like this sometimes caused certain games to take forever to launch, because if the executable used the generic name “game.exe” the driver had to figure out which codepath for game.exe it had to follow. Games with unique names for the executable would launch faster, because while there might be 50 games named “game.exe” there is only one named “tomb2.exe”.
This is such a fascinating example of how much old PC gaming depended on the exact hardware and memory configuration. It’s wild that a game could work on the 386 and 486 but then run into problems on newer Pentium systems because of how it entered protected mode.
The EMM386 and HIMEM.SYS issues are interesting too. It really highlights how fragile some DOS-era software could be when interacting directly with memory management and hardware. Articles like 1000 games are a great reminder of just how much effort went into making older games compatible with the systems of their time.