CLI effect on video memory?

[montrom]

Thanks to Hobbes, that isn't necessary. But, I will tell you that I believe you have already received your answer in this thread. In terms of those threads, I believe they will help you with your approach. Which is what I was trying to do. And, you are calling a BIOS interrupt. Good luck.

[JamesM]

Hi,

I must say that I'm not a real-mode ASM programmer before I try and answer your question.

I'm not calling any BIOS interrupts in this code.

Yes you are.

Code: Select all

;Set video mode to mode 3
mov ah, 0x03
mov al, 0x00
int 0x10

That aside, do you know how the BIOS handles interrupts? Enabling interrupts (removing the CLI - I don't know if the BIOS leaves you with IF set or unset) will cause IRQs such as the timer, keyboard and spurious interrupts to hit the system.

How does the BIOS handle these? AFAIK the BIOS is generally polling - it doesn't usually use interrupts. Given that you haven't set up vectors in the IVT for the timer, keyboard (you get mouse interrupts too) I'd think it most likely that it's receiving an interrupt and jumping to some random location, never to return to your code.

You can test this by running qemu with the "-d int" option, that will post to /var/log/qemu.log (or /etc/qemu.log) all interrupts that are received, and IRETs that occur.

James

[alphomega]

Ok I meant the part of the code that was in question. Ty for the mention though. I'll just take that bit out because the same problem occured when it was commented out.

[gerryg400]

So, I'm curious. Why does adding cli stop his code from working ?

[alphomega]

So, I'm curious. Why does adding cli stop his code from working ?

Same.

James, I don't quite understand what you meant. It's when the CLI is there that causes the "A" to not get printed.

[falstart]

When I copied your code from the original post and ran it in bochs and qemu, with and without cli, it worked exactly as it should. The problem might be in assembly or testing using an emulator. What commands are you using to assemble and run it?

[Brendan]

Hi,

That aside, do you know how the BIOS handles interrupts? Enabling interrupts (removing the CLI - I don't know if the BIOS leaves you with IF set or unset) will cause IRQs such as the timer, keyboard and spurious interrupts to hit the system.

Normally the BIOS leaves interrupt enabled; and does have IRQ handlers for all the devices it uses. This also means that (potentially) an IRQ can occur immediately after the BIOS jumps to the bootloader but immediately before the bootloader's first instruction is executed; which further implies that the BIOS must setup a default stack that is large enough for it's own IRQ hander/s to use.

It is possible for the BIOS's default stack to be anywhere, and if the boot loader used any memory (other than the 512 bytes at 0x007C00) then it would be possible for the memory the boot loader uses to overwrite the BIOS's stack. This is why it's important to setup your own stack before using any memory (other than the 512 bytes at 0x007C00).

None of this explains alphomega's problem - no IVT is needed because the BIOS provides it's own, and no stack is needed because the BIOS's stack can't be overwritten.

So, I'm curious. Why does adding cli stop his code from working ?

The only explanation I can think of, is:

Maybe if interrupts are disabled his emulator doesn't get a chance the redraw the screen. Should be okay on real hardware.

I know that for Bochs, if it reaches "jmp $" with interrupts disabled it'll stop executing instructions; and because it uses the instruction counter to decide when to refresh the video it'll never refresh the video. Other emulators might have similar issues.

A good way to fix it (or to find out if this actually is the problem) is to enable interrupts and then do "hlt" in a loop. This reduces power consumption on real computers, allows the user to "control+alt+delete", and also prevents the "no screen update" problem on (some) emulators.


Cheers,

Brendan

[alphomega]

Thanks for the post, Brendan. But I'm still a bit confused about the halt thing... I put this at the end of my code instead of what I had. when i added and removed the cli, the program performed as it did previously.

Code: Select all

halt: hlt

JMP halt       ;Infinite loop, hang it here.

when i added and removed the cli, the program performed as it did previously

[Nugget]

Interesting... The Babystep tutorial does:

hang:
jmp hang

all over the place. Might this want updating in light of what Brendan is saying?

[gerryg400]

You need to sti (or at least NOT cli) before HLT.

Code: Select all

    sti  // may not be necessary because bios may enable interrupts already
HALT:
    hlt
    jmp HALT

This is a bochs/qemu issue. You mustn't jmp $ or halt with interrupts disabled or the screen will freeze.

[montrom]

Look at that, I was right: http://forum.osdev.org/viewtopic.php?f=1&t=22051

See if you would have listened to me, you would have noticed that in one of those 5 or so threads I mentioned, Combuster said almost exactly the same thing as Brendan and you wouldn't have forced anyone to repeat information that could have been easily found on the first page in one of the threads I told you to look at. I don't know why I even bother. pfft.

[gerryg400]

I don't know why I even bother. pfft

Actually Montrom you didn't bother. It was other people in both cases who answered the question.

In the other thread we suggested that the poster do a CLI before halting to prevent interrupts from waking the processor from the HLT. In this thread we're suggesting an STI so that the screen can refresh. It's very clear now that in the other thread we gave an incomplete answer.

Seems kinds strange to me. That's precisely why I followed this thread.

[alphomega]

You need to sti (or at least NOT cli) before HLT.

Code: Select all

    sti  // may not be necessary because bios may enable interrupts already
HALT:
    hlt
    jmp HALT

This is a bochs/qemu issue. You mustn't jmp $ or halt with interrupts disabled or the screen will freeze.

Got it. I think this problem is fixed now, thanks a ton for the help, guys.