Hello Rugxulo,
About the shareware edition: it did the same for me (crashes at exit
with a hellish BEEEEEEEP), but again, only if I don't give enough "low
XMS" memory to Doom. Since my Ultimate Doom problem is solved, the
Shareware edition runs fine, too (and quits fine also). You use big
caches yourself, and a rather big RAMDisk also, so I bet your problem is
exactly the same than mine.
SHSURDRV: I haven't triedyet, but as said previously I will, and then I
will definitely report here the result. For now I can only say that
xmsdsk /t works very well.
Limiting LBACACHE: I thought about another solution that I will test at
the next possible occasion - in my Autoexec, I will allocate a RAMDisk
"x:" of 32M at the very start, then do all my resident stuff (caches,
real ramdisks, etc), so these will have to go in some higher XMS memory,
and at the end of my autoexec I will deallocate the "x:" ramdisk. This
way I *think* I should have a universal solution, that will give "low
XMS" memory to my applications independently of the number of things I
load into XMS residently. Of couse it would be better that LBACACHE
support a 'top to bottom' allocation, because then I wouldn't end up
with fragmented RAM memory. Jack tells me also about the /R switch on
UIDE - this would probably have the same effect than me allocating a
temporary RAMdisk before loading my caches, and then freeing this
RAMdisk once I'm set.
To sum up, I think the whole "problem" is not really a problem, nor
really a bug, I rather consider it an additional requirement. Some
applications require "low XMS" memory (presumably XMS memory below the
16M address level), that's all. Once one is aware of such requirement,
it's pretty easy to work around this. And it should be a motivation to
XMS resident apps authors to include some switches to prefer taking top
XMS memory rather than the bottom one :) (or even do this by default).
Mateusz
On 28/06/2015 02:04, Rugxulo wrote:
> Hi,
>
> On Sat, Jun 27, 2015 at 4:59 PM, Mateusz Viste <mate...@viste.fr> wrote:
>>
>> I understand your "utilitarian" way of thinking, but this is a specific
>> case for me. There are some pieces of software that I consider "museum
>> grade" and that I want to keep running it their full legacy glory, as
>> much as possible. Ultimate Doom is one of them.
>
> I'm not saying don't use it, but at the same time, if it's more
> trouble than it's worth, then just use a different extender or main
> .EXE (port) entirely. That way the game still runs, maybe even better,
> and you don't lose anything, only bugs.
>
> There's nothing wrong with keeping history or trying to be less
> intrusive in fixes/workarounds. But keep in mind that Doom has been
> GPL since 1999, so there's no "good" reason to stick to a buggy
> (default) build ... if it doesn't work well.
>
> BTW, I forgot I had Doom 1.9 (shareware) here (circa 1995), so I did a
> quick install (no music, PC speaker sfx). It played just fine for
> several levels, using default extender ... until I quit the game, then
> it crashed/hung/beeped with MCB error. :-P And that's on a more
> modern machine than yours, of course not running LBACACHE but still
> using ("Mar-05", 2015) XMGR, UIDE, RDISK.
>
>> About the general problem: I did already found a working solution
>> (although my previous mail was maybe unclear in this aspect).
>> To keep things short:
>> - Doom apparently requires a few megs of XMS memory to be available
>> under "low" addresses (below 16M or so)
>
> I didn't change anything, same setup of mine as always (UIDE /S127,
> XMGR /N128, RDISK /S150). BTW, a naive look inside DOOM.EXE shows
> "DOS/4GW Professional ... Nov 23 1993 ... 1.95". Yet no crash/hang at
> exit under DOSEMU (but which has its own DPMI server, thus indirectly
> avoiding the issue). N.B. PC speaker sound is almost useless under
> DOSEMU (unlike native DOS), the exact same buzz for literally every
> sfx.
>
>> - to achieve that, either make sure you don't load too much resident
>> stuff into XMS (small lbacache is ok), or move the resident stuff as far
>> to the end of the XMS universe as possible (xmsdsk /t)
>
> Did you try SHSURDRV? At least that's free (since he told me it's ZLIB
> license).
>
>> So all in all, it works for me, and I'm happy. My previous mail was
>> trying to say I'm good now, and pointing to the conclusions and
>> solutions I found just in case anyone would wonder about the same
>> problem in ten years or twenty years from now.
>
> Forget ten or twenty years, what about now??
>
> http://store.steampowered.com/app/2280/
>
> I don't use Steam, but I can only guess what it requires. It at least
> says "XP/Vista". Who knows if that means DOSBox (which is explicitly
> not a real DOS, only meant for games, probably has hardcoded fixes for
> bugs like this!). Maybe it (also) works under (Steam) Linux, dunno,
> maybe DOSBox, but they probably have their own preferred Doom port
> (PrBoom?? Chocolate??). EDIT: Even Freedoom only recommends Odamex and
> PrBoom+ these days.
>
>> Limiting LBACACHE to 4MiB is a price to pay also, but I can live with that.
>
> But you shouldn't have to! At least, having a separate CONFIG.SYS
> entry just for one game seems silly when it can be avoided entirely
> (although I'm not so sure, but anyways).
>
> P.S. I vaguely remember trying this same Doom shareware demo a while
> back under VBox, where it had even more bugs, even with VT-X. I really
> do just think the "old" .EXE is just buggy. I'm not saying all the
> (abandoned) DOS builds are any better, unfortunately, just saying ...
> we could indeed recompile it, if forced.
>
------------------------------------------------------------------------------
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
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
