VESA

[jamsinux]

Hello everyone,

I was wondering if when our OS - boot sector, kernel and shell - are ready, will the tutorials have something about setting some form of GUI or VESA modes?

Thank you, jamsinux

[Mike]

Hello,

Yes, we do plan on covering graphics and developing a GUI after the shell.

More specifically, we will be developing a video driver and shared graphics library/driver.

Because it is not possible to develop drivers for every video card, we are going to only use onboard graphics controllers that are standard among motherboards. This is the current plan, anyway.

Not to surprising, if you have experience with 16bit real mode DOS graphics, it is not that different from what we need for our graphics driver.

After the video driver (To interface with the controller), the graphics driver (Shared library for graphics routines. Uses the video driver to render), we can focus on the actual GUI for the OS, which uses our graphics driver.

Hope this answers your question

[jamsinux]

Wow, great thanks. Don't worry if it is 16-bit or anything else because the good thing is that there will be GUI. Thanks a lot for your quick reply and yes, you have answered my question .

until next time
Regards jamsinux

[Mike]

If you are interested, we have started working on a video controllers tutorial, including information on programming several video controllers in 32 bit PMode.

It will include example (and tested) C++ source code as well to demendstrate everything that may be used in your MSVC++ Kernel.

The tutorial itself will be much more complex then our 8259A PIC tutorial, do to the nature of video programming.

We are not going to be using anything 16bit. Everything will be 32bit, hopefully with support for 64bit architectures.

[dev]

What's the timeline for the video tutorial and the interrupt one?

I've started poking at video and working on the interrupts myself but I'm experiencing some very weird issues (accessing global array generates a triple fault ).

How will you be handling the 32bit video driver? I'm assuming using VBE3 and mapping the stuff to protected memory or is there another/better/easier way?

[Mike]

What's the timeline for the video tutorial and the interrupt one?

We will not cover the video and graphics tutorials until later after we have a solid kernel running. Trust me-its easier this way. While we can get into a video mode now, graphics programming can be very hard without a better foundation (ak, memory manager primarily.) I plan on covering 2d software rendering...Mabey 3d later on after the system gets more evolved.

Graphics tutorials might be placed in a different section of this site, linked from the OS Dev Series.

The interrupt tutorial, which was scheduled for tutorial 14 will be pushed to tutorial 15.

Heres the current timeline to the interrupt tutorials...

Tutorial 14 - Kernel and HAL Initialization
Tutorial 15 - Interrupt Handling Part 1
Tutorial 16 - Interrupt Handling Part 2

Hardware Interrupt devices will either be referenced from Tutorial 16, or moved to their own tutorial - Tutorial 17. It depends on how big these tutorials get. We plan on covering these in alot of detail.

I've started poking at video and working on the interrupts myself but I'm experiencing some very weird issues (accessing global array generates a triple fault :/ ).

There can be several reasons for that, and it is not related to video, but rather your envirement setup and linker map. In some cases, the C++ runtime might generate sections that are required by the compiler (We do this in our MSVC++ tutorial.) This is very compiler dependent, however.

If you are using GCC or DJGPP, We plan on adding those tutorials very soon that may resolve that problem.

If you are using one of these compilers, perhaps we can help you out here.

How will you be handling the 32bit video driver? I'm assuming using VBE3 and mapping the stuff to protected memory or is there another/better/easier way?

We are still considering this. While VBE is a great option, it is not compatible with all systems. We might cover both VGA and VBE device programming.

We were considering VGA for its portability (It can support up to 800x600 resolution)...We are still thinking about it, however.

Ideas and opinions on this matter would be greatly appreciated!

*edit: Hm... Looks like the sites going a bit slow today..Going to have to look into that this weekend.

[dev]

We will not cover the video and graphics tutorials until later after we have a solid kernel running. Trust me-its easier this way. While we can get into a video mode now, graphics programming can be very hard without a better foundation (ak, memory manager primarily.) I plan on covering 2d software rendering...Mabey 3d later on after the system gets more evolved.

