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

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.

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 😀

It can be fixed by cputype=8088

I won't add that unless it's assured how exactly the respective CPU behaves in those cases.

386 core also has pentium stuff.

No it doesn't, besides that there's no 386 "core".

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

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.

At least it now works with DOSBox with the patch. MS Flight Simulator 1.05 also seems to work with a real 8088 patched.

fs105 and fs213 work on my JUKO ST 12MHz
fs105patched does not work properly:
- after running demo you see both sky and ground green, after a few seconds both switch to blue and plane "splash", apears again and doesn't move forward.

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.

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)

Thanks; patching isn't needed for a PC/XT/Clone, but would be nice if it worked for either. Probably shouldn't have added all this discussion to a sticky thread, but perhaps a mod will do a cleanup.

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.

You're aware that the CPUs were not built after the reference manual?

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.

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.

Wether the 8086 is different to the 8088 in that matter doesn't really bother us as 8086 PCs were not so common and i don't think we intend to emulate one. It's the differences 8088 vs 80286+ that do.

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?

Works on 8088, NEC V20
Doesn't work on 286

Don't know if 8086 was tested.

Then there's no evidence that the manuals (which documented that 286's divide overflow interrupt behaves not like 8086/8's as far back as in 1986) are wrong.

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