[DOS/4GW] Help needed. We are almost there, the perfect DOS machine

[Caldor]

hi

strange thing with memory i think

main descentr.exe from descent game crash (DOS/4GW Pro 1.97) with 16mo or 256mo config

i have push DOS/4GW PRO 2.01 in exe and it work

(descentr.le in zip is exe without DOS/4GW include)

I think this suggests its again not a memory problem but something else the newer version fixes that DOS32A also fixes.

[Caldor]

Actually, it probably just confirms that for Descent the issue is the amount of RAM. The problem with DOS4GW is that some of the older versions only supported a max of 64mb RAM. Seems like DOS/4GW PRO 2.01 might be a version that fixes that.

There is a nice page here that talks about 2.01a being the newest version of DOS/4GW Pro and how it has a lot of fixes, but also that its not free. It then also goes into several alternatives.
https://maximumhoyt.blogspot.com/2008/1 ... ative.html

[user7182]

When I run the VHD from this issue:
https://github.com/MiSTer-devel/ao486_MiSTer/issues/45

I can see DOOM crash. When I run pminfo.exe it reports values that don't appear correct:

pminfo.png (490.33 KiB) Viewed 5955 times

Maybe that's a hint? If I run QEMM for example I don't see values of 0.

pminfo_qemm.png (486.18 KiB) Viewed 5955 times

[flynnsbit]

When I run the VHD from this issue:
https://github.com/MiSTer-devel/ao486_MiSTer/issues/45

I can see DOOM crash. When I run pminfo.exe it reports values that don't appear correct:

pminfo.png

Maybe that's a hint? If I run QEMM for example I don't see values of 0.

pminfo_qemm.png

Agreed, that looks suspect. If you set the mister to the full 256MB, and then fill up the memory with XMSDSK to say, 8MB left of extended memory, does it still do that? I am at work or I would try it.

[Caldor]

hi

strange thing with memory i think

main descentr.exe from descent game crash (DOS/4GW Pro 1.97) with 16mo or 256mo config

i have push DOS/4GW PRO 2.01 in exe and it work

(descentr.le in zip is exe without DOS/4GW include)

I think this suggests its again not a memory problem but something else the newer version fixes that DOS32A also fixes.

I think I will begin to try and see what other games DOS/4GW 2.01 might help fix.

Something else I have thought about is that AO486 is based on Bochs an open source emulator. Maybe this is a general problem with the BOCHS emulator that it causes these memory issues? Possibly because its written in a way that expects certain things to be done the way they are supposed to be done when it comes to memory handling?

[user7182]

If I could summarize what I think I understand:

