Hi,
Jack R. Ellis have message:
-----------------------------------------------------------------
I have read all the comments on FD-User re: Mark Bailey's problem
using the FD-EMM386 "VDS" parameter. I also noted Mike DeVore's
reply, that using "VDS" only enables 32-bit physical addresses to
be reported for upper-memory addresses, that he thought of making
"VDS" a default, and he now wonders if this should NOT be so.
First, any DMA device whose hardware uses physical 32-bit address
values REQUIRES that its DOS driver is able to INITIALIZE its own
internal addresses. The 32-bit address is found by a "VDS lock"
on a given memory space. Thus, if ANY upper memory is active, a
"VDS lock" and "VDS unlock" (in case drivers decide NOT to load!)
MUST ALSO BE ACTIVE, or any driver/TSR loaded in upper memory may
initialize itself IMPROPERLY and may CRASH!!!
Second, EMM386/QEMM/386MAX/etc. WERE NOT cooked-up only to create
upper memory! Windows 3.1 and other multi-task DOS environments
"switch" from one task to another using an 80386 memory "re-map",
NOT a (slow) disk "swap" as some MISTAKENLY believe! Any active
device drivers ought not be part of "re-mapping", or system speed
will suffer. Any active DMA buffers MUST NOT be "re-mapped", or
the system can CRASH! To avoid buffer "re-mapping", DMA drivers
use a "VDS lock" on user buffers before DMA begins and use a "VDS
unlock" on user buffers after DMA ends. This ALSO requires that
"VDS lock" and "VDS unlock" calls MUST BE IMPLEMENTED when needed
i.e. whenever ANY upper memory is used!
I AM NOT saying this only on behalf of UDMA2! Other DMA drivers
ARE ALSO written to follow Microsoft's unwritten RULES, in MS-DOS
V4.49 EMM386 (on my MS-DOS V6.22) and likely in ALL MS-DOS EMM386
drivers DESPITE their documentation! These unwritten RULES are:
A) If ANY upper-memory will be used when MS-DOS EMM386 loads,
VDS calls are always ACTIVE! Thereafter, upper-memory
and VDS calls can NEVER be DISABLED!
B) If upper-memory WILL NOT be used when MS-DOS EMM386 loads,
VDS calls are left INACTIVE! Thereafter, upper-memory
and VDS calls can NEVER be ENABLED!
As may be seen in the preceding two paragraphs, THERE ARE REASONS
why MS-DOS EMM386 drivers run on such unwritten and STRICT rules!
Ordinary users MUST NOT have "control" on the presence or absence
of VDS "lock"/"unlock" calls, or CRASHES which those users CANNOT
debug WILL HAPPEN! Say what-you-will of Microsoft; but they DID
learn NOT to let ordinary users TRIP over their own "appendages"!
As I noted to Jim Hall and Bernd Blaauw in an E-Mail during 2004,
FD-EMM386 must implement the same rules as MS-DOS EMM386, QEMM or
other available DOS "Expanded Memory Managers"! If not, FreeDOS
can expect UDMA2 and all other DMA drivers written to Microsoft's
[POORLY understood] standards sooner-or-later WILL CRASH!!!
-------------------------------------------------------
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-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
