Index
> OS Construction > VBE PM interface? |
| Author |
|
|
revolution 13 Aug 2009, 00:07
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]? |
|||
13 Aug 2009, 00:07 |
|
|
vid 13 Aug 2009, 00:18
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? |
|||
|
13 Aug 2009, 00:18 |
|
|
revolution 13 Aug 2009, 00:31
vid wrote: revolution: VESA standard 3.0 only supports 16-bit protected mode interface.  And I guess that includes me as one of the insane masochists, because I did it with my old 286 OS, yuck.  |
|||
|
13 Aug 2009, 00:31 |
|
|
vid 13 Aug 2009, 08:27
I don't meant 286 protected mode. I mean 386 protected mode with code descriptor set to 16bit.
|
|||
|
13 Aug 2009, 08:27 |
|
|
sinsi 13 Aug 2009, 08:36
Is there any reason you can't use linear buffer modes?
|
|||
|
13 Aug 2009, 08:36 |
|
|
vid 13 Aug 2009, 10:22
sinsi: I think many BIOSes don't support it (but I may be wrong, I am still somewhat confused about this topic)
|
|||
|
13 Aug 2009, 10:22 |
|
|
sinsi 13 Aug 2009, 10:35
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. |
|||
|
13 Aug 2009, 10:35 |
|
|
vid 13 Aug 2009, 10:57
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. |
|||
|
13 Aug 2009, 10:57 |
|
|
sinsi 13 Aug 2009, 11:24
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 |
|||
|
13 Aug 2009, 11:24 |
|
|
Artlav 14 Aug 2009, 05:16
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 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. |
|||
|
14 Aug 2009, 05:16 |
|
|
sinsi 14 Aug 2009, 05:38
>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) |
|||
|
14 Aug 2009, 05:38 |
|
|
Artlav 14 Aug 2009, 06:40
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. |
|||
|
14 Aug 2009, 06:40 |
|
|
vid 14 Aug 2009, 10:46
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. |
|||
|
14 Aug 2009, 10:46 |
|
|
Dex4u 14 Aug 2009, 13:34
Its 16bit pmode interface, so to me your over half way to realmode, so just go back and forth to realmode for mode change.
|
|||
|
14 Aug 2009, 13:34 |
|
|
Artlav 14 Aug 2009, 13:35
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. |
|||
|
14 Aug 2009, 13:35 |
|
|
Artlav 14 Aug 2009, 21:10
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. |
|||
|
14 Aug 2009, 21:10 |
|
< Last Thread | Next Thread > |
Forum Rules:
|