DOS memory management. My all-time favorite game.
😁

keropi wrote:

One game that comes in mind is Fade To Black that it did not had cinematics when using SHSUCDX ...

Fade to Black is rather obnoxious about trying to determine whether you have a 2x CD-ROM drive. There have been threads about it before; it is fixable with a command-line parameter.

What other games have you had problems with?

@Jorpho: nope, the parameter does not help it, it still misses video cutscenes.... I did made my research 😀
sadly at the moment I do not remember what other games where "the last draw" so I reverted to mscdex... 🙁 it's been almost a year

Good to know about the SHSUCDX issues! Will stick to recommending MSCDEX from now on 🤣

Yeah there are a lot of interesting alternative drivers and memory managers out there but I tend to stick to the MS stuff because the games were tested with them. It works. There isn't much more that I want 🤣.

I suppose if you're fighting with SCSI drivers (etc) taking up lots of conventional and upper memory that the alternatives might be useful. But the more you complicate things the more problems you are going to run into.

I am having a question.... why in my machine MSDOS consumes 22kb??? Is it a windows98SE-DOS issue?
(I have made a custom DOS setup using windows98... ALL windows98SE stuff are gone, the machine boots normally to a dos-only enviroment. ...and I did it for the native FAT32 support in case anyone wonders 🤣 , maybe there is a fat32 "driver" that consumes all that mem?)

1
2Modules using memory below 1 MB:
3
4  Name           Total           Conventional       Upper Memory
5  --------  ----------------   ----------------   ----------------
6  MSDOS       22.160   (22K)     22.160   (22K)          0    (0K)
7  HIMEM        1.120    (1K)      1.120    (1K)          0    (0K)
8  CDROM        5.040    (5K)      5.040    (5K)          0    (0K)
9  EMM386       4.320    (4K)      4.320    (4K)          0    (0K)
10  DISPLAY     18.096   (18K)          0    (0K)     18.096   (18K)
11  COMMAND     10.192   (10K)          0    (0K)     10.192   (10K)
12  MSCDEX      28.032   (27K)          0    (0K)     28.032   (27K)
13  CTMOUSE      3.584    (4K)          0    (0K)      3.584    (4K)
14  Free       655.328  (640K)    622.480  (608K)     32.848   (32K)
15
16Memory Summary:
17
18  Type of Memory       Total         Used          Free
19  ----------------  -----------   -----------   -----------
20  Conventional          655.360        32.880       622.480
21  Upper                  92.752        59.904        32.848
22  Reserved              393.216       393.216             0
23  Extended (XMS)*    65.967.536       578.992    65.388.544
24  ----------------  -----------   -----------   -----------
25Press any key to continue . . .
26  Total memory       67.108.864     1.064.992    66.043.872
27
28  Total under 1 MB      748.112        92.784       655.328
29
30  Total Expanded (EMS)                 33.947.648    (32M)
31  Free Expanded (EMS)*                 33.554.432    (32M)
32
33  * EMM386 is using XMS memory to simulate EMS memory as needed.
34    Free EMS memory may change as free XMS memory changes.
35
36  Largest executable program size         622.464   (608K)
37  Largest free upper memory block          32.640    (32K)
38  Available space in High Memory Area          64     (0K)
39  MS-DOS is resident in the high memory area.

OK, I had display.sys loaded (damned Infogrames installers 🤣) , removing that DOS takes 16kb and free conventional mem under EMS config is 634kb!!! will try to tweak some more now , and will make sure I use swaaye's order 😀

here is the EMS output that seems fine in my eyes, I don't use any non-ms memory managers at all:

1Modules using memory below 1 MB:
2
3  Name           Total           Conventional       Upper Memory
4  --------  ----------------   ----------------   ----------------
5  MSDOS       16,752   (16K)     16,752   (16K)          0    (0K)
6  HIMEM        1,120    (1K)      1,120    (1K)          0    (0K)
7  EMM386       4,320    (4K)      4,320    (4K)          0    (0K)
8  CDROM        5,072    (5K)          0    (0K)      5,072    (5K)
9  COMMAND      7,296    (7K)          0    (0K)      7,296    (7K)
10  MSCDEX      28,032   (27K)          0    (0K)     28,032   (27K)
11  CTMOUSE      3,584    (4K)          0    (0K)      3,584    (4K)
12  Free       681,680  (666K)    632,912  (618K)     48,768   (48K)
13
14Memory Summary:
15
16  Type of Memory       Total         Used          Free
17  ----------------  -----------   -----------   -----------
18  Conventional          655,360        22,448       632,912
19  Upper                  92,752        43,984        48,768
20  Reserved              393,216       393,216             0
21  Extended (XMS)*    65,967,536       578,992    65,388,544
22  ----------------  -----------   -----------   -----------
23  Total memory       67,108,864     1,038,640    66,070,224
24
25  Total under 1 MB      748,112        66,432       681,680
26
27  Total Expanded (EMS)                 33,947,648    (32M)
28  Free Expanded (EMS)*                 33,554,432    (32M)
29
30  * EMM386 is using XMS memory to simulate EMS memory as needed.
31    Free EMS memory may change as free XMS memory changes.
32
33  Largest executable program size         632,896   (618K)
34  Largest free upper memory block          48,560    (47K)
35  Available space in High Memory Area       1,040     (1K)
36  MS-DOS is resident in the high memory area.

