OSDev.org

Posted: **Wed Oct 10, 2012 3:42 pm**

Hey there,

I am a hobby programmer who is very experienced in C/C++/OBJ-C/Java/etc. However I have never done anything with assembly.

A while back, I taught myself C++ OpenGL, WinSock, and all the good stuff. Which, while very entertaining, has lost it's "thrill".. I wanted to give OS dev a go, because it one of the few things I have not yet done with a PC. I have followed countless tutorials on youtube, and various websites to get started with an OS in C/C++ with minimal Assembly. Although, most tutorials I saw were abandoned a long time ago.... I understand most of the basics of OS Dev. But most tutorials stop right before they get into Graphics. The furthest I have seen a tutorial go is to get into mode 13h... But I have no clue where to go from there, and no indication that what I did is correct?

I would really appreciate it if someone could point me somewhere that I could learn more about how to draw pixels with mode 13h (or whatever would be best for GUI) in C/C++. I have checked the wiki, but had trouble understanding what had to be done.

If there is any example code in C/C++, that would be GREAT. Thanks

.

Vlad Ellis.

P.S.
I am running my OS using a simple ASM setup and C takes over. I hope to use mainly C/C++. Running using GRUB and built on a Ubuntu machine with GCC. I would be happy to post what I have so far, if that would help?

Posted: **Wed Oct 10, 2012 4:12 pm**

As for drawing stuff you have basically left the field of operating systems and entered graphics programming. There are many good books on that subject. As for mode 13 you should find a good VGA book. I've seen a couple of mode 13 tutorials/resources by googling for mode 13.

Posted: **Thu Oct 11, 2012 5:47 am**

I think that it is best that you start using VESA BIOS Extensions (VBE) to set up a higher resolution graphic mode with Linear Framebuffer Access (32 bit pixels). It is probably what you want (instead of "13h"). It is a little harder to do but it is worth it.

ellisvlad wrote:I would be happy to post what I have so far, if that would help?

Please feel free to do that. At least I am interested to see it.

Posted: **Thu Oct 11, 2012 9:09 am**

The video memory is located at the linear address 0xA0000. To access a pixel at x, y, use the formula:
pointer = 0xA0000 + y*320 + x

Each pixel is one byte.

