DOS ain't dead

> > If I use the same RTM + DPMI16BI as GVFM, it doesn't crash or reboot,
> but
> > it still doesn't work for those: runtime 200 error (which Veit's
> R200FIX
> > TSR doesn't help, sadly).
>
> Have you tried PROT200 instead of R200FIX?

No, I didn't try any of the various patch utils, only the aforementioned TSR. Maybe one of those (e.g. PROT200) would work, but I'm skeptical. :-/

> I don't know if they work
> exactly the same way or not, but it might be worth a try. I think there
> may even be a few other programs besides those two specifically designed to
> address the Runtime Error 200.

There are several, but they don't always work.

> Also, the Runtime Error 200 is actually a speed problem (the CPU is too
> fast, which indirectly causes a divide overflow), so a CPU slowdown program
> (like my SLOWDOWN.COM) or possibly even FDAPM with a SPEEDn option might
> help.

True, it's something to do with the timer or delay overflowing a 16-bit value on "fast" (250 Mhz?) cpus, heh, and this one (3200 Mhz) is definitely too fast!

Honestly, for something as heavily patched (and presumably with much 386 internals) as Chasm: The Rift, I have no idea what is needed. I'm not sure it can be run on real hardware. Maybe DOSBox is the only answer. The only reason I even tried was due to the alleged UIDE bug (and admittedly I can't think of a lot of public BP7 programs offhand). I just assume BP7 is buggy because it barely ever works, but perhaps it's just rarely tested anymore. Even DOSEMU (x64) didn't like any of it at all (no surprise, their 16-bit emulation would have to be very precise).

I don't know, what else can we do? Without emulators, we're screwed. We don't have sources (or even necessarily the compiler), so it's pretty much dead if it doesn't work with a little tweaking. I hate that, but that's the way it is.

But what other BP7 apps are people on this forum actively running? It would be nice to know what is considered worth preserving or essential, esp. by fellow DOS-heads.

> I don't know if "unknown" is the word here. 16-bit pmode never strictly
> targeted beyond 286 (16 MB), did it?

Yes, but the Borland extender is not really "286 only", because then it would restrict itself to allocate 16 MB - or 15 MB. However, it tries to allocate almost 64MB (65535 kb).

My guess is: the Borland extender uses the 16-bit version of LGDT or LIDT, which works with 24-bit addresses only. If you can find the occurances of these instructions in the extender, a patch may be possible. However, the patch may be tricky, because the 32-bit versions of these instructions requires an additional byte (66h).

---
MS-DOS forever!

> Isn't there possibly a better way at runtime without having "yet another"
> CONFIG.SYS option? Perhaps loading a big RAM disk (temporarily), e.g.
> SHSURDRV, to eat up some RAM? Or maybe "SET DPMIMEM=MAXMEM 16383" or
> whatever? (untested)

No, DPMIMEM= didn't seem to help here at all, but admittedly I didn't test every combination.

Well, for CHASM-SW.RAR, at least, the answer is as follows:


md chasm
cd chasm
unrar x \zips\games\chasm-sw.rar
hdpmi16.exe
fdapm.com speed3
chasm.exe


Otherwise, something somewhere decides to reboot the computer (seemingly using FDAPM, but it could be something else). Of course, this specific BP7 example by itself never rebooted, only wouldn't run due to "Runtime 200" error, which no other fixes seemed to help.

Anyways, this way (HDPMI16 + FDAPM SPEED3) seems to work with or without UIDE regardless. But of course YMMV for other BP7 stuff. (And of course this doesn't fix lack of sound card support, *sniff*, not even PC speaker works for this game.)

P.S. Honestly the few times I've weakly tried to use HDPMI16 recently, it seemed to act weird or not work at all. Perhaps it was other stuff, though I just blindly assumed it couldn't handle seeing all my RAM. But it works here, at least. Very confusing.