From: "Marp" <marp AT 0 DOT 0 DOT 0 DOT 0> Newsgroups: comp.os.msdos.djgpp Subject: Re: VBE2.0 w/LFB + GCC Date: Thu, 12 Oct 2000 14:10:14 -0400 Organization: MindSpring Enterprises Lines: 50 Message-ID: <8s4uou$381$1@slb7.atl.mindspring.net> References: <6v%E5.29784$L12 DOT 598411 AT news2-win DOT server DOT ntlworld DOT com> <8s49vu$k4l$1 AT slb6 DOT atl DOT mindspring DOT net> <JAlF5.31810$uq5 DOT 615829 AT news6-win DOT server DOT ntlworld DOT com> NNTP-Posting-Host: 04.30.99.b5 X-Server-Date: 12 Oct 2000 18:09:34 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com "Graham Reeds" <grahamr AT dtn DOT ntl DOT com> wrote in message news:JAlF5.31810$uq5 DOT 615829 AT news6-win DOT server DOT ntlworld DOT com... <snip> > I thought that it was similar to the _farpokex() functions, in that it > disables memory protection for a small amount of time. I also thought I was > on the right track since it doesn't crash when ran (unlike the other options > I have tried.) It doesn't crash because it doesn't violate the access rights of _dos_ds. That doesn't mean you did it correctly. The dosmem*() functions are for accessing the real mode address space only. That's fine for VGA, but if you're using a VESA LFB it's no good. The _farpeek/poke functions are more like movedata (in fact I think movedata() may even use those functions). None of these functions disable memory protection in any way. You seem to have some confusion about this, so I highly advise you to read chapter 18 of the djgpp faq, especially 18.7. <snip> > _movedatal(_my_ds(), primarysurface->dsimage, videoselector, videomemory, > remainder); This looks wrong to me. The fourth parameter is suposed to be the offset within videoselector, and instead you're passing the linear address that you got from __dpmi_allocate_dos_memory(). This is definately wrong. You probably meant to pass 0, since you probably want to copy data starting at the beginning of the LFB, right? It's not suprising that you get a GPF from this mistake, since you violate the access rights of videoselector (by exceeding its limit boundary). > Casting (-I think that is the right term) the primarysurface->dsimage with > just an asterix removes the warning but it still gpf's out when ran: It's called dereferencing the pointer, and that's not what you want to do. You want to pass the pointer itself, since it's the offset within the ds selector (which is what movedata needs). If you want to get rid of the warning, typecast it to unsigned int. The typecast won't actually change the value passed, but it will tell the compiler that is what you wanted to do and get rid of the warning. The crashing was caused by the mistake you made with the fourth parameter. Hope this helps. Marp