Hello, here is my last batch of tests:
SHSURDRV /T works perfectly, so I use it now instead of XMSDSK /T (the
former being open-source, while the latter is not).
I also tested UIDE with its /R63 option following Jack's suggestion
offlist, and it makes Doom work, even with big caches (I tested 25M of
cache). UIDE's /R63 is designed exactly for my need (giving older games
some low-XMS space, and loading UIDE cache above 64M). But this solution
is not the one I will use, because:
- I don't like the idea of having fragmented XMS memory
- UIDE seems to interact with my soundcard - when UIDE is loaded, I
loose FM music in Wolfenstein 3D
- UIDE is not open-source anymore, while LBACACHE is both open-source
and still (somewhat?) maintained
The final clue is to remember that some applications need "low" XMS
memory, so for such applications one should always try to load resident
XMS stuff somewhere else. For my personal situation, the winning duo is
LBACACHE with a small cache (not more than 4MB, and some hopes that
maybe in some utopian future LBACACHE will gain a /T option?) + SHSURDRV /T.
Mateusz
On 28/06/2015 07:28, Mateusz Viste wrote:
> 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
