CLI effect on video memory?

[alphomega]

In light of http://forum.osdev.org/viewtopic.php?f=1&t=22069, I've decided to write my own bootloader.

I've been able to set the video mode to 3 (although qemu already sets it to 3 already), and then print 'A' at the first character of the first line on the screen by directly changing video memory.

Code: Select all

[org 0x7C00] ;Address BIOS loads the bootloader into
[bits 16]

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

mov ax, 0xB800
mov es, ax
mov bx, 0
mov [es:bx], byte 65
mov [es:bx+1], byte 0x0F

;cli

JMP $ 		;Infinite loop, hang it here.

times 510 - ($ - $$) db 0	;Fill the rest of sector with 0
dw 0xAA55			;Add boot signature at the end of bootloader

Note the commented out cli instruction. When I remove the semicolon and only the semicolon, the 'A' is no longer printed. I don't understand how clearing the IF flag can have the sideeffect of affecting what's in memory. If someone could shed some light on this that'd be great.

Oh and for what it's worth, the commands I use to run the bootloader

Code: Select all

nasm -o bl.bin bl.asm
qemu -fda bl.bin

[qw]

This is odd. Did you try real hardware or other emulators?

[montrom]

• Why are so many people writing their own boot loaders all of a sudden?
• Why does it seem like they are all making the same mistake?
• Why haven't you fixed up the stack?
• Who or what is guiding you?
• Do you belong to a summer course teaching OS Development?
• Are these other members in your class?

I'm sorry. All these boot loader questions are becoming repetitive to me. Your answer is in another thread. Do a search, please.

[qw]

Montrom,
Yes, the OP did not set up a stack, which is stupid of him, but it doesn't explain the issue.

[gerryg400]

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

[alphomega]

I looked and did a search but couldn't find threads where people had the same problem.

Would you be able to paste a link here?

I'm not quite sure about the relevance of the stack, could you enlighten me?

Oh and to hobbes, I don't have a floppy disk drive so I couldn't test it on my computer.

[montrom]

Hi, I think that if you reviewed any of the 5 or so most recent threads about boot loader issues, you would find something in them that may solve your issue. Your code is a mess. I was wondering what guides you are following. Guides that don't set up the stack.

Why are you writing directly to video memory in 16 bit real mode? Why are you turning interrupts off? Why are you doing this : mov [es:bx+1], byte 0x0F, is the size required? I don't think it is. It may be more like: mov byte[es:bx+1], 0x0F, but if it assembles, then whatever.

And, do try to find an external floppy drive. It is absolutely imperative that you begin testing on real hardware.

[alphomega]

I looked at literally every thread in the first page of the forum, specifically the ones regarding bootloaders.

I don't see how my code is a "mess"... there basically isn't any code there.

As for guides, mainly stuff from http://wiki.osdev.org/Main_Page:
http://wiki.osdev.org/Rolling_Your_Own_Bootloader
http://linuxgazette.net/issue77/krishnakumar.html
http://hem.passagen.se/danma/nboot.htm
http://wiki.osdev.org/Boot_sequence
http://wiki.osdev.org/Printing_to_Screen

None of them really mention a stack and if they do, they don't really explain its relevance to what I'm doing.
And various other guides on osdev.org and just stuff I've found through google.

I'm writing to video memory because I'm experimenting and trying to learn a bit more. Because I figure I'm going to be going into protected mode soon I figured I might as well see how I can print stuff when I have to ditch the bios interrupts. I also am trying to figure out what was going wrong in the thread linked at the start of the OP.

as far as mov [es:bx+1], byte 0x0F, I got errors when I didn't specify the size

[qw]

None of them really mention a stack and if they do, they don't really explain its relevance to what I'm doing.

Knowing the relevance of a stack is a prerequisite. Your code does so little that it can run with the stack that was initially set up by the BIOS, but you can't really rely on it.

[montrom]

Aren't you trying to load a C kernel, eventually? Why would you practice in ASM then, in 16 bit real mode where you have the BIOS? lol

That's silly. Anyway, can you post that link to the NASM manual saying that, because that doesn't make any sense. I think it makes more sense for the syntax to be like: mov <size>[value], value. Since the size of 0x0F is already obvious.

[qw]

Montrom,
NASM accepts both "mov byte [foo], bar" and "mov [foo], byte bar". I prefer the first, but I don't see anything wrong with the latter. I fail to see why the size of 0x0f is obvious. NASM doesn't count the figures in a number.

[alphomega]

That's silly. Anyway, can you post that link to the NASM manual saying that, because that doesn't make any sense. I think it makes more sense for the syntax to be like: mov <size>[value], value. Since the size of 0x0F is already obvious.

Sure, if you could reciprocate by giving me a link to the thread that answers my question?

[Nugget]

When calling INT 0x10, shouldn't AH=0 and AL=3?

[alphomega]

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

[Nugget]

What's this then?

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