Hi, Comment from Jack R. Ellis:
===== To set the record straight about Eric's comments of 1-Jul-2005 on FD-Devel: First, the UltraDMA drivers have RULES for whether or not they LOAD. They must find a valid controller chip, one or more UltraDMA disk drives, and if the "read tests" are in-use each disk must pass those tests. But AFTER an UltraDMA driver is loaded, IT WILL NEVER "decide to disable itself", EVER!! Second, it makes NO difference on my V6.22 MS-DOS, and it SHOULD NOT make a difference on other DOS versions, if the UltraDMA drivers are loaded BEFORE or AFTER EMM386/UMBPCI. If UDMA2 loads first, EMM386/UMBPCI are expected NOT to "re-map" or otherwise change its address! The Microsoft "VDS Spec" ABSOLUTELY states that all things ALREADY IN MEMORY when VDS becomes active (i.e. when EMM386/UMBPCI load) ARE NOT to be "re-mapped"! If UDMA2 loads AFTER EMM386/UMBPCI, it "locks" ITSELF into memory so it is NOT "re-mapped" during DMA transfers! That "lock" ALSO demands that EMM386/UMBPCI may NOT disable their VDS logic, EVER, as this will upset the 32-bit addresses that UDMA2 "calculates" for itself during initialization. NOT disabling VDS if any drivers/memory still remain under VDS "lock" IS ALSO a Microsoft RULE!! Third, there is NO restriction in the UltraDMA drivers AGAINST doing I-O to or from the HMA, UNLESS the driver is loaded with its /L switch! /L stops UltraDMA to/from any physical address above 0009FFFFh (except those for the "local buffer" in XMS memory), which is required to use UMBPCI. If /L was NOT used, the drivers allow UltraDMA to ANY physical address from 00000000h to FFFFFFFFh! If I-O to or from the HMA in fact does NOT work, you should EXAMINE what physical address the VDS "lock" logic (EMM386/UMBPCI) gives to the UltraDMA driver for an HMA I-O request! Finally, "A20" address-line switching for HMA access IS NOT REQUIRED, if an UltraDMA driver is loaded! ALL my UltraDMA drivers PERMANENTLY ENABLE the "A20" line during driver-init, to STOP any "fools" from DISABLING that line during a DMA transfer! Microsoft HIMEM implements "A20" enable/disable as a COUNTER; once it is enabled and the count goes to 1, further enables will be IGNORED. And once the UltraDMA drivers enable "A20", any other drivers CANNOT DISABLE "A20" (except by ERROR!), as this would mean the "A20" count went back to ZERO, and some badly-written driver did one disable TOO MANY!! If FD-XMS and/or FD-HIMEM are NOT handling "A20" enable/disable as a count, they NEED to be CORRECTED!! Jack R. Ellis ===== ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
