On Sat, Jun 27, 2015 at 12:45 PM, Mateusz Viste <mate...@viste.fr> wrote:
> I'm almost sure nobody cares, but here's a little follow-up on my
> Doom/XMS troubles, maybe some future generations will find this somehow
> useful.

Of course we care, but "Ultimate Doom" sounds like a commercial
variant, thus not shareware. So it's harder for us to reproduce
(although our RAM amounts, configs, and other details would differ

A very very superficial Google search shows this: "... is an updated
version of Doom released on April 30, 1995, that adds a fourth
nine-level episode, Thy Flesh Consumed ...."

> A few details first, that I should have included in my first message
> probably:
>   - When I run "Ultimate Doom" while RDISK or LBACACHE is loaded, the
> game freezes immediately, or makes the computer reboot

Keep in mind that this is an old (unsupported) game, meant for 386s
and 486s back when it first came out (late '93?). It had various bugs
and did various weird things.

>   - I have 128MB of RAM

Isn't there some setting for limiting memory available to DOS4G? (BTW,
IIRC, Doom uses DOS4G [sic] Professional, which was [also] buggy and
not widely [freely] updated.)

Okay, so a cursory check of DOS4GW.DOC (included with OpenWatcom 1.9)
shows various examples, so you could try one of those (or similar):

"set DOS16M= @ 0 - 5m"

>   - RDISK version 4-aug-12 creates a 32M RAMdisk

I don't think he updated RDISK at all in recent months, but at the
same time, you should "probably" try as new a version as you can, just
to be safe, which is "Mar-05" on iBiblio.

>   - LBACACHE is used with a 16M XMS cache

What happens if you "STOP" it before running Doom?

>   - XMS is provided by HIMEMX v3.32
> Today I tried several things, I list below only the interesting parts:
> Changing HIMEMX v3.32 to XMGR v4-aug-12 doesn't change anything. The
> problem seems independent from the XMS provider.

There's also FDXMS or even FDXMS286 (as I doubt Doom is intentionally
using more than 8 MB).

> Changing RDISK to XMSDSK doesn't change anything either. BUT using
> XMSDSK with its /t switch makes the problem go away (yaay!). /t means
> that xmdsk will allocate memory at the end of the available memory block.

Like I said, Doom is buggy. Honestly, if all of the newer DOS Doom
"ports" weren't buggy and abandoned themselves, I'd suggest you use
one of those. I know you're familiar with Boom (compiled by DJGPP).
That doesn't mean it's bug-free, but I think the original Watcom one
was doing lots of messy stuff (semi-undocumented calls or

> I assumed then that Doom might require some XMSDSK from the low XMS area
> - XMSDSK states in its readme file that some applications might have
> such odd requirement...

It was very rare in 1995 for anybody to have more than 16 MB of RAM,
if even that much. Even Quake only barely supported such a setup
(under Win95), thanks to CWS.

Besides, back to DOS4G (etc) ... wasn't that horribly limited in total
RAM supported anyways?? Something like 32 MB or 64 MB, I forget.

I have no idea, it's like grasping at straws. The point is that nobody
tested such things on newer hardware. I think most people just took
the lazy way out and just used newer Win32 or Linux ports, so bugs
never got fixed.

> This still doesn't solve my LBACACHE problem - so assuming that Doom
> needs some "low" XMS memory, I lowered the LBACACHE cache size from my
> initial 16M to 4M, and the miracle happened - Doom runs fine now (with
> both a RAMdisk with xmsdsk and LBACACHE).

You have to eliminate as many conflicting pieces as possible. Try
running without LBACACHE entirely.

> Hence it would look that for some reasons Doom needs XMS memory that is
> available under some specific addressing level (does this make any sense?).

Dunno, but it's possible.

> Unfortunately, neither RDISK nor LBACACHE provide a way of consuming XMS
> memory from the top (instead of from the bottom) of the available
> memory, so I am apparently left with the only choice of not using RDISK
> at all (xmsdsk does an equally good job, but a FREE alternative would be
> highly preferable), and using lower size for LBACACHE.

Did you try SHSURDRV? (It has "/T   Allocate at the top of XMS.") SRDISK?

Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical & virtual servers, alerts via email & sms 
for fault. Monitor 25 devices for free with no restriction. Download now
Freedos-user mailing list

Reply via email to