Message-ID: <8D53104ECD0CD211AF4000A0C9D60AE336F614@probe-2.Acclaim-Euro.net> From: Shawn Hargreaves To: djgpp AT delorie DOT com Subject: Re: problems with linear frame buffer Date: Mon, 21 Dec 1998 15:16:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Reply-To: djgpp AT delorie DOT com Tobias Nygren writes: > I am writing a program that uses VESA mode 10F, 320x200x16.8M. Are you aware that 0x10F is not a standard VESA mode number? If you just hardcode this value, your program may not work on other machines that use different drivers. For a reliable mode set, you need to scan through the list of available modes as reported by the VESA driver, until you find one that matches your requirements. Also the 320x200x24 modes are not supported by many drivers, so if you use this resolution, many people won't be able to run your code at all! It is a lot more reliable to use only 8 bit lowres modes, and go to 640x480 if you want truecolor graphics. > I want the modeinfo.physbaseptr into an > unsigned char *bigbuffer; You can do that using the routines from , which are described in the info docs ("info libc alpha __djgpp_nearptr_enable"). I can't say that I recommend this method, though: many people seem to like it because it is very easy to program, but IMHO it is much better to use farptr routines: they are just as fast when used properly, maintain proper memory protection, and are far more reliable when used on different platforms like Windows NT or Linux DOSEMU, where the nearptr hack won't work at all. > I know it has got something to do with > __dpmi_physical_address_mapping()... Yes indeed. This subject is too big to cover by email, but look in the djgpp FAQ and the User's Guide on www.delorie.com, where you can find both lengthy explanations and example code. Shawn Hargreaves.