flat assembler
Message board for the users of flat assembler.
Index
> OS Construction > VBE In Protected Mode? Goto page 1, 2 Next |
Author |
|
edfed 23 Nov 2007, 06:45
to do that, it's by IO ports
as you can change the VGA resolution by the graphic adapter, you can make the same for vesa just find the related documents, read them and code. if you find , tell me. i didn't find any easy ressource in this document they say at page 77 that vbe 3.0 is a dual mode code
|
|||||||||||
23 Nov 2007, 06:45 |
|
vid 23 Nov 2007, 11:26
I/O ports are bad way, they don't allow almost anything. Highest you reach is 320x200x256 or 640x480x16. Use VESA.
There may be support in VESA to call it from protected mode, but I am afraid it is very little supported. If it is 32bit mode, then you make v86 monitor, and call VESA interrupts in v86 code. If it is 64bit mode, then you have a problem There are two ways: - you can switch to real mode. this is a big security problem for OS though and shouldn't be done by any real OS. - you can emulate interrupt. Emulator requires LOT of coding, but can be safe. Windows XP64 uses this method. |
|||
23 Nov 2007, 11:26 |
|
Dex4u 23 Nov 2007, 15:24
The Pmode vesa interface is not a good idea, as you still need to switch to 16bit PMode, so you should instead go to realmode change mode and then switch back to Pmode.
The big security problem, as vid pointed out, is not a big problem, that is because i can get round any OS simply by taking over the boot process and then i have full control over anything that runs on it, So that like saying do not boot up it a security risk, even vista is susceptible to being taken over on boot up. |
|||
23 Nov 2007, 15:24 |
|
f0dder 24 Nov 2007, 00:03
Dex: perhaps you missed the part that XP64 (without a proper video driver installed) actually calls VESA not just on startup, but while running, and uses an emulator to do this - hence security concerns.
|
|||
24 Nov 2007, 00:03 |
|
rhyno_dagreat 24 Nov 2007, 04:24
Thanks for the help! So much for trying to avoid mode-switching.
|
|||
24 Nov 2007, 04:24 |
|
MHajduk 25 Nov 2007, 12:06
rhyno_dagreat
Sorry for my curiosity, but I have to ask you: are you descendant of Welsh settlers in USA? Do you speak Welsh? |
|||
25 Nov 2007, 12:06 |
|
tom tobias 25 Nov 2007, 16:23
yes, Unol Daleithiau is the Welsh equivalent of the English: USA. However, such interesting and useful tidbits belong in Heap, not Operating systems.
|
|||
25 Nov 2007, 16:23 |
|
bitRAKE 25 Nov 2007, 16:44
From what I've read there are only a handfull of cards that support VBE 3.0, and some implementations are just wrong. Although those problems have been worked around by either coding a software driver (different for each card UniVBE), and/or copying the video ROM and patching it.
Google turned up many hits. |
|||
25 Nov 2007, 16:44 |
|
vid 25 Nov 2007, 17:30
Quote: From what I've read there are only a handfull of cards that support VBE 3.0 mine notebook's BIOS only has VBE 1.0 (even though with all highres modes). forget about linear framebuffer |
|||
25 Nov 2007, 17:30 |
|
f0dder 25 Nov 2007, 17:40
vid wrote:
Are you 100% sure about that, or have you only queried it inside windows? _________________ - carpe noctem |
|||
25 Nov 2007, 17:40 |
|
vid 25 Nov 2007, 17:59
Quote: Are you 100% sure about that, or have you only queried it inside windows? in case you meant exclusive OR, answer is NO (1 xor 1 = 0) Why would same code emulated beheave differently than when executed directly? any idea how could this happen? |
|||
25 Nov 2007, 17:59 |
|
bitRAKE 25 Nov 2007, 18:03
Luckily, my notebook has an Intel chipset which has open source code, and they say VBE 3.0 is supported but I don't know to what extent. Anyone know of a program to explore the implementation?
|
|||
25 Nov 2007, 18:03 |
|
vid 25 Nov 2007, 19:14
bitRAKE:
call interrupt 10 with AX=4F00, ES:DI = 200h byte buffer, and on return check word at [edi+2]. Check out any VESA tutorial |
|||
25 Nov 2007, 19:14 |
|
bitRAKE 25 Nov 2007, 19:36
Under windows the whole buffer is empty.
Code: org 100h push cs pop es mov di,200h mov ax,04F00h int 10 Edit: changed segment to ES. Now it overwrites bytes prior to ES:200 |
|||
25 Nov 2007, 19:36 |
|
vid 25 Nov 2007, 19:57
If VESA is supported, AX on return will be 004F, i forgot to write that last time. If it doesn't work "in windows" (eg. under NTVDM emulator), it means you either don't have any VESA, or more likely, NTVDM doesn't emulate VESA.
Quote: The Pmode vesa interface is not a good idea, as you still need to switch to 16bit PMode, so you should instead go to realmode change mode and then switch back to Pmode. AFAIK you only need to create 16bit code segment for calling BIOS. Check our VBE3 specs, it deals more in detail with this. |
|||
25 Nov 2007, 19:57 |
|
sinsi 26 Nov 2007, 08:03
bitRAKE, do you mean "int 10" or "int 10h"?
Code: format binary as 'com' org 100h mov ax,4f00h mov di,buffer push cs pop es mov dword [es:di],'VBE2' ;need this before the call to get VBE 2+ info int 10h cmp ax,4fh jnz .novesa cmp dword [es:di],'VESA' jnz .novesa ;word at [es:di+4] has version e.g. 0102h -> VBE 1.2 .novesa: mov ah,4ch int 21h buffer rb 512 ;buffer is 256 bytes for VBE 1 but 512 for VBE2+ I have read (somewhere) that in windows you might need a full-screen dos prompt to get some vesa functions. |
|||
26 Nov 2007, 08:03 |
|
bitRAKE 26 Nov 2007, 08:21
Thank you. Worked like a charm - forced console to fullscreen on int. Returns VESA version 3.0.
|
|||
26 Nov 2007, 08:21 |
|
f0dder 26 Nov 2007, 12:04
Iirc NTVDM defers loading/initialization of some of the BIOS emulation until certain other instructions have been called, ie. a INT10 modechange (dunno if it's the BIOS call or the resulting go-fullscreen that triggers this).
NTVDM is a strange beast. |
|||
26 Nov 2007, 12:04 |
|
pfranz 27 Nov 2007, 20:59
I have a working example of the general VBE protected mode interface in my HwTest version 0.4 found at http://pfranz73.googlepages.com/
To try it, select a video mode WITHOUT 32bit per pixel (that is, 8, 16, 24): if your BIOS supports this interface, it will be selected. You will see Scroll:Prot in the information messages. 32bit selects 4F0A interface for scrolling. Since previous versions caused troubles to someone, this time I'm testing HwTest on many different configurations, and testing is not over (see the site). I'm available for any question. |
|||
27 Nov 2007, 20:59 |
|
Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.