VOGONS


Booter games compatibility overview

Topic actions

Reply 40 of 48, by h-a-l-9000

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Got no mainboard for the 8086 and 8018x CPUs 🙁

1+1=10

Reply 41 of 48, by angrylion

User metadata
Rank Newbie
Rank
Newbie
Qbix wrote:

no, but a reference manual alone isn't enough for us to change things.

Not only 4 manuals in this case, but also the observation that the game runs on 8088 and doesn't run on 286, which fits the information in manuals very well.

Reply 42 of 48, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

which documented that 286's divide overflow interrupt behaves not like 8086/8's as far back as in 1986

Does it say anything more than that the 286 has different IP handling for the exception case?

Reply 43 of 48, by angrylion

User metadata
Rank Newbie
Rank
Newbie

Nope, just that.

Any interrupt on the 80286 will always leave the saved CS:IP value pointing at the beginning of the instruction that failed (including prefixes). On the 8086, the CS:IP value saved for a divide exception points at the next
instruction.

Here's another notable discrepancy, by the way:

The 80286 pushes a different value on the stack for PUSH SP than the 8086/8088. The 80286 pushes the value of SP before SP is incremented as part of the push operation; the 8086/8088 pushes the value of SP after it is incremented.

Reply 44 of 48, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Both are well known/can be found on various bug lists (didn't know they were
officially documented), but they are irrelevant for this issue.
item11 in
http://www.logix.cz/michal/doc/i386/chp14-07.htm
is the difference causing the bad behaviour, which was verified on 8088
compared to the 80286/dosbox behaviour.

Reply 45 of 48, by angrylion

User metadata
Rank Newbie
Rank
Newbie
wd wrote:
Both are well known/can be found on various bug lists (didn't know they were officially documented), but they are irrelevant for […]
Show full quote

Both are well known/can be found on various bug lists (didn't know they were
officially documented), but they are irrelevant for this issue.
item11 in
http://www.logix.cz/michal/doc/i386/chp14-07.htm
is the difference causing the bad behaviour, which was verified on 8088
compared to the 80286/dosbox behaviour.

This list is chapter 14.7 of the official 386 PRM. Item 11 is present in both 386 PRM and 286 PRM. Again, manuals say it's a difference between 8086/8 and 286+.

Reply 46 of 48, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Again, manuals say it's a difference between 8086/8 and 286+.

Right and unless you actually test this you won't know if 8086 is closer to
80286 or 8088 for this feature. Don't know why you insist on this being
a so interesting thing, but just go ahead and verify/falsify it, then post the
results so they can be ignored because of missing relevance.

Reply 47 of 48, by angrylion

User metadata
Rank Newbie
Rank
Newbie
wd wrote:

Right and unless you actually test this you won't know if 8086 is closer to 80286 or 8088 for this feature. Don't know why you insist on this being a so interesting thing, but just go ahead and verify/falsify it, then post the results so they can be ignored because of missing relevance.

Thank you for your kind proposal, and no, I'm not going to retest what was tested by Intel engineers in 1986, especially given the lack of contradictory data.

Reply 48 of 48, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Ok.