The error is actually a divide overflow, not a divide by zero. It's not easy to determine the program's intention with the math it is doing (I guess for calculating your score) because it's written in compiled BASIC. Dunno if there is a timing element to the score or not, but it might be a factor.

Ok, so it sounds like there isn't much that can be done about this?

n/m, there is an alternate version of the game that does not have this error.

AFAICT, there is no other version. It seems that the problem can be avoided depending on the "warhead size" you choose as one of the difficulty settings. A size of 7 or larger doesn't run into the divide error, but a smaller size does. If anyone has an 8088 PC with CGA or better, please try the game with the smaller warhead sizes to see if the divide error happens there as well.

This game runs well in PCem v0.7 with warhead size=3 .

http://www.pcem-emulator.co.uk

Could it be the same issue as with MS Flight Simulator?
It would fail on a 286 then.

I don't think so, it's not the specific case where only 8088 has an exception, it's a straightforward overflow. I suspect cycle accuracy (or maybe video memory speed?) more than PIT behavior, considering it's compiled BASIC where direct interaction with the PIT would be unusual.

PCem and DOSBox see identical values up to the faulting divide.
The only difference is that PCem does not generate any exception.
It's 8086-specific behaviour, as described in Ralf Brown's interrupt list ("an 8086/8088 will generate this interrupt if the result of a division is 80h (byte) or 8000h (word)").

The note in the RBIL does not describe this situation; it describes another cause for an exception, not the lack of other causes for an exception.

What seems to fit the evidence is that an 8086/8088:

- has an exception for divide by zero
- does NOT have an exception for divide overflow
- has an exception for an 80h/8000h result