OSDev.org

Hey Everyone,

I have created a boot loader that loads an extended boot loader from disk (reading sectors, no file system) and it then gets some info about the VESA system installed, sets up a GDT at 0:0 (destroying the R/M IDT). What I need before I can go on is a P/M IDT.

I have checked out the intel docs and viewed alot of source code, but none that is really well commented, I was just wondering if anyone knows of some code that really explains what is going on as it creates and sets up an IDT.

I would also like some information on setting up a keyboard handler, as well.

Thanks.

PlayOS wrote: Hey Everyone,

I have created a boot loader that loads an extended boot loader from disk (reading sectors, no file system) and it then gets some info about the VESA system installed, sets up a GDT at 0:0 (destroying the R/M IDT). What I need before I can go on is a P/M IDT.

that seems a bad idea imho : you'll never be able to go back to real mode or use V86 virtual mode ...

That is OK because I have no intention of ever going back into R/M, It seems to me that this is an old feature and is not preferred, I will not be providing support for this as nothing made these days uses it, except for DPMI, which I think is silly as you can replace all of the R/M IDT with the same procedures in the P/M IDT. I also dont see why anyone would want to enhance DOS when you have Linux, if I wanted a console based OS I would just use that.

Thanks for your opinion anyway.

Your IDT setup code is basically very close to a setup-GDT code : in a first time, you have to build the table's data (it can be builtin static datas for each descriptors, generated on-the-fly, or whatever , then you load its address in IDTR register.

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/clicker/c32-src/core/control.asm?rev=HEAD&content-type=text/vnd.viewcvs-markup
and http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/clicker/c32-src/core/interrpt.inc?rev=HEAD&content-type=text/vnd.viewcvs-markup
link to some code for IDT setup & infrastructure in my own OS. It might be a bit complicated to fully understand because i have compacted the informations about the table (i was trying to do a very tiny OS on that moment) and use some special macros to have syntactic sugar on structures members access, but at least the interrupt stubs and the IDT setting code might help you

B-)

That is OK because I have no intention of ever going back into R/M, It seems to me that this is an old feature and is not preferred

Do you intend to provide a GUI or power management? If so, you'll need to call BIOS functions, which require a valid IVT and BIOS data area. Alternatively, you could pay for a copy of your video card's or motherboard's specifications (very expensive, if not impossible).

I intend to provide a GUI Windowing System, which I will be using VESA Mode to display the graphics, I will be using the Linear Frame Buffer for P/M, I am not aware that I need the BIOS IVT for this. Why do I need the BIOS?

There are two ways of writing video drivers:

1) You could use the VESA BIOS interface by using the extended int 10h functions in V86 mode.

2) You could obtain specifications from the manufacturers of every card you intend to support. You might have to buy them and sign a non-disclosure agreement, or the manufacturers might not be prepared to make them available (trade secrets). If so, you might persuade them to write drivers for you.

Option (2) is extremely unlikely to happen for an amateur OS developer (it barely happens for Linux). Using the VESA BIOS is pretty much your only option unless you want to be stuck with 640x480x4 or 320x240x8 VGA.

I have seen many tutorials on the net that simply find the address of the ModeInfo.PhysBasePtr and Map the screen to memory and use it to draw to the screen, I assumed this to be a generic trait of all modes that support the Linear Frame Buffer (LFB), these tutorials never said anything about needing specific card specification. I already have used the BIOS in my boot code to load information about all available modes, all I need to do is map the LFB and write directly to that (which I cant do at the moment because all examples are using __DPMI_ stuff).

I do not intend to support extended features of the cards (at least not for a while) so cant I just write a kind of generic VESA driver that only uses the modes that are compatible with the LFB, assumng that VESA exists on the system, if it does not then I would revert to command line or something.

That only works if the card supports a linear frame buffer (only newer cards do) and if the card is already in graphics mode. Unless you call int 10h from V86 mode, you will have to initialise graphics mode from your boot loader and you won't be able to change modes without rebooting. It would be like being back in the days of Windows 3.1.

I'd seriously advise you not to write over anything below the address 0x1000. In any case, if you leave that unmapped (when you use paging), any null pointer writes will be trapped. At the moment, if you try to write to a null pointer, your GDT and IDT will be corrupted. The first buggy program will crash the whole system!

I thought that there a protected mode interface for VESA, does this not let you switch modes?

Also aren't most cards these days VBE2 Compliant?

the mode switching support for PMODE is only available in VBE3
It is - for instance - avl. on my GeForce 2