OSDev.org

Hey, everyone I've just finished implementing a puts() method and I'm having a bit of trouble.
When I run my OS in QEMU or VirtualBox everything works as expected

BUT!
When I run my OS on real hardware the text is a bit off(most of the time)...
I've tested it on my laptop,my PC and my PC at school.
On the laptop it looked like fine, but on the PCs the text is bit cut-off to the left.
Is it because of GRUB? Or is it a common thing?

To the left? Huh, can you try to explain better? (take a photo if possible?)

Also consider putting text in the rightmost columns for testing it just in case.

Yeah, the text starts outside the screen, if you can understand.
When I tested it on my PC I thought it was because of my screen settings so I pressed Auto but it didn't fix anything.
As far as the picture goes that would be kinda difficult since I don't have a phone :/ (I broke my phone a week ago)

Hi,

zvoncika wrote:Is it because of GRUB? Or is it a common thing?

It's not common, and I doubt that it's because of GRUB.

Does the same happen for the firmware's boot screen, GRUB's menu, or any other OS?

Does manually adjusting the display (e.g. using the "H position" or "H offset" or whatever your monitor calls it) "fix" the problem (cancel out the symptoms of the problem)?


Cheers,

Brendan

What kind of display is it? Is it a CRT or LCD?

Maybe you are using some weird resolution/timing and the CRT doesn't like it.

Hello!

I've had the same issue in the past with my (older) monitor as well. My text was bleeding off the screen in VGA mode 03h.
Just take a look at the settings of the monitor itself to make sure you're adjusted to the proper Horiz & Vertical offsets, as Brendan suggested. It's an easy fix, but it's easily overlooked as well if you get paranoid about bugs like I do!

All the Best! I like the name!
-human

Hey everyone,
Yeah manually fixing the offset works

Hi,

zvoncika wrote:Hey everyone,
Yeah manually fixing the offset works

Does it fix the problem (e.g. your code and the video mode timing signals were correct and the monitor was dodgy), or does it hide symptoms (e.g. your code and/or the video mode timing signals are dodgy and you only worked around a problem that still needs to be fixed properly)?


Cheers,

Brendan

Timings in text mode are pretty much hardwired with only a few possible combinations (unlike graphics mode which can easily be anything goes). I'd say the issue was the monitor having been miscalibrated (probably specifically regarding 720×400, which is normally used only in text mode).

Of course would be nice to know if the firmware was affected... assuming it ever goes into text mode (e.g. the laptop I use seems to never go to text mode during the firmware, while GRUB and Ubuntu switch to a higher resolution graphics mode to display the terminal).

zvoncika wrote:I pressed Auto but it didn't fix anything

That's most likely because your monitor can't tell the difference between the borders around the active video and the black portions of the active video. More of the screen has to be light for it to work. It may also have trouble telling the difference between 720x400 and 640x400, since the timings for both modes are identical.

Try filling more of the screen with colors that are not black. Mess up the calibration and then press "auto" and you'll see the monitor has no trouble centering the picture once it's light enough.

If your test hardware has a digital output, you could use that instead. You won't have to calibrate a monitor with a digital connection.