Weird text mode cursor bug (only happends on real hardware)

[DeezRamChips]

Hi

After trying my OS on real hardware for the first time, I discovered a weird bug with the cursor:
Its x position is offset by 3 characters

So, naturaly, disabled everything that happens on boot and started to re-enabling them
one after another and narrowed down the problem the function that enables the cursor:

Code: Select all

void Terminal_Class::showCursor(uint8_t thickness) {

    outb(0x3D4, 0x09);
    uint8_t end = inb(0x3D5) & 0b00011111; // Get the max scanline
    uint8_t start = end - thickness;

    outb(0x3D4, 0x0A);
	outb(0x3D5, (inb(0x3D5) & 0xC0) | start);
	outb(0x3D4, 0x0B);
	outb(0x3D5, (inb(0x3E0) & 0xE0) | end);
}

However, I can't find any problem with it

Here is how it looks like in BOCHS (what is should look like):


And how it looks on real hardware:


Do anyone know what's happening ?

[pragmatic]

You do not provide any information on how it behaves beyond that you start with a few character offset. What happens when you write more characters? Is the behavior exactly identical to the emulator save for the initial offset?

[DeezRamChips]

You do not provide any information on how it behaves beyond that you start with a few character offset. What happens when you write more characters? Is the behavior exactly identical to the emulator save for the initial offset?

The behavior is exactly identical to the emulator, it just has a 3 character offset no matter what position I set the cursor to or write a character :/

Also, the fact that the cursor looks yellow on the real hardware is normal since when I clear the screen, the whole screen is filled with a blakc background and yellow forground
so since the cursor isn't where it's supposed to be, when I chage the forground of the next character so that the cursor is the same color as the text, it doesn't affect it.

[linuxyne]

The outb sequence in the showCursor function is attempting to set the new scan line values in the cursor_start and the cursor_end registers while preserving the other bits in those registers.

In that case, isn't inb(0x3e0) a typo? Should it not be inb(0x3d5)?

Code: Select all

outb(0x3D4, 0x0A);
outb(0x3D5, (inb(0x3D5) & 0xC0) | start);
outb(0x3D4, 0x0B);
outb(0x3D5, (inb(0x3E0) & 0xE0) | end);  // < - - - - - - -

The 0xe0 mask preserves bits 7-5 of the inb(0x3e0) return value. If it so happens that bits 6-5 are non-zero, the above code sets the cursor_skew field in the cursor_end register to non-zero, which might create problems when the cursor is displayed.

It is likely that the actual skew field is zero, but then we are not reading the correct register.

It is likely that on an emulator, reading 0x3e0 returns zeroes at bit positions 7-5, and so the code works there.

It may be that the original author of the code meant to write inb(0x3d5), but since the very next act is to mask it with 0xe0, the mind skipped ahead a bit and wrote 0x3e0.

[DeezRamChips]

YES ! Thanks you soo much !

I also thoght this was a bit weird but since I worked, I still used it.

Now, it works perfectly !