VBE SVGA using window positioning function

[BASICFreak]

Ok, there is so little information on this for PMode. (Or Google really hates me today)

According to the information I have been able to find the pointer at offset 0x0C of INT 10h 4F01h should function as int 10h 4F05h just ignoring ax due to calling directly.

Bochs returns 0xC00094f7 as the Window Positioning Function, only issue is when calling this directly bochs dies at the following:

>>PANIC<< prefetch: running in bogus memory, pAddr=0x00000000c00094f7

So, hopefully someone here has some information on this.

I am attempting to implement Page Flipping into my SVGA Driver, due to only being able to copy 1/3 of the buffer per refresh at 640X480X8 with rep movsd. (I know most the time I do not write the whole screen, but when I do I hate the breaking in the display)

Part of Bochs Config:

Code: Select all

romimage: file="/usr/share/bochs/BIOS-bochs-latest"
vgaromimage: file="/usr/share/bochs/VGABIOS-stdvga"
pci: enabled=1, chipset=i440fx, slot1=pcivga
vga: extension=vbe, update_freq=60

[alexfru]

0xC00094f7 must be treated as segment 0xC000, offset 0x94f7 and the code at this address can't be executed in protected mode (unless it's actually virtual 8086 mode).

[Gigasoft]

That is not the entry point you want. For VBE 2.0, the protected mode interface is retrieved by invoking int10 function 4f0ah with BL=0. This returns a pointer in ES:DI to an relocatable area of CX bytes in size. At the start of this area there are four 16-bit offsets, to the Set Window function, the Set Display Start function, the Set Primary Palette function and a table of port numbers that the code accesses, terminated by 0ffffh. After this table, there will either be another 0ffffh, or the address of a MMIO region followed by a 16-bit length minus one, then 0ffffh. If the MMIO region is specified, then a segment pointing to this region must be given as an additional parameter to the three entry points (in ES for Set Window and Set Display Start, and in DS for Set Primary Palette). The code is to be executed in 32 bit mode.

For VBE 3.0, another protected mode interface is defined which is described in the VBE 3.0 standard. If one doesn't exist, you can try the other.

[BASICFreak]

Thanks for the replies.

So I'm looking at INT 10h, Just curious before I start:

INT 10h 4F0Ah 0000h - returns PMode Interface

but will I have to run INT 10h 4F0Ah 0001-0003h to get the code or is this auto returned with the first?

Anyways, I just woke up so I'm off to make coffee - so I'll start playing soon.

[Kazinsal]

VBE 3.0 implements a different protected mode interface that you'll need to look up the details of in the standards document (just google "vbe3.pdf"). It's found differently than the 2.0 interface. The document gives information on how to set an environment up that can use it.

Keep in mind though that implementation of the VBE 3.0 protected mode interface is optional to video BIOS manufacturers and it thus likely doesn't exist in may video BIOSes.

[alexfru]

I have probably mentioned it before, if you detect VBE 2.x or 3.x, it doesn't yet guarantee LFB (one of my PCs from around ~2000 with intel video integrated into the memory controller claimed VBE 3.0 and yet provided no LFB). LFB support needs to be checked for explicitly and there probably should be non-LFB version to fall back to.

[BASICFreak]

Ok, I am attempting now to use the 10h 4F07h function (yes the one returned in the table) and it seems no matter how I set DX and/or CX I get the same result:

(Yes the colors are right, just not the position of anything, it should switch between full screen of one then the other color)

The function returns supported and no errors. I have set Pixel Based, Address Based, and complete randomness in CX and DX and I get the above (never any variance) or a Y out of range Panic from Bochs.

I have open (and read) the VBE 2.0 (p. 20) & 3.0 (p.50-51) Specs. And I cannot seem to find the 1.2 Specs, but all these functions as I can tell are 2.0+ anyways.

