Drawing to my screen should not be so hard

[CheeseBees]

ok. How would i go about doing that. and what bootloader do i use

[eryjus]

Reading up on GRUB would be a good place to start. You would create a specially formatted executable with a multiboot header in the beginning of your binary which would request that GRUB set the resolution and color depth for you and provide the frame buffer address (and other related video information).

When you boot, GRUB would get control first and collect all the necessary information for you (and some other important information such as a memory map) and then load your code and jump to it. GRUB will put the CPU in protected mode and would set up a small stack and temporary GDT for you.

You need to know: GRUB will try to set the resolution based on "best effort". When you read the documentation you need to pay very close attention to the word "may", as GRUB may give up if you are asking for something it cannot figure how to comply with your request. GRUB might give you a different resolution that is "close" to the request or may not service the request at all if it cannot figure out what you are asking it to do. The good news is that GRUB will report back to you what it was able to accomplish for your request.

[CheeseBees]

So if I were making a bootloader of my own, with a resolution selection, would that work?

[kzinti]

So if I were making a bootloader of my own, with a resolution selection, would that work?

That would be a first step. The bootloader will give you to address of the frame buffer in memory. Chances are that this memory will be outside the 32 bits address space available to a 32 bits protected mode application. Consider that a 1080x768x32bpp frame buffer requires at least 3.16 GB of memory... That's very likely not going to be in the first 4 GB.

Your next step is going to figure out how to map the frame buffer memory into your address space and/or switch to 64 bits mode.

[CheeseBees]

my preference would be to do this in 64 bit

So assuming i have this working, where would this go in my list:
1. Make stuff boot obviously
2. Pci-e enumeration
3. Writing driver
4. Plotting the pixel(s)

[Octocontrabass]

If you only want to plot pixels and you don't care about writing a driver, your steps are:
1. Boot with GRUB
2. Make sure the frame buffer meets your expectations (or change your expectations to match the frame buffer)
3. Plot pixels

You don't need to enumerate the PCI bus or write any drivers. GRUB will use the firmware (VBE/GOP) to set up the video card so that you can begin plotting pixels immediately.

If you want to be in 64-bit mode, add "switch to 64-bit mode" anywhere after step 1.

If you want to use your own bootloader instead of GRUB, your bootloader can still use the firmware to set up the video card.


If you're more interested in writing a driver and just using "being able to plot pixels" as a goal, your steps are:
1. Boot
2. Enumerate the PCI bus to learn (or set) the addresses of the video card
3. Write a driver
4. Plot pixels

[CheeseBees]

Enumerate the PCI bus to learn (or set) the addresses of the video card

now how would I go about doing that

[Octocontrabass]

https://wiki.osdev.org/PCI

[Schol-R-LEA]

@CheeseBees: I noticed that you still haven't mentioned the development host OS (that is to say, the one you are developing the new OS/bare metal program on, and the one which is the host for QEMU) you are using. Most of what we've discusses regarding QEMU has assumed you are using some flavor of Linux for this, but if you are using something else such as Windows, MacOS (because Hackintoshen are a thing), FreeBSD, or, uh, I dunno, Haiku maybe... anyway, the development platform will factor into how the virtualization works.

For that matter, if it is Linux, then the distro, distro version, and kernel version will be significant as well, and which AMD drivers you are using (either the official Catalyst drivers, or the semi-supported but open source GPUOpen amdgpu ones) and the version of those may be too.

We might even need to know how you have the UEFI and GRUB boot options set up, as well as certain kernel build options (especially if you have tweaked any of them - uncommon for users of Debian/Ubuntu/Mint derived distros, but quite common for those running with high-performance, bleeding-edge distros such as Arch or Gentoo, or special-purpose ones such as Kali or Qubes).

[iansjack]

Basically im using mingw w64 and nasm on windows 8.1

[iansjack]

Consider that a 1080x768x32bpp frame buffer requires at least 3.16 GB of memory... That's very likely not going to be in the first 4 GB.

???

I think you may be confusing GB and MB.

[CorruptedByCPU]

Consider that a 1080x768x32bpp frame buffer requires at least 3.16 GB of memory... That's very likely not going to be in the first 4 GB.

???

I think you may be confusing GB and MB.

@ianjack is right.
32bpp == 4 Bytes
1080 Pixels * 768 Pixels * 4 Bytes = 3317760 Bytes / 1 KiB = 3,24 MiB

[CheeseBees]

Anyone have a basic PCIe enumeration script in c?

[kzinti]

I think you may be confusing GB and MB.

I think I might have

[CheeseBees]

I think you may be confusing GB and MB.

I think I might have

yeah i only have a 4GB card. lol i wouldnt be able to fit 1280x1024 32bpp