and here is the XMS one, I would really like to find a way to actually use mscdex instead, do I need some UMB manager 3rd party thingie?: I think so, any recomendations?

1Modules using memory below 1 MB:
2
3  Name           Total           Conventional       Upper Memory
4  --------  ----------------   ----------------   ----------------
5  MSDOS       16,752   (16K)     16,752   (16K)          0    (0K)
6  HIMEM        1,120    (1K)      1,120    (1K)          0    (0K)
7  CDROM        5,040    (5K)      5,040    (5K)          0    (0K)
8  COMMAND      7,440    (7K)      7,440    (7K)          0    (0K)
9  SHCDX33C     6,400    (6K)      6,400    (6K)          0    (0K)
10  CTMOUSE      3,584    (4K)      3,584    (4K)          0    (0K)
11  Free       614,784  (600K)    614,784  (600K)          0    (0K)
12
13Memory Summary:
14
15  Type of Memory       Total         Used          Free
16  ----------------  -----------   -----------   -----------
17  Conventional          655,360        40,576       614,784
18  Upper                       0             0             0
19  Reserved              393,216       393,216             0
20  Extended (XMS)     66,060,288        69,632    65,990,656
21  ----------------  -----------   -----------   -----------
22  Total memory       67,108,864       503,424    66,605,440
23
24  Total under 1 MB      655,360        40,576       614,784
25
26  Largest executable program size         614,752   (600K)
27  Largest free upper memory block               0     (0K)
28  Available space in High Memory Area       1,072     (1K)
29  MS-DOS is resident in the high memory area.

(re: "SPEEDRV" in my posted CONFIG.SYS and AUTOEXEC.BAT files)

BTW, that was the HD and CDROM cache that I used to use. far better than SMARTDRV, and took a helluva lot less memory to run.

