Carrera wrote on 2021-03-17, 10:27:

I remember that tip as well!
Also, if you were lucky to have 2 hard drives setting those parameters to the other drive could sped things up a bit...

Woah, what's the logic in that? Something related to seek times?

Basically.. Yeah
In general if you could afford it you put the operating system on one hard drive and all other stuff on another as you tend to read from one and write to the other thus saving (admittedly milliseconds) time.
It was probably not very useful....

There was also a trick of doing this with the other functions. I am nut sure it was SmartDrive or the swap file maybe...?

Actually, splitting temporary file areas, swap and other things across multiple drives, as well as seperating the OS out from applications is still very common - think about a modern multi-tasking operating system; it's nearly always doing more than one thing at a time. In the days when hard drive transfer rates were measured in single digits to dozens of megabytes it was incredibly easy for one badly performing process to lock up your system by starving all IO.

Move the IO for that application to another drive/channel, and your other applications (and the OS itself) can continue with other IO requests while that application (slowly) performs its reads and writes.

^^ I think the same.

I guess ROM-based operating systems like Atari TOS did have an advantage here.

They had instant access to their libraries of code, without needing fixed disk drives.

In fact, they still have that advantage.
They never had to fight over disk i/o with the applications.

Operating systems like Windows will always be behind in this specific point, I think,
unless they are being run on a RAM drive.

Speaking of RAM drives/disks, Linux has the ability to run in such an environment (TO RAM argument).

