Mail Archives: djgpp/2001/11/30/11:18:41
> Meanwhile I took a look at [ http://clio.rice.edu/djgpp/cwsdma2.zip ]
> and tried it out.
> It really is what currently serves the most configurations.
> (plain cwsdpmi, himem with or without quemm/emm386)
> Excellent work. No surprise, cws having some insight to cwsdpmi :-)
A few people writing commercial software based on DJGPP/CWSDPMI asked
for a specific example of how to create a big DMA buffer with
physical addresses - this is the example code.
> It pokes deeply into the inner works thouh. Might be dangerous
> to be left to 'users' to modify and compile themselves etc.
> Couldn't it become part of a (runtime) library or so, to be
> encapsulated and standardized?
This is my long term goal, but I'm severely time constrained.
In today's environments, it shouldn't be dangerous (it either
works or gives you a failure code). In the future however...
> From the sources I saw that there is a case 'CWSDPMI PD in UMB not
> supported'. Under what circumstances will that strike?
If the page directory and tables are in UMBs (this can happen
if DOS=UMB is enabled with an EMM provider) then the physical to
virtual mapping is not 1:1 for the tables themselves. It's a
circular problem of how to find them when they point to themselves.
I have other code which has identified the location by scanning
the UMBs - but haven't completed it all. Today the fix is to
ship the product with CWSDSTUB on the exe image, and to set the
CWSPARAM flag to disable UMB usage.
> And finally: Where do you see problems when you say 'prototype'?
Since its first "release" as a prototype, several people have
written heavily used and tested code based on it. (There is
an excellent commercial product which uses it.) While the
people who used the example may have found problems - I believe
they would have asked me. So I think the fundamental code is
sound.
It is really a toolkit however - it needs to be better structured,
more clean and modular. One issue is what the API should be -
something like "get dma buffer", and have it return a virtual
and physical map? Different users had different needs.
Still, this all should work OK - unless I finally get 4Mb page
support into some future version of CWSDPMI. When that happens
I'm not sure the 4Mb page support works in the current code
(It wasn't in early versions, and it's untested in the current
code).
There is also some VDS support code in CWSDPMI which is
currently turned off - since it was never fully tested.
This would probably be a better way of doing it long term, but
given how frequently I get CWSDPMI releases out don't hold
your breath. So far no one has been interested enough to
do a full VDS survey on all platforms to see what works
where to see if it is worth while messing with.
I hope that makes you feel a bit more comfortable.
- Raw text -