VOGONS


First post, by exofreeze

User metadata
Rank Member
Rank
Member

This game seems to load and start up fine, however after playing a round and getting to the score screen it displays:

Congratulations!

You have won the battle..
X(whatever number) IBM locations remain

Your score is :
Division by zero at address 0386:3fcb

This is using 0.74, with a standard conf. Cycles however have been lowered to 300 for gameplay speed.

I have also tried disabling ems/xms/umb.

Reply 1 of 9, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

Reply 2 of 9, by exofreeze

User metadata
Rank Member
Rank
Member

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

Reply 3 of 9, by exofreeze

User metadata
Rank Member
Rank
Member

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

Reply 4 of 9, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

Reply 6 of 9, by h-a-l-9000

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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

1+1=10

Reply 7 of 9, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

Reply 8 of 9, by peterferrie

User metadata
Rank Oldbie
Rank
Oldbie

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)").

Reply 9 of 9, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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