However, if we're a little bit sarcastic, we could say that it requires that option somewhat badly also.
It handles everything through the file system, after all (everything's a file). 😉

Well, today's operating systems keep a lot in the ram and therefore kinda run from a "ram drive". It's not a new idea...

By loading everything high in config files on my 486 I am able to use just 3 megabyte’s of conventional memory of my 16 megabyte’s of ram.
Has anyone been able to use less on a 486 running DOS 6.22 ?

Intel486dx33 wrote on 2021-06-03, 05:13:

By loading everything high in config files on my 486 I am able to use just 3 megabyte’s of conventional memory of my 16 megabyte’s of ram.
Has anyone been able to use less on a 486 running DOS 6.22 ?

What? Conventional memory is the first 640KB of RAM.

Did you mean to say that you are able to only use 3KB of conventional memory, giving you ~637KB of free conventional memory?

cyclone3d wrote on 2021-06-03, 05:25:

Intel486dx33 wrote on 2021-06-03, 05:13:

By loading everything high in config files on my 486 I am able to use just 3 megabyte’s of conventional memory of my 16 megabyte’s of ram.
Has anyone been able to use less on a 486 running DOS 6.22 ?

What? Conventional memory is the first 640KB of RAM.

Did you mean to say that you are able to only use 3KB of conventional memory, giving you ~637KB of free conventional memory?

I'd like to see his config.sys and autoexec.bat files........

As well as the C:\>mem output.

Caluser2000 wrote on 2021-06-03, 06:50:

As well as the C:\>mem output.

"mem /c/a > output.txt" would be the best. 😀

BloodyCactus wrote on 2019-03-05, 20:01:

its in this zip

https://kråketær.com/stuff.zip

mcbexp for mcb expander. I dont know if its latest version, I'll check when I get home tonight.

this link doesn't seem to work anymore. 🙁
can you please reupload that zip file? thanks in advance!

honx wrote on 2021-08-26, 19:32:

BloodyCactus wrote on 2019-03-05, 20:01:

its in this zip

https://kråketær.com/stuff.zip

mcbexp for mcb expander. I dont know if its latest version, I'll check when I get home tonight.

this link doesn't seem to work anymore. 🙁
can you please reupload that zip file? thanks in advance!

its in here
Releasing some of my old DOS stuff

I'm wasting back some time trying to further improve the free conventional memory.
I'm wondering in your opinion which of those 2 setup is better:

Older configuration:

1 Tipo di memoria      Totale         Usata     Disponibile
2  ----------------  -----------   -----------   -----------
3  Convenzionale         655.360        14.704       640.656
4  Superiore             223.664        57.824       165.840
5  Riservata             393.216       393.216             0
6  Estesa (XMS)      132.945.488    10.929.744   122.015.744
7  ----------------  -----------   -----------   -----------
8  Memoria totale    134.217.728    11.395.488   122.822.240
9
10  Tot. inf. a 1 MB      879.024        72.528       806.496
11
12  Dim. massima di un programma eseguibile                   640.640   (626K)
13  Dim. massima di un blocco libero di memoria superiore     155.248   (152K)

New configuration:

1  Tipo di memoria      Totale         Usata     Disponibile
2  ----------------  -----------   -----------   -----------
3  Convenzionale         655.360         9.968       645.392
4  Superiore             196.144        57.824       138.320
5  Riservata             393.216       393.216             0
6  Estesa (XMS)      132.973.008    10.854.864   122.118.144
7  ----------------  -----------   -----------   -----------
8  Memoria totale    134.217.728    11.315.872   122.901.856
9
10  Tot. inf. a 1 MB      851.504        67.792       783.712
11
12  Dim. massima di un programma eseguibile                   645.376   (630K)
13  Dim. massima di un blocco libero di memoria superiore     122.496   (120K)

The new configuration gives 4kb of free conventional memory but the upper memory block is quite smaller (that's a general configuration it still needs audio driver to be loaded and probably something else), also 626kb of free conventional memory should be enough for any program, is that right?

GigAHerZ wrote on 2021-06-03, 08:21:

Caluser2000 wrote on 2021-06-03, 06:50:

As well as the C:\>mem output.

"mem /c/a > output.txt" would be the best. 😀

Have we seen this yet?

Nemo1985 wrote on 2021-09-01, 03:21:

I'm wasting back some time trying to further improve the free conventional memory. I'm wondering in your opinion which of those […]
Show full quote

I'm wasting back some time trying to further improve the free conventional memory.
I'm wondering in your opinion which of those 2 setup is better:

Older configuration:

Copy code to clipboard

1 Tipo di memoria      Totale         Usata     Disponibile
2  ----------------  -----------   -----------   -----------
3  Convenzionale         655.360        14.704       640.656
4  Superiore             223.664        57.824       165.840
5  Riservata             393.216       393.216             0
6  Estesa (XMS)      132.945.488    10.929.744   122.015.744
7  ----------------  -----------   -----------   -----------
8  Memoria totale    134.217.728    11.395.488   122.822.240
9
10  Tot. inf. a 1 MB      879.024        72.528       806.496
11
12  Dim. massima di un programma eseguibile                   640.640   (626K)
13  Dim. massima di un blocco libero di memoria superiore     155.248   (152K)

New configuration:

Copy code to clipboard

1  Tipo di memoria      Totale         Usata     Disponibile
2  ----------------  -----------   -----------   -----------
3  Convenzionale         655.360         9.968       645.392
4  Superiore             196.144        57.824       138.320
5  Riservata             393.216       393.216             0
6  Estesa (XMS)      132.973.008    10.854.864   122.118.144
7  ----------------  -----------   -----------   -----------
8  Memoria totale    134.217.728    11.315.872   122.901.856
9
10  Tot. inf. a 1 MB      851.504        67.792       783.712
11
12  Dim. massima di un programma eseguibile                   645.376   (630K)
13  Dim. massima di un blocco libero di memoria superiore     122.496   (120K)

The new configuration gives 4kb of free conventional memory but the upper memory block is quite smaller (that's a general configuration it still needs audio driver to be loaded and probably something else), also 626kb of free conventional memory should be enough for any program, is that right?

In the big scheme of things it isn't going to make much difference at all.

Caluser2000 wrote on 2021-09-01, 04:10:

In the big scheme of things it isn't going to make much difference at all.

Well the first configuration use xmgr.sys and emm386, while the second use jemmex (I wasn't able to use xmgr and jemmex).

That being said, can you please elaborate? Which one would you use?

Edit: I just noticed that with jemmex windows 3.11 doesn't run because it complains the lack of himem.sys

Carrera wrote on 2021-03-17, 11:05:

Basically.. Yeah In general if you could afford it you put the operating system on one hard drive and all other stuff on another […]
Show full quote

Basically.. Yeah
In general if you could afford it you put the operating system on one hard drive and all other stuff on another as you tend to read from one and write to the other thus saving (admittedly milliseconds) time.
It was probably not very useful....

There was also a trick of doing this with the other functions. I am nut sure it was SmartDrive or the swap file maybe...?

Wouldn't make any difference in DOS though.

DOS is strictly single tasking. It will sit there waiting for each I/O to complete no matter which drive you send it to.

Maybe with SMARTDRV or other smart caching software, you could eek out a small measure of improved performance with multiple drives vs 1, but it wouldn't be much.

To get benefit from multiple drives, you need software that is able to do multiple things at once.

In terms of how much I try to optimise memory, I don't run a lot of drivers on most of my systems so it isn't really that hard.

Default HIMEM.SYS then EMM386.EXE. Load DOS and all the drivers high. Do mild optimisation to get conventional memory free, and whatever high memory is left is fine, as non-TSR software generally doesn't care about high memory.

Some interesting tips here. On my system, this line as posted by @DonutKing seems to be freeing up around 20 KB of conventional memory by itself:

1DEVICE=C:\DOS\EMM386.EXE AUTO RAM M3 A=64 H=128 D=256 HIGHSCAN X=B800-C7FF I=C800-EFFF I=B000-B7FF NOTR

I have a couple of questions about that.

1. What are the memory ranges listed here normally used for? Monochrome graphics adapters?
2. What does the NOTR parameter do?
3. Is HIGHSCAN necessary for this line to work?
4. Are there any documented issues with games that arise from using this approach? I mean specific examples, not a general "some games might crash" warning

1. DOS Memory Ranges. Specifically B000-B7FF is monochrome text - almost never used by games, so frequently recommended.
2. EMM386 NOTR - can work around some hangs, does not increase available blocks as I understand it.
3. HIGHSCAN tells EMM386 to try to search heuristically for free blocks. You don't need it if you specify I= and X= ranges manually. HIGHSCAN can also cause some PCs to hang.
4. I know of at least one game that crashes with B000-B7FF (CDMan2), and there may be a couple of others. I found I=B400-B7FF (or even B100-B7FF) to be more compatible, at the cost of lower free UMBs.
5. The other ranges (C000 and higher) are for BIOS expansion ROMs. They do not specifically conflict with games, but may conflict with expansion cards you have installed and cause lockups.

Full documentation of EMM386 options. In particular, I have no idea why one should use A=64; seems like it only increases EMM386's footprint with no gain (how frequently does one multi-task in DOS?)

dr_st wrote on 2021-09-27, 07:07:

Full documentation of EMM386 options.

Cheers! That explains some things more clearly.

BTW, for testing purposes, I just reverted all of the tweaks that I added manually (including the EMM386 line listed previously) and let MEMMAKER.EXE work its magic on the unmodified AUTOEXEC.BAT and CONFIG.SYS. Surprisingly, it achieved an even better result, giving me 614 KB of free conventional memory. And this is without using any of those memory ranges and without HIGHSCAN.

I think I'm good with that and will likely keep this setup.