Xref: news-dnh.mv.net comp.os.msdos.djgpp:1281 Path: news-dnh.mv.net!mv!news.sprintlink.net!howland.reston.ans.net!swrinde!elroy.jpl.nasa.gov!decwrl!waikato!comp.vuw.ac.nz!mu.sans.vuw.ac.nz!empty From: empty AT sans DOT vuw DOT ac DOT nz (Malcolm Taylor) Newsgroups: comp.os.msdos.djgpp Subject: Re: Video question Date: 31 Jul 1995 23:30:31 GMT Organization: SANS, Student Access Network System Lines: 30 References: Nntp-Posting-Host: mu.sans.vuw.ac.nz To: djgpp AT sun DOT soe DOT clarkson DOT edu Dj-Gateway: from newsgroup comp.os.msdos.djgpp Steve Havelka (shavelk AT agora DOT rdrop DOT com) wrote: : Hi. I have written a few graphics programs (mode 13h) for DJGPP, : and they access video memory at 0xd0000000. If I try to run : them under a DPMI server, though, they GPF when they try to : access the video memory. Is there another way to access video : memory so the programs don't crap out under DPMI? Several ways. The above way is only possible on the 1.12m4 and earlier version of djgpp in the nodpmi mode. The VRAM page fault handler is specific to go32, so if you use dpmi you don't get these buffers. Djgpp v2.0 is DPMI only, so you'll run into this problem if (when) you upgrade. The video memory is actually at 0xa0000 in physical memory. You can access this 64k segment using the sys/farptr.h routines or by using assembly code directly. The sad point here is that you have to handle the page changing yourself, making graphics routines harder. The way I got around this problem was to write a BitBlt routine that Blted an area of memory to screen, and then work entirely (almost, I have written a few specific routines to write to the screen) in memory buffers which can then be Blted to the screen. This is actually quite fast in some situations (esp. when working with a slow video card). There is a hack available (I think) to do the page fault handling under DPMI, but it isn't guaranteed to work. Hope this helps. Malcolm : -- : Steve : Life is pain. -- Siddhartha