Long mode VBE

[Pype.Clicker]

well, i suppose one could hope the AMD64 system is equipped with a video card that supports protected mode interface and use 32bit-compatibility-in-long-mode to access it, right ?

or is the segmentation support so diminished in that sub-mode that supporting the protected mode interface to VBE cannot be done ?
(iirc, you have to setup a segment covering 0xc000...0xcffff and one covering VRAM).

[Candy]

in compatibility mode all segmentation stuff works, iirc. You can even declare 16-bit segments and use 16-bit protected mode code. You just cannot use 16-bit V86 code, which sort of precludes vesa / VBE 1.2.

[bubach]

Hmm.. But SANiK had some code to "translate/whatever" BIOS/16-bit code, right?

[Pype.Clicker]

true. that was here

[Crazed123]

Most of the time you only need to make vbe real mode calls to switch the mode. To render graphics you can:

1) Use a linear frame buffer. Easy to use, just a block of memory.

2) if your unlucky enough that 1) isn't support some cards have a protected mode stub you can copy from the bios to a code segment in order to perform bank switching in protected mode.

3) worst case, you drop into real mode to perform bank switching. however, you don't have to do this for every pixel drawn, only when you need to draw outside the current visible window of video memory.

Eddie

And how might we obtain said linear frame buffer from protected mode?

[beowulf573]

For now I've been using a patched grub to setup the mode and using the physical address returned in the multiboot information.

See the thread on setting a video mode from grub going on now.

This is not a good long term solution, you'd want to be able to drop in and out of text mode and change resolutions on the fly, and this won't allow that. However, it is good for testing code.

Eddie

[Candy]

Just a concept between what Sanik's doing and what vm86 normally does:

Would it be possible to go to the vm86 code in 16-bit pmode with an invalid gdt and an invalid ldt, then to be able to catch each and every segment load so you can reload it with a different and more valid segment? Would that be reliable enough for normal use?

You could also just load a 38-byte GDT, which would only allow segment selectors between 0x8 and 0x30. That way, it'd catch nearly all of them, but not quite all... Don't think it's a problem though.

Other than that, 16-bit pmode would be exactly the same as 16-bit vm86 mode, iirc.

Any comments?

[Pype.Clicker]

well, you could certainly catch "mov ax,0xc000; mov ds,ax" or "jmp 0xc000:fffe" and adjust that to "mov ds,<0x38>" (with descriptor 38 adjusted to match 0xc0000 .. 0xcffff).

The trouble will be when the code will attempt to read the value of some segment and use that to perform computation. For instance if it receives something in ds:si (initially 0xc000:0x1234) and want to compute the physical address to perform some DMA operations it's likely to have something like

Code: Select all

mov ax,ds
mov dx,ax ;; compute offset = (seg*16+offset)%65536
shl ax,4    ;; and page = (seg*16+offset)/65536
shr dx,12
add ax,si
adc dx,0
out DMA_OFFSET_PORT,ax
mov al,dl
out DMA_PAGE_PORT,al

give that ds=0x38 where ds.base eq 0xc0000 and you're running toward GreatHavoc(tm)