OSDev.org

I have been in OS dev for a long time... messed around in realmode... bought MMURTL v1.0 (a.k.a. How tyo write your own 32bit OS) I enjoyed toying with MMURTL but the system wasn't to friendly for my personal tinkerings and I have decided to embark on my own. I have spent the past couple of weeks reading and studying PMODE Tutorials and TSS and GDT and ITD. I have a companion book called "Protected Mode Software Architecture" Its a great book and I've learned alot from it. Ok enough ramble onto the point of this message.

I want to create my OS around a GUI. I know all of you are saying thats @$$ backwards but thats ok with me. I am extremely comfortable with this task but I wanted to run this by you guys.

- What I want is to have the Bootloaded set VGA mode 12 (640x480x16color) or maybe even (320x200x256 to make it even easier) in realmode
- The kernel is then loaded and sets a simple background and creates a default window (a console window)
- The system will then actually "boot" up... loading keyboard drivers ata disk serial lpt and whatever... All status will be displayed to the console window
- My printf or xprintf will push to a putch that will run through a font renderer (Basically A bitmapped rip of the 8x8 font)
- The font engine is easy enough as I have done the same thing for a dos gui.

I will definately being using C++ for this as classes will provide the easiest way to define my windows.

Please don't flame me (this is my first post...) but I just want some opinions on this... do you think its possible... and do you think I will run into any troubles doing a kernel in C++ with classes. Had anything like this been already done?

Thanks for the help guys,

Rich

