Mixing
Microsoft Flight Simulator 1.0 “DIVIDE BY ZERO†command
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
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
ibm-pc software
edited 2 hours ago
Stephen Kitt
30.5k4125147
asked 3 hours ago
Jonathan Irons
1805
add a comment |Â
up vote
1
down vote
favorite
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
ibm-pc software
edited 2 hours ago
Stephen Kitt
30.5k4125147
asked 3 hours ago
Jonathan Irons
1805
1
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.
– Ross Ridge
2 hours ago
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
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
ibm-pc software
edited 2 hours ago
Stephen Kitt
30.5k4125147
asked 3 hours ago
Jonathan Irons
1805
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
ibm-pc software
ibm-pc software
edited 2 hours ago
Stephen Kitt
30.5k4125147
asked 3 hours ago
Jonathan Irons
1805
edited 2 hours ago
Stephen Kitt
30.5k4125147
asked 3 hours ago
Jonathan Irons
1805
edited 2 hours ago
Stephen Kitt
30.5k4125147
edited 2 hours ago
Stephen Kitt
30.5k4125147
edited 2 hours ago
Stephen Kitt
30.5k4125147
30.5k4125147
asked 3 hours ago
Jonathan Irons
1805
asked 3 hours ago
Jonathan Irons
1805
asked 3 hours ago
Jonathan Irons
1805
1805
1
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.
– Ross Ridge
2 hours ago
add a comment |Â
1
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.
– Ross Ridge
2 hours ago
1
1
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.
– Ross Ridge
2 hours ago
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.
– Ross Ridge
2 hours ago
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
3
down vote
accepted
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.
answered 2 hours ago
Stephen Kitt
30.5k4125147
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
accepted
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.
answered 2 hours ago
Stephen Kitt
30.5k4125147
add a comment |Â
up vote
3
down vote
accepted
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.
answered 2 hours ago
Stephen Kitt
30.5k4125147
add a comment |Â
up vote
3
down vote
accepted
up vote
3
down vote
accepted
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.
answered 2 hours ago
Stephen Kitt
30.5k4125147
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.
answered 2 hours ago
Stephen Kitt
30.5k4125147
answered 2 hours ago
Stephen Kitt
30.5k4125147
answered 2 hours ago
Stephen Kitt
30.5k4125147
answered 2 hours ago
Stephen Kitt
30.5k4125147
30.5k4125147
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f7778%2fmicrosoft-flight-simulator-1-0-divide-by-zero-command%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
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.
– Ross Ridge
2 hours ago