True enough. Will you be creating a memory manager from scratch or porting an existing one? Plan to support virtual memory and paging (I guess you'll need a filesystem for that)?

For 3D might just be able to port Mesa over for OpenGL support unless you want to create your own API for it.

Heres the current timeline to the interrupt tutorials...

Tutorial 14 - Kernel and HAL Initialization
Tutorial 15 - Interrupt Handling Part 1
Tutorial 16 - Interrupt Handling Part 2

Hardware Interrupt devices will either be referenced from Tutorial 16, or moved to their own tutorial - Tutorial 17. It depends on how big these tutorials get. We plan on covering these in alot of detail.

Is the HAL going to be it's own dll? What will you be putting in the HAL, the HW IO, interrupts and some higher level stuff (spinlocks, semaphores)? I've just been throwing everything into the kernel, don't think I'll ever need to run it on anything else than x86.

There can be several reasons for that, and it is not related to video, but rather your envirement setup and linker map. In some cases, the C++ runtime might generate sections that are required by the compiler (We do this in our MSVC++ tutorial.) This is very compiler dependent, however.

If you are using GCC or DJGPP, We plan on adding those tutorials very soon that may resolve that problem.

If you are using one of these compilers, perhaps we can help you out here.

I am using MSVC 2005 and it isn't related to the video stuff I am doing. I have an array of interrupt descriptors and if I access the array it generates a triple fault.

I've also had some other weird problems in the past with it, for the longest time I couldn't get a kernel over 4KB to boot (triple fault). Even when the extra data/code in there was never access or called, can't remember what I did to fix that.

I'm handling the runtime the same way you are (in the MSVC tutorial) so I don't think that is the problem...

We are still considering this. While VBE is a great option, it is not compatible with all systems. We might cover both VGA and VBE device programming.

Interesting, what systems is it incompatible with? I assumed it would work pretty much on anything now since the spec was released in 98.

[Mike]

True enough. Will you be creating a memory manager from scratch or porting an existing one? Plan to support virtual memory and paging (I guess you'll need a filesystem for that)?

Probably from scratch. Virtual memory and paging is a must.

For 3D might just be able to port Mesa over for OpenGL support unless you want to create your own API for it.

If we can port Mesa, this should work fine. Interesting idea

Is the HAL going to be it's own dll?

This was originally planned, however it would be to complex at this stage as the bootloader will require some advance topics that have not been covered yet.

For now, it is going to be treated as a static library. I plan on adding a section later to expand the bootloader, and give it more capabilities (Booting from hdd, usb, support more filesystems, error handling, memory management, and loading the kernel and hal as independent programs.

As it is a static library, it is still independent of the kernel...We will dynamically load it later similar to hal.dll however.

What will you be putting in the HAL, the HW IO, interrupts and some higher level stuff (spinlocks, semaphores)? I've just been throwing everything into the kernel, don't think I'll ever need to run it on anything else than x86.

One of our goals with the series is to encourage good coding practices and design. While we may not port the system to more then one architecture, we should still provide interfaces and abstraction layers to allow for easier portability...This is our primary reason for doing it this way.

The HAL itself will include interfaces to the basic motherboard chipset devices that the kernel may need. This, of course, includes the processor.

In other words, if the kernel reqiores any access to a device, it will NOT use port IO. Instead, it will go through the HAL.

Interesting, what systems is it incompatible with? I assumed it would work pretty much on anything now since the spec was released in 98.

Most systems these days do support it, alot of the older machines dont though. (Im referring to machines still running Win95, Win98, etc...)

If the series reader demand for this is great enough, we might just skip the vga, and use VBE... What would you like?

[scorpion007]

If the series reader demand for this is great enough, we might just skip the vga, and use VBE... What would you like?

I don't know, I think if VGA is simpler I'd prefer it as a starting point, especially as it's supported on more platforms. 800x600 resolution is plenty for a start.

If you like you can do VBE or whatever it is later on, I've never heard of it myself, but I'm a noob.

[michael]

Is VESA and SVGA the same thing?.. sorry if im like totally wrong lol.

[gzaloprgm]

If the series reader demand for this is great enough, we might just skip the vga, and use VBE... What would you like?

I don't know, I think if VGA is simpler I'd prefer it as a starting point, especially as it's supported on more platforms. 800x600 resolution is plenty for a start.

If you like you can do VBE or whatever it is later on, I've never heard of it myself, but I'm a noob.

Hello, VGA only supports
* 640×480 16 colors
* 640×350 16 colors
* 320×200 16 colors
* 320×200 256 colors (Mode 13h)

So, if you wanna use 800*600*24 you will have to use SVGA.

[stoic1979]

hi guys,

i have followed the tutorials on this website and done
GDT and IDT related stuff.

I am planning to give some GUI to my OS.

can anyone pls , guide me how to start with GUI development.

can anysomne send me some good tutorial link.

thanks
stoic