From: Henrik Baarnhielm Newsgroups: comp.os.msdos.djgpp Subject: Re: VESA 1.2 Date: Tue, 08 Jul 1997 01:17:25 +0200 Organization: ABC-Klubben Lines: 77 Message-ID: <33C17905.41204F1A@abc.se> References: <33BB72C2 DOT B1ADF07B AT abc DOT se> NNTP-Posting-Host: pm2-04.abc.se Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk Shawn Hargreaves wrote: > I'm confused. If you only have a VBE 1.2 driver, 0x4F0A won't work, > because it's a VBE 2.0 extension. I think you are misunderstanding the > distinction between a linear framebuffer and VBE 2.0: one is a > hardware > thing while the other is a software API, so it's quite possible to > have > a VBE 2.0 driver that doesn't support linear framebuffers, if your > hardware doesn't provide such a thing. Maybe I wrote a bit strange. What I meant was that when I call the VBE interrupts, my vbeinfo-structure is filled with 0x0102 in the vbeversion-field. My card must then be VBE 1.2, am I wrong? But I use UniVBE 5.3a which emulate VBE 2.0 on some points, at least it says so. It emulates the 32-bit interface and some things more, but as you say it can't emulate a LFB, so I don't have that. At least I don't have a mode wich modeattributes in the modeinfoblock has bit 7 set. I have a Cirrus card, and 16 MB RAM and I don't know if it's one of those models that has LFB if there's 14 or less MB RAM installed. > >I also get a memoryaddress that I have to map. > ... > >I allocated a ldt with the libc-function > __dpmi_allocate_ldt_descriptors > >and set it's address and size with __dpmi_set_segment_base_address > and > >__dpmi_set_segment_limit and I locked the memory with > >__dpmi_lock_linear_region. > > That's correct, but I _think_ you might also have to use the > __dpmi_physical_address_mapping() to convert the physical addess you > get > from the VESA driver into a linear address that you can use as a > selector base address. You will only need to do that if the address is > above the first megabyte of memory, which is very unlikely, but unless > I'm very much mistaken (quite possible, as I've never seen a card that > does this :-) it would be a good idea to make this mapping... You mean that I should first map the memory address that I get from function 0ah and then use the memory-address I get from the map as the baseaddress for the allocated ldt? And you mean that everything else is correct?! Is it the way to go to load ES with the ldt before I make the switchbank call? > You'll need to make the entire call from asm, not just the bit that > loads the registers! Otherwise gcc is liable to replace the values you > so carefully loaded with something else as soon as your asm statement > closes. More importantly, there are several coding mistakes here. Your > move statements have the operands the wrong way round: in AT&T syntax > the source comes before the destination! You can't put %es in the > clobber list: you have to save and restore it yourself. And since you > told gcc to put "temp" in %ebx and "bank" in %edx, there's no need to > then copy the parameters in your asm code, because they are already > there! asm volatile("movw %%ax,%%es call %3 : :"b" (window),"d" (bank),"a" (ldt),"m" (switchbank)); You mean that this is enough? It doesn't get any compiler errors.... But is the values moved to bx,dx and ax before the statement mov es,ax is executed? I hate the AT&T syntax... portability may be good... but this is weird. > Look in bank.s. Also the vesa_scroll() and vesa_set_palette_range() > call > pmode VESA functions in a similar way to the bank switch, but using > inline asm. Thank you! -- *************************************** Internet : Henrik DOT Baarnhielm AT abc DOT se Fidonet : Henrik Baarnhielm, 2:201/235 ***************************************