flat assembler
Message board for the users of flat assembler.

Index > OS Construction > VBE PM interface?

Author
Thread Post new topic Reply to topic
Artlav



Joined: 23 Dec 2004
Posts: 188
Location: Moscow, Russia
Artlav
Greetings.

I'm trying to use VBE 2.0's protected mode interface to speed up bank switching, yet no success is available so far.

What i do is - call 4F0Ah function, copy the received table into driver's local memory, then, when time comes, call the entry point at table+[table+2]. At that point, something hangs.

So, what is the proper way to use these functions? The description is somewhat cryptic, and examples are curiously lacking.

Also, is it even worth it, in performance/effort, compared to vm86 solution?
Post 12 Aug 2009, 16:17
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17716
Location: In your JS exploiting you and your system
revolution
If the pointers are for PM mode then I imagine they would be dword values? Your description of [table+2] would seem to imply word values?

Anyhow, that it just my guess, I have never dealt with the interface at all. Sorry if I gave a bad suggestion.

Maybe it is [table+2*4]?
Post 13 Aug 2009, 00:07
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
revolution: VESA standard 3.0 only supports 16-bit protected mode interface.

I would be surprised if anyone ever used that interface for something real (based on fact that generic windows drivers ignore it and use real mode calls).

Anyhow, VBE 3.0 says BIOS image has to be copied to write-enabled area. Do you do that?
Post 13 Aug 2009, 00:18
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17716
Location: In your JS exploiting you and your system
revolution
vid wrote:
revolution: VESA standard 3.0 only supports 16-bit protected mode interface.
Oh, that sucks, 16bit PM is best suited only to masochistic or insane people (and probably only really for someone that is both) Wink And I guess that includes me as one of the insane masochists, because I did it with my old 286 OS, yuck. Crying or Very sad
Post 13 Aug 2009, 00:31
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
I don't meant 286 protected mode. I mean 386 protected mode with code descriptor set to 16bit.
Post 13 Aug 2009, 08:27
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 713
Location: Adelaide
sinsi
Is there any reason you can't use linear buffer modes?
Post 13 Aug 2009, 08:36
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
sinsi: I think many BIOSes don't support it (but I may be wrong, I am still somewhat confused about this topic)
Post 13 Aug 2009, 10:22
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 713
Location: Adelaide
sinsi
VBE 2 supported it (according to ralf) but also supported linear modes, which kinda defeats the purpose...
Also, from the OP, we can't even assume he runs code in PM - I've seen lots of code written on the assumption that PM 'must be faster'.

Don't think I am accusing you of doing that, Artlav, but your original post is a tad vague.
Post 13 Aug 2009, 10:35
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Quote:
VBE 2 supported it (according to ralf) but also supported linear modes, which kinda defeats the purpose...

The VBE2 standard defines interface for linear framebuffer, but that doesn't automatically mean every implementation out there implements this interface. In fact, from BIOS vendor point of view, you'd hardly see difference between supporting it and not - drivers for bank-switching are written long ago, and the speed gain is, I think, minimal.
Post 13 Aug 2009, 10:57
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 713
Location: Adelaide
sinsi
Totally agree, but you would have to go back to ISA or early PCI video cards to see a (full) vbe2 interface without a linear buffer.
They basically had to for the drivers in win311.

I remember asking about this in a previous thread, but can't find it...
edit: here it is http://board.flatassembler.net/topic.php?t=8768
Post 13 Aug 2009, 11:24
View user's profile Send private message Reply with quote
Artlav



Joined: 23 Dec 2004
Posts: 188
Location: Moscow, Russia
Artlav
The 4F0A call returns a table at the given pointer, at table+0 there is a word offset from the start of the table to the function 05h entry point, or, that's how i understood it.

The description (VBE/Core 2.0 Standard) said nothing about 16bit PM code segment requirement that i could notice. Is it really that bad?

Even to the contrary, the description clearly mentioned 32bit mode:
Quote:
4.2. Protected Mode considerations

VBE services may be called directly from 32-bit Protected mode only.

