RDISK -- DOS Device Driver =========================================================== 1. Description ----------- RDISK is an Open Source DOS RAM-disk driver for a PC system with an 80386+ CPU and using FreeDOS. It creates a "fast" disk using up to 2-GB of XMS memory. Files can be uploaded using FDAUTO to the RAM-disk and accessed at memory speeds. RDISK is a simple RAM-disk driver with no resizing or other options. The small RDISKON.COM program will re-enable an RDISK drive if a format command is issued to it by mistake! Entering RDISKON L at a command prompt, where L is the drive letter (A to Z), re-enables the drive. 2. NO Warranties ------------- RDISK is offered at no cost, as-is, "Use at your own risk", and with NO warranties, not even an implied warranty of FITNESS for any purposes, nor an implied warranty of MERCHANTABILITY! 3. Revision Summary ---------------- 25-Apr-11 BAD "code mods" init error corrected 23-Jun-09 RDISK now a .COM file. RDISK /: switch, RDISKON program added. 15-May-09 Added RDISK. 4. Switch Options -------------- RDISK uses only /S size and /: drive-letter switches: /Sn Specifies a desired RAM-disk size in megabytes of XMS memory. Values are any number from 2 to 2047. When /S is omitted or invalid, a 25-MB RAM-disk is set by default. /:L Specifies the DOS drive letter desired to access RDISK files. L may be any available drive letter from A to Z, e.g. /:N assigns drive N: to all RDISK files. If the drive letter is too high or already in use, RDISK will abort, and users will need "LASTDRIVE=" in FDCONFIG.SYS to set more drives. If RDISK loads from FDCONFIG.SYS, or if /: is omitted, the next free drive letter will be used. -------------------- For all switches, a dash may replace the slash and lower case letters may be used if desired. 5. Example Configuration Files --------------------------- A) Small real-mode systems that need only XMS may use this FDCONFIG.SYS example file: .. .. DOS=HIGH DEVICE=C:\BIN\XMGR.SYS .. .. Etc. .. B) Real-mode systems with V3.70+ UMBPCI and XMGR do not need the LOWDMA driver, as XMGR sets an "I-O Catcher" for UMBPCI. This scheme uses NO low memory, if /W is given; XMGR and other drivers go directly to UMBPCI "Shadow RAM" upper memory! An example FDCONFIG.SYS file is: .. .. DOS=HIGH,UMB DOSDATA=UMB DEVICE=C:\BIN\UMBPCI.SYS DEVICE=C:\BIN\XMGR.SYS /W .. .. Etc. .. C) A protected-mode system with XMGR and JEMM386 can use XMGR's "boot", taking only 384 low memory bytes as its 32-entry "XMS Handles" table (used early by JEMM386). See Section 6 below for other notes about protected-mode! An example FDCONFIG.SYS file is: .. .. DOS=HIGH,UMB DOSDATA-UMB DEVICE=C:\BIN\XMGR.SYS /B /N32 ;32 Handle XMGR "boot" DEVICE=C:\BIN\JEMM386.EXE I=B000-B7FF ... DEVICEHIGH=C:\BIN\XMGR.SYS ;Loads the runtime XMGR .. .. Etc. .. When all above drivers are loaded, other needed FDCONFIG.SYS files such as SETVER, ANSI.SYS, etc. can then load in any desired order. For each of the above examples, FDAUTO.BAT can then load UHDD and UDVD2 (or just UIDE) using the DEVLOAD program. This permits the drivers to use "free HMA" and save low memory. UDVD2 must load after UHDD, so it will find UHDD in memory and "link" to it for CD/DVD data file caching. Example FDAUTO command lines are: .. .. Int 13h drivers cached thru UHDD/UIDE .. load now and can load in upper memory. .. DEVlOAD /H C:\BIN\UHDD.SYS /S500 /H /O ;Or UIDE alone DEVLOAD /H C:\BIN\UDVD2.SYS /D:BLURAY1 /H LH C:\BIN\RDISK.COM /S250 ;Optional .. .. Etc. .. 6. Technical Notes --------------- Protected-mode users must pretest "I=nnnn-nnnn" or "X=nnnn-nnnn" values for JEMM386, as its "I=TEST" or "X=TEST" options may fail on newer PCs. Protected-mode is unrecommended with old DOS games needing reserved XMS as JEMM386 takes some XMS memory first. Newer "cheap BIOS" mainboards now OMIT logic used only by DOS and need an UltraDMA disk driver loaded before JEMM386 sets V86 protected-mode! For such boards, FDCONFIG.SYS example C above requires drivers cached thru UHDD, then UHDD itself, to load only in LOW memory directly after XMGR sets up XMS for the system. UIDE is unrecommended in this case as it will take FAR more low memory! JEMM386 can then load and set V86 protected-mode, and UDVD2 (if wanted) can be loaded later from FDAUTO. 2015 or older PCs with a normal BIOS usually do not need this and can use example C as shown above. Use of JEMMEX or other "EMM" drivers but JEMM386 must now be avoided. Other "EMM" drivers got dropped long ago, some with leftover ERRORS! JEMMEX has caused crashes on newer PCs due to OBSOLETE XMS detection code, and it cannot work with UIDE/UHDD on a "cheap BIOS" board as neither driver can load O.K. if the other is absent! To run protected-mode on "cheap BIOS" boards, use FDCONFIG.SYS example C with UHDD/UDVD2 (not UIDE) and the changes noted herein, and be aware that JEMM386 will be REQUIRED! XMGR and UIDE/UHDD/UDVD2 will return normal XMS and CD/DVD error codes, as needed. They are listed in the "V3.0 XMS Specification" and in the Microsoft "MS-DOS CD-ROM Extensions 2.1" document. Both are available from Microsoft or from other Internet sources. UIDE and UHDD work as "BIOS drivers" and return whichever codes are set for diskettes and hard-disks handled by the BIOS. For their SATA and IDE hard-disks, UIDE/UHDD can post the following error codes: Code 0Fh - DMA error. CCh - Disk is FAULTED. 20h - Controller busy. E0h - Hard I-O error. AAh - Disk not ready. FFh - XMS memory error. Many DOS programs display only "Disk Error" messages with NO code, thus disk errors may require running a diagnostic to get better information! UIDE/UHDD handle only "Legacy" or "Native PCI" IDE controllers. RAID- only chipsets, port multiplier chips, or ADMA chipsets are unsupported. UIDE/UHDD must use "Legacy", "Compatibility", or "Native IDE" mode with AHCI controllers. For mainboards with no such controller settings, a Sabrent or similar SATA-to-IDE card can let UIDE/UHDD/UDVD2 handle SATA disks/CDs/DVDs from parallel-port IDE controllers (80-pin cable) at DMA speeds. "Add on" PCI-bus adapter cards that can be detected by normal PCI-bus routines may also be used for disks/CDs/DVDs. XMGR loads in UMBPCI upper memory that is not "provided" to the system. With UMBPCI, a "MEM" list may begin with a block having a 00A5h offset, or greater with 80 or 128 XMS "Handles". The upper memory skipped by this offset contains XMGR. The UMBPCI upper memory manager uses system "Shadow RAM" that cannot do DMA. A newer BIOS may use UltraDMA to load programs in upper memory. If this is "Shadow RAM", a HANG can occur! These two rules apply, if using UMBPCI with XMGR and UIDE/UHDD: A) V3.70+ UMBPCI must load before XMGR, so XMGR finds UMBPCI and sets its "I-O Catcher", to handle diskette "Shadow RAM" DMA forever and to do disk "Shadow RAM" UltraDMA until UIDE/UHDD can load. Older UMBPCI drivers, or other UMBPCI load schemes, are not recommended! B) When CHS I-O is done, each disk must have valid CHS parameters set in the BIOS. If not, the "I-O Catcher" or UIDE/UHDD let the BIOS handle CHS I-O. If BIOS UltraDMA is left enabled, a "Shadow RAM" HANG can occur! Old BIOS programs may not configure a mainboard controller when no user drives are on it! The drivers then display "BAD controller" and go on looking for others to use. If this message is given, users must check that all SATA/IDE drives are set "active" with the BIOS setup routines. If so, "BAD controller" means a chip is not using "Bus Master" and "I-O Space" modes, and a BIOS update is needed!