• DOS4G/W is included in a lot of games, and it has bugs that cause the games to crash. (It wasn't totally broken, many people played these games fine back in the day)
  They have a list of bugs here: https://web.archive.org/web/20190123202 ... rn4gw.html
• To work around bugs that effect you have to change your hardware configuration, software configuration, or replace the buggy DOS4G/W with a new DOS extender, normally DOS32/A.

There's been suggestions that even on real systems running with 256MB of RAM breaks old DOS games unless you change to a newer DOS extender. This makes sense to me, if someone wrote their software to track free space in a 16-bit integer, you're number will wrap if you have more free space than can be stored.

One work around suggested is to use XMSDSK to consume enough memory so the free space remaining seen by the game is less than 64MB.
https://www.vogons.org/viewtopic.php?f= ... sk#p994765

However I've been struggling to narrow down a simple test case where I can reproduce a problem that I can point the finger at the DOS4G/W. If changing RAM to 16MB had a positive effect on a game, then I can see the logic to try and make an AO486 build that has 64MB to allow us to run more "Terminate-Stay-Resident" programs, as well as the original games (which together may exceed 16MB).

For example if I try to install Red Alert (as was discussed on another thread) which runs DOS4G/W 2.0, it locks up when trying to copy files. I'm running FreeDOS and I have a few startup options FreeDOS gives me

• With JemExx: I get an exception running setup.exe, doesn't even start.
• With Jem386: Setup runs, but freezes when copying files.
• Safe Mode: Install runs fine.

If I drop my RAM setting from 256MB to 16MB, I can now start setup.exe with JemExx, but the setup locks up copying files. And even when setup completes and I go to the c:\westwood\redalert folder, most of the files haven't actually been copied. Now changing the RAM settings definitely makes the software start or crash with exception, but is this a bug in FreeDOS/JemExx or DOS4G/W? Why does copying files seem to work sporadically?

Trying to run Descent, I can install fine, but when I run the game I get different errors:

• With JemExx: I get an invalid op code exception.
• With Jem386: I get a divide by zero exception.
• Safe Mode: A bunch of invalid op codes
• No drivers: Two invalid op code errors.

I found some test programs already written for DOS which could be helpful in tracking down some of our problems in a more controlled way:
https://github.com/joncampbell123/doslib

As far as I can tell most of the test programs run with DOS32/A, but we could switch it back to DOS4G/W and try to create the original bugs reported by Tenberry in an effort to make AO486 more compatible with the buggy software. There are some bugs about RAM size in their release notes, but even if we avoid that problem we may crash because of some of the other bugs.

I think I'll focus on why Descent crashes because it crashes so quickly, and I'll use an MS-DOS environment rather than FreeDOS.

[Caldor]

FreeDOS has compatibility problems. One test I often use for DOS compatibility is Game Wizard. Its a bit like Arcade Replay and such that helps with memory alteration, cheats and other things. FreeDOS cannot run Game Wizard at all, I have tried several setups, so on a real DOS machine, I would guess FreeDOS would have the same issues, just like a real DOS machine would have DOS4GW issues if it has more than 16MB of RAM and its an older version of DOS4GW.

FreeDOS is pretty great, has some pretty awesome and very optimized drivers, and I do prefer FreeDOS when it comes to how nice it is for using DOS, its autocomplete features and such. But most of those features comes from extra software that can be used with DOS 6.22 or DOS 7 as well. DOS 7 is almost as compatible as DOS 6.22 and also supports FAT32 partitions. I use DOS 7 primarily and sometimes I use DOS 6.22.

[keith.f.kelly]

I've finally gotten around to trying out the ao486 core, and I've quickly run into the same issues with Warcraft II and other DOS/4GW games under MS-DOS 6.22.

I've got the 2.01a version of DOS4GW.EXE, but I can't use it to run WAR2.EXE:

Code: Select all

DOS/4GW fatal error (1008): can't load executable format for file WAR2.EXE [1]

I've also tried switching the hardware configuration to 16MB as others here have suggested that might help, but WAR2.EXE still crashes out from its built-in DOS/4GW 1.97, and I still get the same error quoted above when I try to run it explicitly using DOS4GW.EXE v2.01a.

How can I get Warcraft II running under MS-DOS 6.22? Or is that still just impossible at present?

[amstan]

How can I get Warcraft II running under MS-DOS 6.22? Or is that still just impossible at present?

I run it from flynnsbit's distro, it was patched with dos32/a I think: viewtopic.php?f=13&t=1531
Works great, already finished first orc campaign.

[breiztiger]

can you try this please ?

[keith.f.kelly]

Thanks, I'll give that a shot!

How does one go about patching an EXE to embed a different DOS4GW.EXE or DOS32A.EXE? I have a large library of "No-CD" modified game EXEs that will need the same process applied.

[user7182]

Thanks, I'll give that a shot!

How does one go about patching an EXE to embed a different DOS4GW.EXE or DOS32A.EXE? I have a large library of "No-CD" modified game EXEs that will need the same process applied.

There's a tool called 4GWBIND that came with DOS/4GW Professional that can do it.

To unbind:

Code: Select all

4GWBIND -U <boundapp.exe> <yourapp.exe>

[flynnsbit]

and DOS32a's "SB" command can also do it and or replace the stub with the 32a version. That's how I usually do it. https://www.javiergutierrezchamorro.com ... til/1.html

[amstan]

Anyway, so are we any closer to figuring out what's missing/different in our core to run the unmodified dos4gw stuff? It does sound like we have plenty of usable workarounds, but they're not as neat as getting to the bottom of it.

[keith.f.kelly]

and DOS32a's "SB" command can also do it and or replace the stub with the 32a version. That's how I usually do it. https://www.javiergutierrezchamorro.com ... til/1.html

That works beautifully! Thanks!

[held]

If I could summarize what I think I understand:

• DOS4G/W is included in a lot of games, and it has bugs that cause the games to crash. (It wasn't totally broken, many people played these games fine back in the day)
  They have a list of bugs here: https://web.archive.org/web/20190123202 ... rn4gw.html

I think DOS4GW searches for a newer version in PATH and runs that instead.

[held]

Thanks, I'll give that a shot!

How does one go about patching an EXE to embed a different DOS4GW.EXE or DOS32A.EXE? I have a large library of "No-CD" modified game EXEs that will need the same process applied.

Does DOS32A MYGAME.EXE not work on MiSTer ?

[the_muteKi]

Thanks, I'll give that a shot!

How does one go about patching an EXE to embed a different DOS4GW.EXE or DOS32A.EXE? I have a large library of "No-CD" modified game EXEs that will need the same process applied.

Does DOS32A MYGAME.EXE not work on MiSTer ?

Not when the extensions are embedded in the file. You'd have to un-embed them first. That's the case on any system, just usually less of an issue because most dos4gw setups work better

[held]

I have no idea what you are saying, sorry :/

Afaik DOS4GW searches PATH for a newer version, and runs it when found bypassing itself. So I do not understand why one would start hacking into the game executable. Besides I can run Warcraft II fine with the "dos32a war2.exe", bypassing DOS4GW completely. Thus the same should work for a newer version of DOS4GW.

CWSDPMI (also a DOS-extender) refuses to run at all, unfortunately. So I think the core still has to mature more and issues like these will resolve over time.

Personally I would only start patching if everything else fails.