I even tried to conform to this code from Robert C. Pendleton (http://gameprogrammer.com/1-vbe.html):

Code: Select all

int
vbeSetDisplayStart(uint16 pixel, uint16 line)
{
    union REGS reg;

    reg.x.ax = 0x4f07;
    reg.h.bh = 0x00;
    reg.h.bl = 0x00;

    reg.x.cx = pixel;
    reg.x.dx = line;

    int86(0x10, &reg, &reg);

    return (reg.x.ax == 0x004f);
}

My video Memory is filled like so:
memset(FrameBuffer, 0x83, (Width*Height*(Depth >> 3)));
memset(SecondFrameBuffer, 0x28, (Width*Height*(Depth >> 3)));

FrameBuffer is offset 0, and SecondFrameBuffer is offset Width*Height*(Depth>>3) into video memory.
Current video settings 640x480x8bpp (and I know I have the memory as I can easily goto 1024X768X32bpp, which requires more than 10X the memory)

[freecrac]

Hello.
I am not sure if it is a problem, but the scanline is maybe longer as the horizontal resolution. And so we have to calculate the whole buffer and the position of a pixel with BytesPerScanLine(mode_Info+10h) or LinBytesPerScanLine(mode_Info+32h) for LFB.

Dirk

[BASICFreak]

No, That would not be the problem both variables are:
BytesPerLine = 0x280
LinBytesPerScanLine=0x280
Width = 640
Height = 480

Does anyone know where I can find example codes of Function 7?

I cannot get any different results, if I set all 0's its still the same result, if I set DX = 480 same, DX = (480/4) Y out of range panic.

I put a magic break point in front of the call so I can manually edit registers, I even tried clearing they High 16 bits of EAX, EBX, ECX, EDX and setting ESI and EDI to 0, Still the same.

And yes I am in LFB.

[freecrac]

Hello.
I have written a DOS example in assembler for VBE triple buffering with 1024x768x32@100hz refreshrate using the LFB with the 16 bit Big-Real mode for an analog CRT-Monitor with 96 khz capacity.
http://www.alice-dsl.net/freecracmaps/Tool/Neutrip.zip

Dirk

[alexfru]

I haven't really used Bochs (first and last time it was around 2000), so I don't know if its VESA implementation is correct or free of oddities. I know that the original Virtual PC had buggy VESA (I helped identifying and fixing some of those bugs when they migrated into Hyper-V) and I can see some odd behavior in Oracle VirtualBox when scrolling (which is, in effect, changing the start address). But surprisingly DOSBox is OK (probably because it was tested on many games that used VESA). For VESA testing I'm using an old "Graph unit demo program" from TMT Pascal. TMT's VESA support in the Graph unit appears to be taking care of most if not all edge cases. I used it many years ago on a number of different video cards with VBE 1.2, 2.0 and 3.0, LFB, windowed/banked, with 64KB windows/banks and with 16KB windows/banks. Unlike many other (S)VGA test tools it always showed correct picture for me. Could you try your program in DOSBox?

[BASICFreak]

@freecrac: Very nice and well commented code, will be studying it soon. Noticed it was VBE3.0 only - the subfunctions it uses are not in VBE2.0.

@alexfru: Yea, I'm starting to assume Bochs has broken VBE functionality. I "could" use dosbox to test but I haven't programmed for dos since QBASIC, and I don't want pure ASM.


Anyways I forfeited the idea of VBE Functions (for now) learned that processors since the PIII have a SSE and set-up the following:

Code: Select all

refreshScreen:
	pusha

	mov ecx, DWORD [VBE_FBSize]
	shr ecx, 7
	mov esi, [VBE_FB]
	mov edi, [VBE_LFB]
	;VSync cannot be trusted on all devices!
	;mov edx, 0x3DA
	;.WaitVSyncEnd:
	;	in al, dx
	;	cmp al, 8
	;	je .WaitVSyncEnd
	;.WaitVSyncStart:
	;	in al, dx
	;	cmp al, 8
	;	jne .WaitVSyncStart
	.copyloop:
		MOVAPS xmm0, [es:esi]
		MOVAPS xmm1, [es:esi + 0x10]
		MOVAPS xmm2, [es:esi + 0x20]
		MOVAPS xmm3, [es:esi + 0x30]
		MOVAPS xmm4, [es:esi + 0x40]
		MOVAPS xmm5, [es:esi + 0x50]
		MOVAPS xmm6, [es:esi + 0x60]
		MOVAPS xmm7, [es:esi + 0x70]
		
		MOVAPS [es:edi], xmm0
		MOVAPS [es:edi + 0x10], xmm1
		MOVAPS [es:edi + 0x20], xmm2
		MOVAPS [es:edi + 0x30], xmm3
		MOVAPS [es:edi + 0x40], xmm4
		MOVAPS [es:edi + 0x50], xmm5
		MOVAPS [es:edi + 0x60], xmm6
		MOVAPS [es:edi + 0x70], xmm7
		
		add esi, 0x80
		add edi, 0x80
		dec ecx
		jnz .copyloop

	popa
	ret

Which is so much faster than the rep movsd I was using. Only notice tearing when not in sync, I have to find a way to get VSync on real HW (non VGA compatible VBE mode)

But for now I am happy with the speed of the refresh, at 640X480X8bpp my refresh rate is way to high but at 1024X768X32 its about 30-40fps with full screen changes which to me is usable (a DVD is 27 iirc)