Having trouble plotting pixel color in 24 bit vesa modes

[~]

By the way, you could implement a function to save settings to apply after rebooting.

In this way, you can get all of the supported standard and nonstandard modes at boot time from your boot manager (the program that gets loaded by the boot sector and that in turn loads the rest of the kernel or the operating system).

Now, if the user selects a video mode that you cannot currently enter, you can offer the user to switch the video mode after rebooting. Then your boot manager will see the video mode that it should use, and apply before entering 32-bit Protected Mode or 64-bit Long Mode.

In this way, you could switch between standard VGA modes and Super VGA modes for which you have a native driver.

But if you happen to want to switch between standard and Super VGA modes without a driver and without emulating the BIOS code, you can still do so by saving the desired mode on the disk where the OS is installed, and then reboot using that new display mode. Then the boot manager will use the VESA mode (or even the standard text or graphics VGA mode) that was indicated.

It's a great improvement over only using a fixed mode or selecting it only at boot time, isn't it? Now you can select the video mode to use while using your own OS, after rebooting, using on-disk configuration files.

____________________________________
You could also implement saving the state of the whole OS on disk so you can reboot as fast as possible (caching the whole state of the hardware configuration and devices present), then resuming the multitasking and memory-management data back to memory (maybe by flushing I/O and freezing each task individually until you reboot and resume).

Then you can switch more on the fly by rebooting very fast, probably also trying a warm reboot for increased stability, through the KBC or another mechanism. Then it would almost feel as if you had native video drivers if you make it both efficient/fast and stable (meaning resuming the whole state won't cause crashes -- whatever task state was in the devices and in the multitasking/paging structures, that's exactly what will be restored, starting by the most critical programs).

[beyondsociety]

I haven't had a chance to try out any of the code yet but have managed to read through all the useful information. As alexfru and JAAman pointed out, I meant to use the edi register for the calculations and not ecx which explains why it was getting overwritten, thanks for pointing that out. I knew it was something simple I was doing wrong and had to do with using the right registers and an issue with "rep stosd".

Code: Select all

If you have 800 pixels wide, how are you going to place a pixel at X coordinate 815?
If you have 600 pixels tall, how are you going to place a pixel at Y coordinate 615?
If you have 800 pixels wide, how are you going to fit 800 24-bit pixels into 24 bytes per line?

I was thinking in normal x and y coordinates but wasn't having any luck plotting pixels so I thought I needed the resolution plus the x or y coordinate I wanted to plot, boy was I wrong and thanks for mentioning that mistake. The 800 * 3 for the bytes per line makes more sense now as I saw a put pixel function in the Osdev wiki for 24 bpp and it had 2400, which I couldn't figure out for the life of me how they got that, now I know it was 800 * 3 = 2400 bytes per line.

Code: Select all

I don't remember if you mentioned why you wanted a 24-bit color mode. This is the slowest mode there is, not necessarily the video mode, but the way you write to the frame buffer.

I originally wanted to use 32 bpp for the high end and 16 bpp modes for the low end to support but was having a hard time trying to get Bochs or Qemu to go higher than 24 bpp. I had read that they both supported 32 bpp but couldn't get it to work unless I set grubs graphics fields in my current kernel or used my Bochs Graphics driver. The issue was that I was manually setting the mode for Vesa in real mode instead of writing a function to query for the best possible resolution. If I had done that from the start, I would of already solved one of my issues but the help with getting 24 bpp to work has been valuable to me and will be used for the other supported modes.

As for what Brendan mentioned about not checking for certain vesa things, I plan to fix all those once I get this plotting of pixels issue sorted out.

[BenLunt]

Glad to hear. Bochs must have the cirrus driver loaded to allow 32-bit modes.

bochsrc.txt:
vgaromimage: file=path_to_use/VGABIOS-lgpl-latest-cirrus
vga: extension=cirrus, update_freq: 10
pci: enabled=1, chipset=i440fx, slot1=cirrus

If you haven't used it already, you want to use service 0x4F00 to check to see if VESA is available and which version it supports.
Then use service 0x4F01 to get information about a given mode. Service 0x4F00 will return all supported modes including modes
that would be supported if the monitor and/or graphics card supported it. Check the first byte in the returned information.

Good luck,
Ben

[beyondsociety]

After trying out both Brendans and BenLunts code, I was able to finally plot more than one pixel to the screen in red as well as change the entire background. As for the cirrus driver allowing 32 bpp modes, I didn't know that. Will try that out as soon as I recompile Bochs as it doesn't have the cirrus driver compiled in by default.

[beyondsociety]

So I recompiled bochs for cirrus vga driver and still can't get bochs to output higher than 24 bpp even though it supports 32 bpp. I believe it has to do with manually selecting the mode and not using a function to parse for the best video mode possible. I plan to clean up the code and move on to other things.