Hi!
(Forwarded by Johnson Lam from Jack R. Ellis to me. I answer again in
group, because this is not private topic):
> trouble using a packet driver. If you know where to E-Mail Belousov
> can you please send him the following?? Thanks! Jack R. Ellis
May address mentioned on the www.freedos.org/contact page.
> with "loadhigh" packet-driver problems. UMBPCI may or may-NOT help,
Yes, of course - if chipset doesn't supported by UMBPCI, then it will
not load at all. But if it supported - which other troubles you see?
> as Uwe Sieber notes in his UMBPCI writeup that the "shadow memory" he
> sets as upper-memory WILL NOT do DMA on mainboards for AMD CPU chips!
Hm, interesting and strange. Anyway, author of question doesn't
specifies machine configuration, so he may try this itself.
> Also, drivers that work in memory below 640K but FAIL in upper-memory
> may not be just "incompatible"; more likely they may be in ERROR! A
I just make short, generic description, which may not cover some
specifics (which was not specified by author of question).
> lot of drivers still have NO LOGIC for finding and using their ACTUAL
> 32-bit addresses, which ABSOLUTELY demands "Virtual DMA" (VDS) calls!
[...]
> what is now UDMA2!] VDS calls are implemented by EMM386 or whatever
> equivalent driver is in use, as only that driver "knows" which ACTUAL
> addresses are "mapped" into upper-memory. Only three VDS calls need
> be used. First, an initialization VDS "lock" on the resident driver
> prevents it from being "mapped OUT" during Windows 3.1 task-switching
> AND provides a base 32-bit address for fixed driver command-chains or
> buffers. Afterward, if user I-O is to be done DIRECTLY to or from a
> user buffer (not through an "intermediate" driver buffer), the user's
> buffer must have a VDS "lock" BEFORE any DMA I-O, then a VDS "unlock"
> AFTER all DMA I-O ends. The "lock" also returns the 32-bit address
> of the user buffer, needed for DMA.
> If your friend is "source code"
> competent and has the source for his packet driver, tell him to CHECK
> for those 3 VDS calls. As an example of how-to-do-it he can inspect
> the V2.5 UDMA2S driver (a bit simpler than UDMA2). UDMA2S.ASM lines
> 461-476 are the init "lock", DVRCORE.ASM (the resident driver!) lines
> 216-231 "lock" user I-O buffers, and DVRCORE.ASM line 246 "unlocks" a
> buffer (if needed) after I-O using a subroutine.
> If your friend has
> NO source-code competence but HAS the packet-driver sources, you will
> need to check the files for him as I describe. WITHOUT the sources,
> I am afraid your friend is "stuck" loading his packet driver into low
> memory, like it or NOT!! Lack of VDS logic, even AFTER upper-memory
> came into general use about 1990, is still a common ERROR in many DMA
> drivers; VIA and many other companies "DON'T want to talk about it"!!
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