For 32 bit protected mode, 2 selector/segment descriptors for 32-bit
code and the data segment are needed. These will be allocated and
initialized by the caller. The segment limit fields will be set to
64k. These selectors may either be in the GDT or LDT, but must be
valid whenever the VBE is called in protected mode. The caller must
supply a stack large enough for use by VBE and by potential interrupt
handlers. The caller's stack will be active if or when interrupts are
enabled in the VBE routine, since the VBE will not switch stacks when
interrupts are enabled, including NMI interrupts. The 32-bit VBE
interface requires a 32-bit stack.

Why not use LFB? 50% interest in figuring out banking mode, 50% bochs not supporting LFB modes.

sinsi: What exactly is too vague in my initial post? I'm not too good in english.
Post 14 Aug 2009, 05:16
View user's profile Send private message Visit poster's website Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 713
Location: Adelaide
sinsi
>What exactly is too vague in my initial post? I'm not too good in english.
Just wondering about your code (real mode or protected mode) and where it hangs. Have you tried bochs debugger?

>bochs not supporting LFB modes
I thought it did. What version are you using? (I'm using 2.4.1)
Post 14 Aug 2009, 05:38
View user's profile Send private message Reply with quote
Artlav



Joined: 23 Dec 2004
Posts: 188
Location: Moscow, Russia
Artlav
Code is in protected mode, it hangs shortly after the interface call.
Bochs (2.3.5.cvs) was not working with it at the time i originally posted, but it does now.

First problem, there is 0 in cx being returned by the 4F0A call, by both qemu and bochs, instead of table length, so nothing was actually copied.

That problem fixed, there is the second problem - at the given offset there is something that is definitely not 32bit pm code.

At that point, i checked what the interrupt did, and it actually did nothing for that call!
So, i got the bochs vgabios sources (http://www.nongnu.org/vgabios/), and here it was, all properly done. But, the disassembly is nothing like their int 10h handler, despite the vgabios binaries match and bochsrc being correct.
Something weird is going on, i assume, so i'll keep investigating.

If anyone got VBE PM under bochs working before, advice are welcome.
Post 14 Aug 2009, 06:40
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Artlav: Interesting. I use VBE3 specs, that goes into detail how to set up selectors for 32 to 16 bit PM transition, 16-bit stack, translate pointers to 16bit etc., before the calling. It says nothing about 32-bit interface. Unfortunately I can't copy-paste from it.

Can you link the document you use please? Mine is this I think.
Post 14 Aug 2009, 10:46
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Dex4u



Joined: 08 Feb 2005
Posts: 1601
Location: web
Dex4u
Its 16bit pmode interface, so to me your over half way to realmode, so just go back and forth to realmode for mode change.
Post 14 Aug 2009, 13:34
View user's profile Send private message Reply with quote
Artlav



Joined: 23 Dec 2004
Posts: 188
Location: Moscow, Russia
Artlav
vid: I used this one:
http://docs.ruudkoot.nl/vbe20.txt

Your link gives 404, but i guesstimate it's this one:
http://passxos.googlecode.com/files/vbe3.pdf
That one mentions both the 2.0 interface, also stating it to be 32bit PM, and the new one, which is something for 16bit PM.
Post 14 Aug 2009, 13:35
View user's profile Send private message Visit poster's website Reply with quote
Artlav



Joined: 23 Dec 2004
Posts: 188
Location: Moscow, Russia
Artlav
The VGAbios loaded and the interrupt handler are actually the same, i just didn't looked at the proper handler.
It seems that cirrus bochs VGABIOS does not have that interface implemented, so nothing is returned.
QEMU was using pretty much the same kind of vgabios, with the same effect.

Now, with the non-cirrus vgabios, bochs does indeed returns the PM interface table.
Unfortunately, it also returns 0 for VBE version and garbage for modes list.
Don't know why yet.


In other news, tried the third way of getting a bios interrupt to run from PM - full real mode emulation.
Surprisingly, it worked. Amazingly, it worked only twice as slow, with the bank switching call being the one emulated, in a random pixel plotting loop!

Which raises a question - is it vm86 about as slow as an emulator, or the 84 instructions long routine is being lost in the noise of whatever else is going on?

EDIT: The twice as slow case is only true for QEMU, in Bochs it's 15 times slower.
Post 14 Aug 2009, 21:10
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.