6

I was reading an Wikipedia article named "History Of Microsoft Flight Simulator" and I noticed something weird about Microsoft Flight Simulator 1.0:

November 1982
sometime during 1981-82 Microsoft obtained the license to port the simulator to IBM compatibles PCs. This version was released in November 1982 as Microsoft Flight Simulator, and featured an improved graphics engine, variable weather and time of day, and a new coordinate system (used by all subsequent versions up to version 5).

Advertisements claimed "If flying your IBM PC got any more realistic, you'd need a license", and promised "a full-color, out-the-window flight display" Early versions of Microsoft Flight Simulator were used as a test for PC compatibility. If a computer could run MSFS 1.0 and Lotus 1-2-3, it was 100% IBM PC-compatible, and if it could not, it was not.

Compatibility difficulty included the unusual use of the x86 assembly DIV command, where a "DIVIDE BY ZERO" command would be issued every time a screen refresh was needed. This technique often required hardware changes to assure compatibility with MSFS 1.0 software.

As I understand the MSFS 1.0 was an compatibity checking software but there is something lot more intereseting. 

"DIVIDE BY ZERO"

So

Was the "DVZ" was used to make sure the CPU had the ability to detect divide by zero commands and send it to the crash handler ?

Back in the day, not all CPU's had to ability to detect divide by zero commands and send it to the crash handler ? (Did Crash Handling even exist on IBM PC's back in the day?)

Thanks For Answering

Improve this question
1
  • 3
    All IBM PCs (and compatibles) will invoke the INT 0 handler when a zero divisor is used as an operand to the DIV instruction. According to your quote this was deliberately done in order to trigger screen refreshes. However, I can't see why it would do this, and am I skeptical that it's true. I suspect the author of the quote is mistaken and the program generates unintentional divide by zero exceptions when run on computers that are too fast compared to the original IBM PC. This was a fairly common problem with old IBM PC games.
    – user722
    Sep 29, 2018 at 20:22

1 Answer 1

Reset to default
10

Some 8086/8088 software ends up calling interrupt 0, the divide-by-zero trap, during normal execution, either through programmer error, or intentionally. (Even when this happens through programmer error, there is some level of intent involved since the programmer would have to install a handler to avoid having the program exit.) On the 8086 and 8088, this acted like a “standard” interrupt, with a return address pushed to the stack containing the address of the instruction following the divide instruction. Examples of software which do this include The Seven Cities of Gold’s World Maker and of course Flight Simulator 1.

I don’t think however that this would cause issues with 8086/8088-based computers attempting to be PC-compatible, because this is handled by the CPU. It does cause problems with later CPUs though because the divide-by-zero error became a fault, not a trap, with the address on the stack pointing at the faulting instruction, not the one following it. Thus on World Maker or Flight Simulator 1, the divide-by-zero instructions would result in the interrupt 0 handler being called, but when that returned, the divide-by-zero instruction would run again, causing an infinite loop.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .