As far as i know, disk overlay software does not consume memory.

What "mem /c/p/a" shows? (you can also export it to a file for later investigation: mem /c/a > report.txt)

yes diskmanager steals some ram to work, no way around it
maybe use XT-IDE bios with some nic to load it, works better

Try different DDO software, not all of them reserve so much memory. IF I remember correctly, a version of EZ-Drive that I'm using reserves about half of Ontrack.

edit: according to this, EZ-Drive 9.x uses 5KB
http://site.iendraguignan.free.fr/telecharger … FAQ.htm#memory1

Well, seems i'm wrong...

How can i check how much DDO software uses memory? mem command doesn't seem to show anything...

(I've been happily using OnTrack 9.57 on my 386, but if i want to max out everything, i might want to replace the DDO software for more free memory...)

GigAHerZ wrote:

Well, seems i'm wrong...

How can i check how much DDO software uses memory? mem command doesn't seem to show anything...

(I've been happily using OnTrack 9.57 on my 386, but if i want to max out everything, i might want to replace the DDO software for more free memory...)

What's your mem/c/p reporting? You need to check the total conventional memory column. Mine with Ontrack is only 640000 bytes. Ontrack manual says with relocation it can move all but around 80 bytes to UMBs, but I was not able to do that.

You need to be sure ontrack is enabled, though. If it doesn't find any disk with DDO, it'll not using any memory.

keropi wrote:

yes diskmanager steals some ram to work, no way around it
maybe use XT-IDE bios with some nic to load it, works better

I didn't realize the SIIG EIDE card I have around actually supports disks up to 8.4G. I tried it yesterday and it works great except for some reason the BIOS on this card reserve 2k from DOS. So I end up with 638K for now.

mega486, you are right! Some conventional memory just doesn't exist for DOS.

My mem /c/a is clean from any drive overlays, but with ontrack i had ~15000 bytes lost from total conventional memory. With EzDrive, i have ~5000 bytes lost from total.

Thank you! I have moved over from OnTrack to EzDrive because of that.

Slight resurrection.

Just found out that EzDrive has a ezmem.sys, that you can load in the beginning of config.sys that frees up the ~5000 bytes the EzDrive overlay initially takes. (Probably moves it away to somewhere else)

So you can have DDO (the cake) and have the full 640kB of conventional memory. (and eat it too)

GigAHerZ wrote on 2019-05-10, 07:05:

Just found out that EzDrive has a ezmem.sys, that you can load in the beginning of config.sys that frees up the ~5000 bytes the EzDrive overlay initially takes. (Probably moves it away to somewhere else)

So you can have DDO (the cake) and have the full 640kB of conventional memory. (and eat it too)

Where did you get the EZMEM.SYS?
I couldn't find it on various EZ-Drive floppies (v9.03, 9.06, 9.09).
What EZ-Drive version do you use?

bttr wrote on 2020-05-05, 19:31:

Where did you get the EZMEM.SYS? I couldn't find it on various EZ-Drive floppies (v9.03, 9.06, 9.09). What EZ-Drive version do y […]
Show full quote

GigAHerZ wrote on 2019-05-10, 07:05:

Just found out that EzDrive has a ezmem.sys, that you can load in the beginning of config.sys that frees up the ~5000 bytes the EzDrive overlay initially takes. (Probably moves it away to somewhere else)

So you can have DDO (the cake) and have the full 640kB of conventional memory. (and eat it too)

Where did you get the EZMEM.SYS?
I couldn't find it on various EZ-Drive floppies (v9.03, 9.06, 9.09).
What EZ-Drive version do you use?

It was on my floppy image together with all the other files... Images are from the internet. I think i had both 9.03 and 9.09.

mega486 wrote on 2019-01-17, 23:04:

What's your mem/c/p reporting?

Completely pointless, as any DDO is loaded before the OS (obviously). It won't show up in DOS and is not a DOS application either. It's more of an option "ROM", which even "mem /c/p" will not list.

GigAHerZ wrote on 2020-05-06, 11:09:

It was on my floppy image together with all the other files... Images are from the internet. I think i had both 9.03 and 9.09.

I also got my images from the Internet: archive.org or philscomputerlab.com
The file is just not there. 🙁

For the interested, the EZMEM.SYS file is on the boot disk created by the EZDRIVE9.EXE program -- the one available as "9.03W" -- but not in the archive described as "9.06W".

There is no readme or instructions about its purpose, use or method of operation, but it does do something:

- Without EZMEM.SYS, the overlay consumes 5120 bytes from the top of conventional memory from 9EC0h. DOS addresses 650,240 bytes of conventional memory.
- The string "EZ-DRIVE" identifies this block of memory.

Loading EZMEM.SYS -- without any switches either before or after HIMEM.SYS but before EMM386:

- EZDRIVE does not vacate conventional memory, but its space is linked to DOS conventional memory.
- DOS addresses the full 655,360 bytes of conventional memory.
- EZMEM is not a TSR and does not appear in mem/c except its size is included in "MSDOS" blob and its segment is flagged as "System Area" in MSD.
- EZ-DRIVE is still resident at 9EC0h and consumes ~ 5k.
- You do get 16 bytes back as EZ-DRIVE uses 5104 bytes instead of 5120.
- If you load EMM and enable UMBs you get 32 bytes back as EZ-DRIVE uses 5088 bytes instead of 5120.

It does not appear possible to relocate EZDRIVE to UMB because it cannot load after any memory manager that would make those UMBs available.

TLDR: EZMEM.SYS doesn't do anything immediately useful.

JudgeMonroe wrote on 2020-08-13, 17:19:

For the interested, the EZMEM.SYS file is on the boot disk created by the EZDRIVE9.EXE program -- the one available as "9.03W" - […]
Show full quote

For the interested, the EZMEM.SYS file is on the boot disk created by the EZDRIVE9.EXE program -- the one available as "9.03W" -- but not in the archive described as "9.06W".

There is no readme or instructions about its purpose, use or method of operation, but it does do something:

- Without EZMEM.SYS, the overlay consumes 5120 bytes from the top of conventional memory from 9EC0h. DOS addresses 650,240 bytes of conventional memory.
- The string "EZ-DRIVE" identifies this block of memory.

Loading EZMEM.SYS -- without any switches either before or after HIMEM.SYS but before EMM386:

- EZDRIVE does not vacate conventional memory, but its space is linked to DOS conventional memory.
- DOS addresses the full 655,360 bytes of conventional memory.
- EZMEM is not a TSR and does not appear in mem/c except its size is included in "MSDOS" blob and its segment is flagged as "System Area" in MSD.
- EZ-DRIVE is still resident at 9EC0h and consumes ~ 5k.
- You do get 16 bytes back as EZ-DRIVE uses 5104 bytes instead of 5120.
- If you load EMM and enable UMBs you get 32 bytes back as EZ-DRIVE uses 5088 bytes instead of 5120.

It does not appear possible to relocate EZDRIVE to UMB because it cannot load after any memory manager that would make those UMBs available.

TLDR: EZMEM.SYS doesn't do anything immediately useful.

Thanks for that analysis! 😮

Xtide bios also consumes Memory 😅

matze79 wrote on 2020-08-25, 06:56:

Xtide bios also consumes Memory 😅

That's true, but it's only 1kB, so looks like the best solution.

I've converted my 386 from EzDrive to XTIDE now and waiting for more rom chips so i could convert my 486 as well.