[Freedos-user] (no subject)
Dears, I need your help. I try to boot to my desktop (Windows XP) via usb-flash with FreeDOS (VERSION 0.84-PRE2 XMS_Swap). My problem is that by the normal booting check disk stucks to 27%.So through freedos I try to bypass check disk but I don't know which command I have to use. Note that using "chkdsk" command I get the message "bad command". I also do not the name of my had disk in the freedoss environment. Among others I need a list of freedos command which corresponds in the freedos version I use. Thanks in advanceJim -- 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
Re: [Freedos-user] [solved] Doom unstable with LBACACHE or RDISK
On Sun, 28 Jun 2015 16:50:25 -0400, Mateusz Viste wrote: > On 28/06/2015 20:03, Rugxulo wrote: >> "Below 16M"? You mean for DMA or the like? > > I have honestly no idea what the 'low-level' implications are. If > someone asked me 2 days ago, I'd say that's impossible, since an > application only requests XMS "handles" from the XMS driver, and > performs all moves from/to XMS by calling the XMS driver over a small > 64K window of data... Hence the application is not aware at all where > physically the memory it gets is located at. DOOM is a 32-bit program, it doesn't use 64KB segments. It doesn't even need an XMS driver installed to run. BTW, I tested DOOM 1.9 on my FreeDOS install and got similar results. My system is a Pentium III 600e, 192MB of RAM, with an ISA Sound Blaster 16. If I have a large (40MB) UIDE disk cache active then the system halts upon exiting the game. Under Windows 98 DOS, it crashes with a GPF if I have a 32MB SMARTDRV cache. It does seem like a bug in the old DOS4GW. -- 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
Re: [Freedos-user] [solved] Doom unstable with LBACACHE or RDISK
Hi Mateusz, > Actually, by taking a closer look I did find the function 0Ch from both > the XMS 2.0 and 3.0 standards. This function returns the physical > address (called "base address" for the occasion) of the allocated XMS > block as a 32bits integer. > > Now, I could imagine an application (like DOS4GW) that gets such address > and puts it into a 24bit field. Such behaviour would effectively limit > an application to being able to use only the lowest 15MB of the XMS memory. Wikipedia says: https://en.wikipedia.org/wiki/DOS/4G * DOOM was the first game to make dos/4g or dos/4gw popular * it was limited to 64 MB of memory So I can imagine that Doom uses a really old version of dos/4gw, which is even more likely to have issues with "too much RAM" ;-) "We expect to be updating the DOS extender to use the extended XMS and VCPI calls that allow access to greater than 64MB" That sounds as if it is in any case limited to XMS 2. Have you made some comparisons between XMS-only and EMM386-style behaviour of DOOM? http://www.tenberry.com/dos4g/rn4g.html Version 2.01 (1996) mentions some fixes for systems with above 64 MB of memory and even for properly supporting 64 MB in the first place. I repeat my advice of using DOS32A instead of working around DOS/4G. DOS32A is free open source while DOS/4G came in version 1.97 with old Watcom compilers while 2.01 was only available as paid update: http://www.tenberry.com/dos4g/watcom/prices.html Which version does your copy of DOOM use? Cheers, Eric -- 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
Re: [Freedos-user] [solved] Doom unstable with LBACACHE or RDISK
On 28/06/2015 22:50, Mateusz Viste wrote: > I quickly (re)read > the XMS v2.0 standard, and haven't found any function that would even > communicate the physical address of the data back to the application... Actually, by taking a closer look I did find the function 0Ch from both the XMS 2.0 and 3.0 standards. This function returns the physical address (called "base address" for the occasion) of the allocated XMS block as a 32bits integer. Now, I could imagine an application (like DOS4GW) that gets such address and puts it into a 24bit field. Such behaviour would effectively limit an application to being able to use only the lowest 15MB of the XMS memory. All this is pure speculation on my part of course, but at least it's "some" plausible theory. Anyway, this doesn't matter much, since the limitation itself is clearly there, and there are ways of dealing with it (as described in my previous messages). Mateusz -- 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
Re: [Freedos-user] [solved] Doom unstable with LBACACHE or RDISK
On 28/06/2015 20:03, Eric Auer wrote: > As mentioned earlier, all those tricks are just working around > annoying limitations of the totally outdated DOS extender used > by DOOM. The better solution is to replace that: Use DOS32A or > load a resident instance of CWSDPMI while playing DOOM :-) While I do agree with the raw technical argument that DOS32A seems superior to DOS4GW, it's still my opinion that it's saner to have a system that can accommodate such XMS requirements rather than "patching" the game/program with third-party bits. For DOS4GW there's a possible DOS32A replacement, sure, but what if another (non-DOS4GW) application happens to have a similar requirement regarding low-address XMS availability? Having a system that fulfils such condition (which I have now) makes me able to run such program without pain. While if I had bypassed the Doom problem using the DOS32A shortcut, any other "need-low-XMS" application would potentially still fail, without me necessarily knowing why. Mateusz -- 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
Re: [Freedos-user] [solved] Doom unstable with LBACACHE or RDISK
On 28/06/2015 20:03, Rugxulo wrote: > "Below 16M"? You mean for DMA or the like? I have honestly no idea what the 'low-level' implications are. If someone asked me 2 days ago, I'd say that's impossible, since an application only requests XMS "handles" from the XMS driver, and performs all moves from/to XMS by calling the XMS driver over a small 64K window of data... Hence the application is not aware at all where physically the memory it gets is located at. But all the above belief of mine have been ruined recently, when I looked into my Doom issue. It does seem after all that 'where physically the XMS memory comes from' can be of some importance. I quickly (re)read the XMS v2.0 standard, and haven't found any function that would even communicate the physical address of the data back to the application... So I have no clue what DOS4GW does. But apparently it does something that works fine only if the XMS pool it obtains comes from some "low" XMS area. I also found a few programs that vaguely talk about this: XMSDSK says: > Some machines under Win95 hang up when there's no free memory under > 16 MBytes. It can be used too if you have problem playing sounds > under Windows. These 2 issues seem to be related to DMA buffering. SHSURDRV says: > This option will allocate memory before any drives, then release it > upon exit. It is only necessary in order for Windows to start (when > drives exceed more than 14MiB in total). The default is 4 > (kibibytes). UIDE says: > /R15 reserves 15-MB of XMS, and /R63 reserves 63-MB of XMS, for DOS > game programs that require XMS memory below 16- or 64-MB! > Dunno, for all I know it could be (only) soundcard related, thus any > Doom ports that don't use that library (e.g. use Allegro instead) > won't have the bug. I do not think it's related to the sound card. In fact, the first thing I did two days ago was to run Doom with no sound at all - the problem was still the same. >> 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). > > I don't think that's feasible. Fortunately both XMSDSK and SHSURDRV do it perfectly, that's enough for me :) Mateusz -- 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
Re: [Freedos-user] [solved] Doom unstable with LBACACHE or RDISK
Hi, On Sun, Jun 28, 2015 at 12:28 AM, Mateusz Viste wrote: > > About the shareware edition: it did the same for me (crashes at exit > with a hellish BEEEP), 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. I just tried 1.9 shareware under VBox, which seemed to work fine (even Sound Blaster, although no music, only sfx). > 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. I did, prior to running under VBox, make SHSURDRV use /T, and it indeed did *not* crash or hang upon exit. I even ran a simple compile test of something else afterwards just to prove it. I mean, that's not exhaustive by any stretch, but it seems to be a valid workaround. > 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. "Below 16M"? You mean for DMA or the like? Dunno, for all I know it could be (only) soundcard related, thus any Doom ports that don't use that library (e.g. use Allegro instead) won't have the bug. BTW, Allegro 4.x could indeed be built with OpenWatcom, but I guess nobody cared enough to port Doom back (since DJGPP was good enough). > 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). I don't think that's feasible. -- 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
Re: [Freedos-user] [solved] Doom unstable with LBACACHE or RDISK
Hi Mateusz, > - I don't like the idea of having fragmented XMS memory Indeed. See below... > - UIDE seems to interact with my soundcard - when UIDE is loaded, I > loose FM music in Wolfenstein 3D Strange. > - UIDE is not open-source anymore, while LBACACHE is both open-source > and still (somewhat?) maintained Well XIDE is not open source and UIDE is not maintained, but there have been no updates for LBACACHE for several years :-p While the most recent open source UIDE is only 3 months old. UIDE and XIDE might differ quite a bit, too. You could take a recent UIDE version and start maintaining it if you prefer. Some people see XIDE as closed source continuation of UIDE, I see it as closed fork, but it could be a rather different implementation of ideas known from UIDE and no actual fork. > 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. As mentioned earlier, all those tricks are just working around annoying limitations of the totally outdated DOS extender used by DOOM. The better solution is to replace that: Use DOS32A or load a resident instance of CWSDPMI while playing DOOM :-) The old (DOS4GW or similar) DOS extender used by DOOM might be designed with 286 or 386 or XMS 2 in mind, lacking imagination that usable RAM could exist beyond the first 16 or 64 MB... ;-) Cheers, Eric -- 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
Re: [Freedos-user] [solved] Doom unstable with LBACACHE or RDISK
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 BEEEP), 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 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 D