IIRC SPEEDRV was made by "Fast" (or possibly "Fast Track), and a stripped-out version was included with the old Norton Utilites (maybe v5.0, or v8.0?).

awesome awesome AWESOME!!!! using UMBPCI.SYS I get 637,040 free conventional under XMS config AND with mscdex loaded high!
That thread was an eye-opener for me that motivated my lazy ass to further investigate 🤣
I sure hope UMBPCI does not cause any compatibility issues ....

This is a very interesting thread.

In Windows, more memory means more fun. 😉 But in DOS, do games run more smoothly/better/faster if there is more extra free memory remaining, after the DOS game has taken what it needs for itself? What I am saying is - say if you have 600KB of memory, and your game must have 590KB. That leaves 10KB remaining. If I tweaked my auto/config files, and managed to get 610KB of memory, which leaves 20KB free memory, is this somehow "better", or will it make either no or little impact on the game's overall general performance?

Perhaps a game will take more memory for itself, if it sees that there is more free memory available? Perhaps that is why it is important to free up as much memory as possible?

retro: I think it's mostly about wanting to maximize available memory at the beginning, so that you can play a wide variety of games without having to worry about messing around to get specific ones to work.

Edit: Stickied, although I think this should maybe go in the DOS forum?

keropi wrote:

I sure hope UMBPCI does not cause any compatibility issues ....

After having used UMBPCI (and similar programs like URAM, RDOSUMB, etc...) for years, I have to say these are very compatible with games. I'm sure there are some programs which won't work with one of these drivers installed, but I couldn't recall any examples.

retro games 100 wrote:

is this somehow "better", or will it make either no or little impact on the game's overall general performance?

Most game either work or they don't.

Some games turn off "features" before totally refusing to start. E.g. Wing Commander is such a case and so is Flash Back. In such games you will miss out on animations or sound effects and things like that...

E.g. from the Wing Commander Qickstart Guide:

You must have between 560000 and 583000 bytes free to run the game (583000 bytes are required for full music)

So yea my take is to use memaker which will sort everything out for you. You might get a bit more through tweaking, but there are no gains to be found (apart from the feeling of achievement 🤣)

5u3 wrote:

keropi wrote:

I sure hope UMBPCI does not cause any compatibility issues ....

After having used UMBPCI (and similar programs like URAM, RDOSUMB, etc...) for years, I have to say these are very compatible with games. I'm sure there are some programs which won't work with one of these drivers installed, but I couldn't recall any examples.

SB Live's SB16 emulation init program doesn't work with UMBPCI

There are details of the issues and downsides on the UMBPCI web page.
http://www.uwe-sieber.de/umbpci_e.html

I think I'll stick with EMM386 and HIMEM.

DOS 6.22 FTW 🤣

There's also jemm and jemmex http://www.japheth.de/Jemm.html

Using it on a couple of machines...very compatible

So yea my take is to use memaker which will sort everything out for you. You might get a bit more through tweaking, but there are no gains to be found (apart from the feeling of achievement Laughing Out Loud)

I'm not so much doing it just for the sake of having as close to 640kb free conventional memeory as I can- its more to get one working config for the vast majority of games, so I don't have to resort to a boot menu to load different configs to play different games- which means if you want to play a certain game you need to restart the PC. I also wanted to keep my system as compatible as possible, so I wanted to stick with microsoft-provided drivers like HIMEM.SYS, EMM386.EXE and MSCDEX.EXE.
It should be noted that the DOSMAX utils I'm using isn't a replacement memory manager, they just do a few tricks to get parts of DOS to load high that normally don't.

The problem I was having was when EMS was enabled, certain TSR's wouldn't load high and would eat conventional memory- I was close to going below 580kb which is enough to stop some games from running. Scitech Display Doctor in particular doesn't like loading high when EMS is enabled- a common problem from what I've seen on the net. So it was looking like if I wanted to play a game that uses high res VESA modes, then played one that required EMS, I would need to reboot to swap configs for either game.

I could have disabled SDD, Smartdrv and other bells and whistles to free up upper memory but I decided I wasn't going to settle for that, and now I've got a heap of TSRs/drivers running with ~620kb free conventioal memory- all under one config. All the games I've tested so far run perfectly with this single config.

Even if you don't want to use dosmax, I got instantly positive results from simply adding these switches to emm386:
DEVICEHIGH=C:\DOS\EMM386.EXE AUTO RAM M3 A=64 H=128 D=256 HIGHSCAN X=B800-C7FF I=C800-EFFF I=B000-B7FF NOTR

This allowed SDD and some other utils to load into upper memory with EMS enabled. This would probably have freed up enoguh conventional memory for nearly all games to run. So even if you wanted to stick to microsoft provided drivers only, and avoid DOSMAX, this seems to be the go.

Using the UIDEJR.SYS CDROM driver is also a great help, because I could still use MSCDEX with it and its less than 1KB when loaded in memory, unlike OAKCDROM.SYS which was something like 27KB.

I'm planning to install a network card in this machine which will mean additional drivers- I don't think I'll be able to fit the card's drivers and protocol stack into upper memory (at least without getting rid of something else) but hopefully with the large amount of conventional memory I've got free at the moment, it won't cause any problems to have them loading low.

Well yeah the more stuff you want running makes things get trickier and trickier.

That EMM386 line scares me. 😉 It may be stable for you but that baby will not work for everybody. And I don't think DEVICEHIGH does anything when loading EMM386?

Why do you need SDD running all the time? Are you having VESA issues with your graphics card?

Only in certain high res games eg build engine. If I have it running all the time it saves having to load it when necessary- makes the system easier to use. I've got the memory to burn now, so why not 😁

The EMM386 line I'd expect would work for the majority of people with a basic setup- sound, video and IDE I/O card- as long as you aren't doing adapter ROM shadowing in BIOS because that's the memory ranges its including in C800-EFFF. In fact the M3 switch loads the 64K EMS page frame at C800.

Of course, the more adapter cards you have installed the more likely you are going to run into issues with the above- but for your average ISA/VLB games box I'd say it would be fine.

From what I can tell the B800-C7FF range includes video BIOS shadowing range, which is why its excluded, and the B000-B7FF range is the monochrome adaptermemory range, which is a pretty standard range for EMM386 to use on VGA machines.

The HIGHSCAN parameter supposedly causes instability on certain machines, but I've built quite a few DOS 386/486 boxes in my time and I've never seen it cause an issue.
I doubt the other parameters would cause much issue with most machines either. The MSDOS HELP explains those better than I can but they seem pretty innocuous.

But yes if people experiment and it causes problems they can alsways hit F5 while its booting and remove the offending parameters.

I don't think DEVICEHIGH does anything for emm386 but it doesn't hurt anything either. That's probably from when I was trying to optimise everything myself, I just changed all DEVICE into DEVICEHIGH after himem.sys.