Mode 13h is arguably the simplest; try drawing a few simple things so you can get the hang of it. Once you do, learn a bit about VESA (13th is very low resolution so you probably don't want to stick with it). Set up a linear buffer in VESA and modify your routines to work with it.

Or, better still, plan your routines to work well in almost any environment:

pointer = base + (y * xResolution + x) * bytesPerPixel

That will work in any video mode with a linear buffer that doesn't have "blank" spots other that 16 color modes.

Posted: **Thu Oct 11, 2012 9:16 am**

pointer = base + (y * xResolution + x) * bytesPerPixel

Wrong.

Code: Select all

pointer = base + y * bytesPerScanLine + x * bytesPerPixel

VBE specification defines bytes per scan line as the only guaranteed to work way to iterate over lines in linear frame buffer. y * x resolution may, but also may not work.

Posted: **Thu Oct 11, 2012 9:53 am**

Griwes wrote:
pointer = base + (y * xResolution + x) * bytesPerPixel
Wrong.
Code: Select all
pointer = base + (y * bytesPerScanLine + x) * bytesPerPixel
VBE specification defines bytes per scan line as the only guaranteed to work way to iterate over lines in linear frame buffer. y * x resolution may, but also may not work.

Not wrong. I said it would only work when there are no "blank" spots (ie bytes per scanline = pixels per scan line * byte per pixel); I was trying to keep it as simple as possible while still being relatively flexible.

Also, yours is wrong; you can't multiply by bytes per scanline and then multiply by bytes per pixel.

Posted: **Thu Oct 11, 2012 10:50 am**

azblue wrote:Not wrong. I said it would only work when there are no "blank" spots (ie bytes per scanline = pixels per scan line * byte per pixel); I was trying to keep it as simple as possible while still being relatively flexible.

You did not define what "blank" spot is, and I don't think VBE specs don't define it either. Also, I'm not sure why you're calling it "blank"...

And how is a formula that is *more* complicated (and it is, look at all those ()s!) *simpler*?

Also, yours is wrong; you can't multiply by bytes per scanline and then multiply by bytes per pixel.

Fixed, thanks for noting.

Posted: **Thu Oct 11, 2012 2:01 pm**

Mode 13 is very unrewarding - the pixels are huge and they aren't square on any monitor I've ever seen, so your circles will look oval or ugly no matter what you do. It's much better to use a modern machine and the best resolution VESA mode for it. You may need this:-

http://www.petesqbsite.com/sections/tut ... s/vbe3.pdf

You say you use GRUB though, so that may get in the way of using VESA directly - I don't use GRUB so I don't know how many hoops you'd have to jump through there.

I'm now using 32-bits-per-pixel 1024x700 and 1280x800 modes on widescreen laptops set up through VESA, and it makes graphics stuff fun and rewarding. I also import .bmp files in from FAT32 partitions on flash drives using the BIOS to load them, and I could easily export images created in my OS in the same way - this can all be done with a simple operating system. It won't be so easy on future machines which only boot with EFI, but at the moment the door is still open. Again though, GRUB may get in your way, making it difficult for you work out how to get into real mode to use the BIOS for saving files.

Posted: **Thu Oct 11, 2012 3:52 pm**

DavidCooper wrote:they aren't square on any monitor I've ever seen

Someone's never seen a 16:10 monitor... Laptops included...

Mode 13 is very unrewarding

Any success is rewarding. Getting yourself into a graphics mode with solely your own code is especially an achievement of its own...

Posted: **Thu Oct 11, 2012 4:16 pm**

Dear Vlad ,

I learned about mode 13 h programming via this one ...

http://atrevida.comprenica.com/

--Thomas

Posted: **Fri Oct 12, 2012 3:59 pm**

Combuster wrote:
DavidCooper wrote:they aren't square on any monitor I've ever seen
Someone's never seen a 16:10 monitor... Laptops included...

Thanks for using a "liar" smilie on that: you always assume the best motives of people. I hadn't realised that a machine I recently tried my OS on has exactly that shape of screen, but that's the first machine I've ever had access to with the right shape of screen. I don't know when monitors of that shape first appeared, but I'd be surprised if they were common until long after massively superior VESA modes were universally available - before that, everyone seemed to be trying to set up mode X to get around the problem of mode 13h not being the right shape for their screen.

Mode 13 is very unrewarding
Any success is rewarding. Getting yourself into a graphics mode with solely your own code is especially an achievement of its own...

It could just slow things down and delay people's experimentations with VESA modes - it took me a long time to find out how to get beyond using the VGA modes because everything I'd read about VESA made it sound difficult to set up and also dangerous (with monitors being fried if you make a mistake). You, in an answer to someone else's question, showed me the way into VESA (by linking to the documentation which I had thought was only available if you paid for it) and that was all it took to get past what had appeared to me to be a huge barrier. I don't want to see anyone else limiting themselves to VGA modes if they'd get more out of using a high-resolution graphics mode. If mode 13h really suits them better for their purposes, then that's fine too, but I found the VGA modes so unrewarding that I simply gave up on doing graphics until I got into VESA modes, whereas I now spend a substantial chunk of my time doing fun stuff with graphics (mainly for the purpose of writing software that can identify things that I draw).

Anyway, I don't want to get into an argument about this - I simply wanted to point to the way in that you showed me so that the OP can see that it's there.

Posted: **Tue Oct 16, 2012 3:41 am**

DavidCooper wrote:I'd read about VESA made it sound difficult to set up and also dangerous (with monitors being fried if you make a mistake).

But modern monitors comes with an automechanism for to prevent us to fried our monitor with wrong CRTC parameters, if they exeed the capacity of the monitor.
Then it is shown an onscreen window with a warning message like: Out of sync, please check the cable, or a similar message.
Or the monitor still ignore a higher refreshrate like my 28" LCD from HansG with a native resolution of 1920x1200(16:10) with 60hz, if i try to switch into a vesamode with 1024x768 and with 100 hz refreshrate.
(Results a resolution of 1024x768 and with a 60hz refreshrate.)

Additional we can get some informations from our monitor recieving the extended display identification data(EDID) using the display data channel(DDC),
for looking about the manufacturer recommended and prefered timing and prefered mode of the monitor and for the maximum horizontal frequency in khz and the maximum vertical refresh frequency in Hz.

Public and costfree documents from vesa.org (need only register/login):
EEDIDguideV1.pdf
EEDIDverifGuideRa.pdf
...
vbe3.pdf

Dirk

Posted: **Tue Oct 16, 2012 6:18 am**

The vast majority of monitors are safe from signal "tampering" from the video card. There are just a few known (old fixed frequency VGA CRTs) and less known (at least one specific LCD model it's owner neglected to name) that will burn out under such conditions. It's those stupid corner cases, rare but independent of age, that demand the big fat warning.

Yet, if you ever want to get something done in the video world, voiding some warranties is a consequence. And you don't have a duty to tell your retailer you voided it

Posted: **Wed Oct 17, 2012 12:40 pm**

Combuster wrote:The vast majority of monitors are safe from signal "tampering" from the video card. There are just a few known (old fixed frequency VGA CRTs) and less known (at least one specific LCD model it's owner neglected to name) that will burn out under such conditions. It's those stupid corner cases, rare but independent of age, that demand the big fat warning.

Yet, if you ever want to get something done in the video world, voiding some warranties is a consequence. And you don't have a duty to tell your retailer you voided it

And the vast majority of laptop LCDs (they're pretty much raw panels with no protection circuitry)

Posted: **Sun Oct 28, 2012 8:35 pm**

ellisvlad wrote: I am a hobby programmer who is very experienced in C/C++/OBJ-C/Java/etc. However I have never done anything with assembly.

Never can u be VERY experienced in C/C++ without understanding assembly. But soon u will i think.

OSDev.org

13h in C?!

13h in C?!

Re: 13h in C?!

Re: 13h in C?!

Re: 13h in C?!

Re: 13h in C?!

Re: 13h in C?!

Re: 13h in C?!

Re: 13h in C?!

Re: 13h in C?!

Re: 13h in C?!

Re: 13h in C?!

Re: 13h in C?!

Re: 13h in C?!

Re: 13h in C?!

Re: 13h in C?!