Plotting in mode 12h is very slow (I've tried it). Also I'd set up the stuff in text mode and then move into whatever mode (it's not that hard to do this in pmode)

Code for my attempt to a similar problem is attached. It may not work and is several years old.

Good luck!

Pete

[attachment deleted by admin]

Hi
I can not coment on the c++ classes, But if i understand you right ,you want to do this in pmode.
I can not see any problems, But i would use VESA as once setup, it just as easy to use has mode 12 or 13.

PS: linux must do this on start up,as it has the graphic image in the corner or it use's to.

ASHLEY4.

Plotting in mode 12h isn?t very slow... It depends on your rutines..
And about linux.. i guess that it is mode 10h u are talking about, it is both graphical (640x350x16) and normal text (80x25)...

/ Christoffer

C++ classes are quite OK to use in kernel space, and it has been done.

Tripwires are Exceptions and RTTI (both requiring some runtime support not available in kernel space). You can disable them using compiler options, though.

You also have to write up your own operator new() and operator delete(), for memory handling. (Usually simple wrappers for malloc() and free() should suffice.)

Global / static constructors will create a linker section "*ctors*" (don't know exactly right now) in the object file, consisting of an array of pointers to said constructors - you will have to write some code to call them sequentially before using your global / static objects. Don't use complex dependencies here, they might break.

Check out the OS FAQ for some more details. Generally speaking, you'll probably do fine.

Just a few considerations about starting with graphical mode:

- mode 12h is uncomfortable to deal with because it has 'bitplanes', which means that in order to plot a single pixel, you need 4 "request/reply' cycle with the Video hardware and read/mask/write 4 times ... It can work efficiently if proper care is taken (i.e. defer some pixels until it "worth the switch"), but this usually involves more logic that a bootstrap/kernel can afford.

- mode 13h is a pain for your eyes, especially with that squared 8x8 fonts ... a 5x8 font will look much better. However, plotting characters manually is another source of possible mistakes and at very early stages, you'll probably prefer to write to a hardware-assisted console (i.e. real textmode)

- i've never seen something that would handle *both* graphics and text with the same hardware video mode ... this is somehow sad, but modes that announce both graphic and text resolutions actually offer text rendering through software BIOS ints, not in hardware ...

- plotting fonts yourself will probably not harm at all on real hardware, but it will certainly make most 'PC emulators' like BOCHS slow down severly ...

Pype.Clicker wrote: - plotting fonts yourself will probably not harm at all on real hardware, but it will certainly make most 'PC emulators' like BOCHS slow down severly ...

Bochs makes about 3-5 mhz. In 3 million cycles you can plot a full screen of pixels, and even when you use bitmaps for the fonts, if you take care not to write them sloppily.

@candy:
agree. 3-5MHz will be sufficient to echo the characters typed by the user or to draw the result of a 'LS' command ... But if you want to do something like a debug console (being *much* more verbose, so that you can know what was wrong if something does), you're likely to be doomed ...

My own experience told me that such debug output were gold-equivalent at first stages of a kernel ...

Pype.Clicker wrote: @candy:
agree. 3-5MHz will be sufficient to echo the characters typed by the user or to draw the result of a 'LS' command ... But if you want to do something like a debug console (being *much* more verbose, so that you can know what was wrong if something does), you're likely to be doomed ...

My own experience told me that such debug output were gold-equivalent at first stages of a kernel ...

Yes okay. For the debug output, I'd advise any kernel to go to text mode and dump it there anyway. Still, for a GUI it really sucks.

Also, if you can make an intelligent debug function, you might be just as well off with the graphical one

This sounds a bit like what I'm considering doing -- forgoing text mode, entering a VBE mode right at startup, and using a bitmapped font to echo characters to the screen. (This means that I won't write text-mode code and then later have to rewrite it when I finally switch to using a graphics mode.) Of course, my graphics screen will not be a full GUI with movable windows; just a screen with a monospaced font on it, as in text mode.

Advantages:
-- I can draw and use special characters that aren't available in text mode.
-- The font gives my system its own look, even before I have a real interface to show off.
-- If my characters are 8 pixels wide by 16 high and my video resolution is 800x600, I can print 100 characters per line (not just 80), and the screen can display up to 37 lines (not just 25).

Well I was thinking about mode 12h

640x480 16 color

My Font routines are really simplistic...

Array of 10101001 in ram, to render an 'A' requires 64 bytes (8x8) (I know this is extremely in-effecient, and I could pack the 1s and 0s into actually bytes)

My Plan is to have my bootloader kick in mode 12h in realmode... then in PMODE, I have i/o port only code that reders my pixels.

Initially I am just gonna setup one window that has the appearnce of a console style window, and then implement my own scrolling routines... there will be no calls to any type of textmode resouces as all charecters will be generated by my font-renderer.

Thanks all for the advice... now If I could just figure out how to compile my c++ files we'd be in business... My file compiles fine with g++ but I can't link it using the commands listed on the OS Faq... it complains about PE not avialible in PE Executeable or something similar.

On a side note, in a debate of C++ vs C (Just some ideas I was thinking I dunno if they've been brought up before)

Constructors / Destructors would require special attention, or would they behave normaly with out any modification.
Because Using Classes Would be super sweet, but I could just as easily use strict C and make Struct'ures and pass them to generic draw_window(struct mywin) functions. Which path do you think would provide the least resistence.

Thanks again for all the help!

Rich

creating an OS "around" a GUI ... *rofl*

I suppose, output routines in any graphics mode are ok, but I do not agree with the above mentioned statement.

You have to design and implement OS primitives first (like memory management stuff, Multitasking stuff, Interrupts and so forth ... all the neat things *required* either in text mode or in graphics mode).

I've done it the other way round: got all the necessary OS stuff running first, then tinkered with the gui. But I think you'll do fine with the approach you chose, only slow it might be in the bochs. Consider a routine which updates exactly the area of the actual drawn char in video memory.

It could worth mentionning here that one can switch video mode *without* clearing video memory, thus it is theorically possible to switch back to text mode when a problem occurs and to find the debugging informations there, rather than trying to display everything on the graphic screen ...

Im in two minds whether to start user info, in text or graphic mode or to have it at all .
Most people i have asked,say they take no notice and would much rather have a graphic demo,and only if theres a problem have it print a message.

ASHLEY4.