Mark,

> Yep, just tried Rdisk and it works as expected (when loaded from
> Autoexec.bat), I can assign a known drive letter and then not have
> to "faff around" trying to locate the ramdisk using findtdsk.exe.
>
> I don't think rdisk was around in 2003 when we set up our stuff
> originally, which I why we went tdsk route.

I am the author of RDISK, also UIDE and XMGR.   Glad you like RDISK,
which I wrote in 2009 in response to Johnson Lam (my "partner" in my
DOS activities), who noted HE "did not like" any of the available
RAM disk drivers, either.   So I did a "simpler" driver for him, and
that is how RDISK came to be!

> Interestingly thou, Rdisk suffered the same problem, that tdsk had,
> in that we stored the ramdrive disk letter in an environment variable
> %RAMDRIVE% and our watcom app used a GetVar to retrieve it ...

Not sure if this is a "driver" problem.   If you wish, send me an
E-Mail in private with more detail, and if RDISK can be improved,
I shall do so.

> One last question, all these memory managers and such, is there a
> recommended set for a modern PC?

I definitely recommend either JEMMEX (as you are using) or JEMM386
with a good XMS manager, either HIMEMX or my own XMGR.   The other
"EMM" drivers are all NOT under current maintenance, and many have
never-fixed bugs!!   Japheth works hard to keep his "JEMM" drivers
current and bug-free, so they are the ones to use.

JEMMEX alone should work fine for most people.   If you don't need
any protected-mode features nor any "extra" upper-memory (B000h to
B7FFh, i.e. the old "monochrome video" area) that must be "mapped"
by an EMM driver, you can first run UMBPCI, then load my own XMGR.
XMGR can "read" the UMBPCI memory blocks and load itself directly
into upper-memory.   XMGR also has "I-O Catcher" logic to "catch"
and execute diskette I-O (also hard disk I-O until UIDE loads) in
upper-memory, since UMBPCI's "Shadow RAM" upper memory will not do
any DMA!   "Serious" game fanatics prefer UMBPCI/XMGR, as they are
slightly faster from not using protected-mode, and many DOS games
are written for real-mode speed.   Except for JEMMEX by itself, or
UMBPCI + XMGR, other memory-manager drivers are usually unneeded.

> At the moment, my fdconfig.sys looks like:
>
> DEVICE=A:\JEMMEX.EXE
> SHELL=A:\COMMAND.COM A:\ /E:512 /P
> DOS=HIGH,UMB
> DOSDATA=UMB
> FILES=20
> BUFFERS=20
> LASTDRIVE=Z
> DEVICEHIGH=A:\UIDE.SYS /S40 /D:CDROM1
>
> and the start of my Autoexec.bat looks like:
>
> LH A:\RDISK.COM /S50 /:Y
> A:\FREEDOS\SHSUCDX /QQ /D:CDROM1,Z
>
> Any pointers or help optimizing it further would be appreciated.

Looks good to me!   My only comment is that if you always use the
FreeDOS system, you may want to delay loading UIDE until AUTOEXEC
runs, in which case you will have to load UIDE with --

   DEVLOAD /H A:\UIDE.SYS /S40 /D:CDROM1 /H

DEVLOAD, maintained by Eric Auer, can load .SYS drivers during the
AUTOEXEC.BAT file (normally, they load during CONFIG.SYS).   In my
example line, the first /H tells DEVLOAD to load UIDE "high", i.e.
in upper-memory, and the second /H tells UIDE to use free HMA space
for most of its driver logic.   That will save you about 4300 bytes
of upper-memory.   FreeDOS does not make HMA available for drivers
until AUTOEXEC runs, thus the reason for "delaying" UIDE's loading.

You may also want to give UIDE more than just 40-MB of XMS for its
cache.   The "rule" I recommend, where possible, is to allocate 3
times the size of your largest cached file, i.e. if your system may
have to handle up to 100-MB files, then a 300-MB cache works fine:
100-MB to cache the "input" file, 100-MB to cache its "output" copy
during file copies, and 100-MB for directories or other files to be
SAVED while a big file-copy is going on!   If 300-MB is too much or
if your largest file is used only "occasionally", make the cache 3
times the size of your largest "most used" file.   This scheme will
avoid UIDE having to discard directories, to make space for a large
"new" file in its cache, which slows it down a bit when those disk
directories ultimately need to be re-read!

Finally, unless your WATCOM application requires them, you may want
to use BUFFERS=4, or at most BUFFERS=10, in your CONFIG.SYS file.
WIth UIDE present, there is no further need for a large number of
DOS buffers.   UIDE does a much better caching job than the old DOS
buffers, and by reducing your buffer count, you may save enough HMA
space to put UIDE "up there" in the HMA, as well!

Best wishes,

Jack R. Ellis


------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Reply via email to