Writing to the screen without BIOS
-
- Member
- Posts: 5563
- Joined: Mon Mar 25, 2013 7:01 pm
Re: Writing to the screen without BIOS
How do they contradict? Both of those snippets of code do the same thing.
Re: Writing to the screen without BIOS
As Octocontrabass said, they do the same thing. Note that the first one is clearer, the second one is faster
Re: Writing to the screen without BIOS
They are not exactly the same. The first works for pixels in the (8,8,8) RGB format only, but for arbitrary pixel widths. The 2nd works for 4 bytes-per-pixel only and expects the caller to have already created the pixel value in the appropriate format. If the framebuffer is 4 bytes-per-pixel and the pixel format is (8,8,8) RGB, which is likely, then both examples will have the same effect.
By "(8,8,8) RGB" I mean there are 8 bits each for the red, green, and blue components of each pixel, and they are packed together with blue in the least significant 8 bits, green the next 8 bits and red the following 8 bits.
What you should understand is that both of them are writing to a pixel value to a memory location. They first calculate the correct location (which is offset from the framebuffer base, which is screen in the first example and gop->Mode->FrameBufferBase in the 2nd). The first example stores colour components one byte at a time, whereas the 2nd stores an entire pixel value (a uint32_t value). Despite these differences, if you look at what the code does you will see it is effectively the same in both cases, if the assumptions they make about pixel format hold true.
By "(8,8,8) RGB" I mean there are 8 bits each for the red, green, and blue components of each pixel, and they are packed together with blue in the least significant 8 bits, green the next 8 bits and red the following 8 bits.
What you should understand is that both of them are writing to a pixel value to a memory location. They first calculate the correct location (which is offset from the framebuffer base, which is screen in the first example and gop->Mode->FrameBufferBase in the 2nd). The first example stores colour components one byte at a time, whereas the 2nd stores an entire pixel value (a uint32_t value). Despite these differences, if you look at what the code does you will see it is effectively the same in both cases, if the assumptions they make about pixel format hold true.
- PavelChekov
- Member
- Posts: 113
- Joined: Mon Sep 21, 2020 9:51 am
- Location: Aboard the Enterprise
Re: Writing to the screen without BIOS
Let me rephrase:
I would prefer the latter, because it is faster, and I don't have to figure out those values myself.
HOWEVER
I don't know what dependencies the latter has, so I am nervous to use.
I would prefer the latter, because it is faster, and I don't have to figure out those values myself.
HOWEVER
I don't know what dependencies the latter has, so I am nervous to use.
USS Enterprise NCC-1701,
The Final Frontier,
Space,
The Universe
Live Long And Prosper
Slava Ukraini!
Слава Україні!
The Final Frontier,
Space,
The Universe
Live Long And Prosper
Slava Ukraini!
Слава Україні!
Re: Writing to the screen without BIOS
The one you tagged "former" is likely to be faster. Why do you think the "latter" is faster?PavelCheckov wrote:Let me rephrase:
I would prefer the latter, because it is faster, and I don't have to figure out those values myself.
HOWEVER
I don't know what dependencies the latter has, so I am nervous to use.
(edit: Also what are the values you think you'd need to "figure out" by yourself?)
Also: what do you mean by "dependencies"? Those snippets of code are pretty minimal. They're not calling any library functions. You can check that easily just by reading the code. "The former" uses the GOP, so it needs UEFI headers if copied verbatim, but you could easily replace "gop->Mode->FrameBufferBase" and "gop->Mode->Info->PixelsPerScanLine" with other suitable expressions.
Re: Writing to the screen without BIOS
By second one, I meant what you called the former. The reason why it is faster is because it does one memory access instead of 3.
The other one does a bunch of bit shifting and does 3 memory access, making it slower. In a tutorial, that one is good, as it present a clearer picture as to what it going on. In a real application, the other one is better as it isn't as verbose.
The other one does a bunch of bit shifting and does 3 memory access, making it slower. In a tutorial, that one is good, as it present a clearer picture as to what it going on. In a real application, the other one is better as it isn't as verbose.
- PavelChekov
- Member
- Posts: 113
- Joined: Mon Sep 21, 2020 9:51 am
- Location: Aboard the Enterprise
Re: Writing to the screen without BIOS
What do I need to do to access this GOP struct that is in the second one?
USS Enterprise NCC-1701,
The Final Frontier,
Space,
The Universe
Live Long And Prosper
Slava Ukraini!
Слава Україні!
The Final Frontier,
Space,
The Universe
Live Long And Prosper
Slava Ukraini!
Слава Україні!
-
- Member
- Posts: 5563
- Joined: Mon Mar 25, 2013 7:01 pm
Re: Writing to the screen without BIOS
You don't need that specific structure, it's just an example. What you need is the base address and stride of the framebuffer. Your bootloader can provide that information.
Which bootloader are you using?
Which bootloader are you using?
- PavelChekov
- Member
- Posts: 113
- Joined: Mon Sep 21, 2020 9:51 am
- Location: Aboard the Enterprise
Re: Writing to the screen without BIOS
How would I find the screen resolution and video memory base?
I would eventually (in the far future) like to roll my own, but for now, BOOTBOOT looks like the best choice.
I would eventually (in the far future) like to roll my own, but for now, BOOTBOOT looks like the best choice.
USS Enterprise NCC-1701,
The Final Frontier,
Space,
The Universe
Live Long And Prosper
Slava Ukraini!
Слава Україні!
The Final Frontier,
Space,
The Universe
Live Long And Prosper
Slava Ukraini!
Слава Україні!
Re: Writing to the screen without BIOS
This was answered on the first page of this thread:PavelCheckov wrote:How would I find the screen resolution and video memory base?
-
- Member
- Posts: 5563
- Joined: Mon Mar 25, 2013 7:01 pm
Re: Writing to the screen without BIOS
Your kernel gets that information from your bootloader. Your bootloader gets that information from the firmware.PavelCheckov wrote:How would I find the screen resolution and video memory base?
The information you need is provided in this structure. I believe you need to define a symbol in your linker script so the loader can put that structure where you want it to go.PavelCheckov wrote:I would eventually (in the far future) like to roll my own, but for now, BOOTBOOT looks like the best choice.
- PavelChekov
- Member
- Posts: 113
- Joined: Mon Sep 21, 2020 9:51 am
- Location: Aboard the Enterprise
Re: Writing to the screen without BIOS
I don't want to use PC Screen Font or other dependencies, so how would I implement a font?
USS Enterprise NCC-1701,
The Final Frontier,
Space,
The Universe
Live Long And Prosper
Slava Ukraini!
Слава Україні!
The Final Frontier,
Space,
The Universe
Live Long And Prosper
Slava Ukraini!
Слава Україні!
Re: Writing to the screen without BIOS
That's a low-effort question which requires high-effort answers. How about you start with your own thoughts on the matter, lay out any problems that you can foresee and any possible solutions (even if not complete), outline what background reading you've already done, and ask more specific questions?PavelCheckov wrote:so how would I implement a font?
Last edited by davmac314 on Sat Oct 02, 2021 4:29 pm, edited 1 time in total.
-
- Member
- Posts: 5563
- Joined: Mon Mar 25, 2013 7:01 pm
Re: Writing to the screen without BIOS
The same way as PSF, but using a different file format.PavelCheckov wrote:I don't want to use PC Screen Font or other dependencies, so how would I implement a font?
Re: Writing to the screen without BIOS
If you want an easy way you can use bitmap fonts, and you can use them as well in basic text mode if they are the good size.PavelCheckov wrote:I don't want to use PC Screen Font or other dependencies, so how would I implement a font?