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 Freedosemail@example.com https://lists.sourceforge.net/lists/listinfo/freedos-user