VOGONS


Booter games compatibility overview

Topic actions

  • This topic is locked. You cannot reply or edit posts.

Reply 20 of 48, by peterferrie

User metadata
Rank Oldbie
Rank
Oldbie

Yes, I realised after I posted that message, that it was worded too strongly. wd also noted elsewhere that we could introduce a new core to deal with it, after I said something similarly wrong like this. You'd think that I'd learn. :-)

In this particular case, all it needed was that a divide overflow interrupt returns to the instruction following the divide, not to the divide instruction itself. However, creating a proper 8088 core requires ripping out all kinds of stuff from the 386 core. I doubt that we'll see one anytime soon. ;-)

Reply 21 of 48, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

As I noted elsewhere about hacking the FS 2.13 divide handler into FS 1.05, and the patch I made to do just that, not trying to re-execute the failing divide is the prominent feature of the 2.13 handler. Fixing up the return address doesn't seem backward-compatible, though, so it makes me wonder how well 2.13 runs on an 8088... but I would guess that Microsoft enhanced the later version's handler to work on either an 8088 or a 286.

Reply 22 of 48, by robertmo

User metadata
Rank l33t++
Rank
l33t++
ripsaw8080 wrote:

it makes me wonder how well 2.13 runs on an 8088... but I would guess that Microsoft enhanced the later version's handler to work on either an 8088 or a 286.

Someone with a 8088 machine could just check it.

peterferrie wrote:

However, creating a proper 8088 core requires ripping out all kinds of stuff from the 386 core. I doubt that we'll see one anytime soon. 😉

386 core also has pentium stuff. Dosbox is rarely made "proper" just for the sake of it 😀

Reply 24 of 48, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

I think a more interesting test would be to see if MSFS 1.05 works on either CPU when patched with the 2.13 divide handler. And by "works" I mean that the operation of the game remains consistent on either CPU, not just that the hang condition is avoided. I don't have systems to test it on, but anyone interested in trying the experiment can use a patch that hacks the 2.13 handler into the 1.05 disk image (it's based on the Retrograde Station images).

Reply 25 of 48, by robertmo

User metadata
Rank l33t++
Rank
l33t++

I doesn't hang and looks exactly like in dosbox (286, 386, 486) (although in dosbox it seems that is runs in composite mode when i ask it to run in rgb).

even starteing demo at the same time with different version of dosbox (for example cvs and hal's) the plane rotates with different speeds resulting different view and different crushing places (crush on land or splash into the water 😉 ), although the camera view swiching, switching to the menu happens more less at the same time.

I compared 286/386/486 with dosbox and on real machines whole game was slightly faster.

I also compared 486 slowned down to XT's speed with phenom. Whole game on phenom was slower.

Reply 28 of 48, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Does that system have an 8088 or a V20? Can you dial it down to 4.77mhz from 12mhz? Only reason I ask is because the game does exhibit some sensitivity to CPU speed (in DOSBox as well) with regards to how and where the plane hits the ground during the demo.

Reply 29 of 48, by robertmo

User metadata
Rank l33t++
Rank
l33t++

This is my board:
http://www.abc-cpu.com/temp/xt1.JPG
I have removed the sticker but there is nothing underneath.

I have a jumper for 10/12 MHZ and turbo button on/off.

cga_comp detects it as a V20 11MHz (both 10 and 12) with turbo on
and as V20 4,77MHz (both 10 and 12) with turbo off

fs105patched has all these problems with all 4 possible MHz options. (The plane in demo doesn't even take off, it crushes while wheeling)

Reply 31 of 48, by angrylion

User metadata
Rank Newbie
Rank
Newbie
peterferrie wrote:

The problem is the different hardware behaviour between 8088 and 8086+ CPUs.

I think it's incorrect. According to chapter 14.7 of 386 Programmer's Reference Manual and Appendix C to 286 PRM, int 0 handling is a difference between 8086/8088 and 286+.
By the way, in these chapters of said Intel documents one can read about more than dozen incompatibilities between 8086/8088 and the real-mode of 286+, so adding a "pseudo-8086" cputype might be worth considering.

Reply 33 of 48, by angrylion

User metadata
Rank Newbie
Rank
Newbie

The same thing about int 0 handling is said in 4 Intel documents at the very least: two said PRMs, another 286 document and in 8086 Family User's Manual.
Did peterferrie run hardware tests on 8086 and 8088 side-by-side? If no, then it's just his speculation vs. behavior meticulously documented by Intel.

Reply 34 of 48, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

As i already said, no matter how many manuals you consult you will NEVER
get to the interesting parts which are the bits and pieces that were not documented
for a reason (bugs and backwards incompatibilities or bug fixes of old bugs that
should not surface publicly).

Did peterferrie run hardware tests on 8086 and 8088 side-by-side?

I don't know but given the FS tests on real hardware, the logics peter ferrie
derived from this are much more interesting than citing official docs.

Reply 36 of 48, by angrylion

User metadata
Rank Newbie
Rank
Newbie
wd wrote:

I don't know but given the FS tests on real hardware, the logics peter ferrie
derived from this are much more interesting than citing official docs.

So it has been confirmed that, contrary to manuals, the original unpatched game doesn't work on 8086 and works on 8088? Who tested that?