Mail Archives: djgpp-workers/2001/01/22/00:21:21
I'm not on developers - so please CC me on replies.
At the request of Alexei Frounze, I looked at virtualized LFB support in
CWSDPMI. It turns out this type of feature was available in DJGPP v1.x
and we never bothered porting it (since it couldn't be provided under
other DPMI providers).
The example at ftp://clio.rice.edu/djgpp/lfb.zip includes a SIGSEGV handler
which looks for page faults and uses a "hacked" CWSDPMI to get the CR2
information. It also finds the location of the page tables and abuses them
to provide linear frame buffer support through emulation and bank swapping
to the 0xa000 real mode area. This is REALLY ugly code since it was a proof
of concept.
So, why am I bugging you guys about this? Two reasons. One, I modified
the "error code" on exception 14 (page faults) in the hacked CWSDPMI to
include the upper 29 bits of CR2 in the error code. I left the lower 3
as defined. I don't think anyone uses the regular bits, so it might be
useful (but a small DPMI violation) to just dump CR2 in the error code
instead of the error code bits. The way I did it gets you the fault
error within 8 bytes which was good enough for LFB emulation. Should this
feature go into a CWSDPMI release? If so, within 8 bytes or the full
address?
Second, with this type of example you get the ability to do other things
in your address space - which might include things like memory mapped
files or other things I haven't considered. You could probably even
add back support for early GRX code and V1.x programs which were never
ported due to heavy reliance on the LFB at 0xd0000000.
Beware, the example code can't handle having the page tables in UMBs.
Theoretically you could add similar support for other DPMI providers
(potentially including Windows with an enhancing VxD or something).
I don't have a lot of time to develop it, so I thought I would see if anyone
needs it for some feature they can't live without. Good luck.
- Raw text -