Mail Archives: djgpp/1997/07/08/05:17:55
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
***************************************
- Raw text -