Bochs confuzion

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
Mr.Confuzed
Posts: 20
Joined: Fri Nov 24, 2006 10:55 pm
Location: C eh, N eh, D eh

Bochs confuzion

Post by Mr.Confuzed »

Hey y'all,

I'm having troubles with my OS coding. Can anyone help? See my user page for details and source code. If you want to copy the code for testing, opening it in edit mode might be easier.

[wiki]User:Mr.Confuzed[/wiki]
Crazed123
Member
Member
Posts: 248
Joined: Thu Oct 21, 2004 11:00 pm

Post by Crazed123 »

The most common reason for code to work in Bochs but not on real metal is the code relying on uninitialized memory equalling 0.
User avatar
AJ
Member
Member
Posts: 2646
Joined: Sun Oct 22, 2006 7:01 am
Location: Devon, UK
Contact:

Post by AJ »

That's the reason it tends not to work on real hardware for me too. The other possibility is not delaying long enough for a piece of hardware to finish doing its stuff (for example when setting the A20 line, pummeling the controller with data, without checking if the keyboard controller is ready...)

Cheers,
Adam
User avatar
os64dev
Member
Member
Posts: 553
Joined: Sat Jan 27, 2007 3:21 pm
Location: Best, Netherlands

Post by os64dev »

1) on a first glance you definatly forgot to enable address line A20 before jumping to protected mode.

2) further more when loading the rest of the sector register ch is in an undefined state so maybe mov cx, 0x02 works better then mov cl, 0x02.

3) also you use dx to initialise segment by clearing dx you loose the bootdrive information which is located in dl. thus this code can only work for floppy.

4) switching to protected mode without disabling interrupt is a real killer if you don't have an IDT.

i didn't look any further in the code.. because the above described errors are already fatal for execution. Be thourough when it comes to writing assembly and test with small increments.

regards
Author of COBOS
Mr.Confuzed
Posts: 20
Joined: Fri Nov 24, 2006 10:55 pm
Location: C eh, N eh, D eh

Post by Mr.Confuzed »

I don't think I'm using any uninitialized memory.

os64dev:
1) I didn't forget to enable A20. I just haven't got around to it yet, as it will take me a while before I need to go above the 1MB barrier.
2) This could be the problem. I'll try it when I get home. Looks like I was optimizing my code and forgot about ch being dirty.
3)The code is only supposed to work for a floppy. Are you telling me that bioses provide the bootdrive in dl before they transfer control to the OS? I thought I was supposed to assume every register is dirty on boot.
4)True, I don't have a working IDT yet, but I did disable interrupts.

Thanks
User avatar
os64dev
Member
Member
Posts: 553
Joined: Sat Jan 27, 2007 3:21 pm
Location: Best, Netherlands

Post by os64dev »

indeed register dl contains the bootdrive information, which is as far as i know the only register with a defined state after the bios has booted.

the most-significant-bit depicts whether it is a hard-disk or not so the ranges 00h-7Fh are for floppy drives and 80h-FFh for harddisk. Note that booting from an usb-stick will use the same ranges depending on the emulation mode(floppy or harddisk), if your bios supports booting from usb-drives that is.

personally i use usb-drive booting because it is way faster then a floppy-drive though you need to load everything up front, because once you've booted to protected mode, or long mode in my case, you need an usb driver.

regards
Author of COBOS
Mr.Confuzed
Posts: 20
Joined: Fri Nov 24, 2006 10:55 pm
Location: C eh, N eh, D eh

Post by Mr.Confuzed »

:( Using cx didn't solve anything. If there aren't any more suggestions, I'll try interpreting some code from Nanos.
User avatar
os64dev
Member
Member
Posts: 553
Joined: Sat Jan 27, 2007 3:21 pm
Location: Best, Netherlands

Post by os64dev »

do small steps. place some loops(jmp $ in nasm) and print some characters to the screen. This helps in pin pointing the exact location where it fails.

Did you test is with bochs? if so what is the output. If you can, compile bochs with internal debugger support. This helps a lot because you can set breakpoints and more....

something that i just saw. the first statement is cli. yet later on you use int 13 to read from disk and int 10 for setting the screen. seems a little weird calling interrupts with interrupts enabled. Use the follwoing rules:
1) disable interrupts when initialising the stackpointer enable the afterwards.
2) Do all the bios stuff you need to do...
3) Disable interrupts, setup protected mode and .....

You will get it eventually took me 3 days to write my universal bootloader, by universal i mean that it boots from different media, as told before.

regards
Author of COBOS
Mr.Confuzed
Posts: 20
Joined: Fri Nov 24, 2006 10:55 pm
Location: C eh, N eh, D eh

Post by Mr.Confuzed »

:D SWEET! :D

Yeah, that means it works now, finally.

Thanks for the help! I had already placed some infinite loops but I guess it wasn't early enough in the code. You're suggestion got me to find it. As it turns out, your earlier suggestion was correct. Apparently, it is mandatory to enable the A20 line before jumping into protected mode. I stole the code from Nanos; I hope he doesn't mind. You see, the problem was that the computer did everything that it was supposed to, followed promptly by a reboot. I thought that it would have crashed instantly, but I guess not.

Yup, I've been testing with Bochs, which doesn't have this problem. That's probably why I got so far with pmode before realizing that it didn't work. The output is exactly as it should be: A message saying, "Protected mode successful," and a very distinct and useless virtual keyboard interface. I've heard a little bit about debugging in Bochs. It sounds useful. Is it true that you need another copy of Bochs just for debugging?

I'm pretty sure that you can call BIOS interrupts with interrupts disabled, because you are calling it manually. I think cli only disables hardware interrupts. I'm following your suggestion anyway for now.

Well, I'm glad it's up. Now I can do something fun with it.
User avatar
os64dev
Member
Member
Posts: 553
Joined: Sat Jan 27, 2007 3:21 pm
Location: Best, Netherlands

Post by os64dev »

enabling the debugger in bochs requires you to compile the source tree. The main advantage of compiling your own bochs is that you can tailor it to your specific needs by using the configure method. I suggest you look at the bochs site how to do this or google of course.

the cli stuff i mention i found out by trying. my bootsectors wouldn't load with interrupts disabled and worked fine with interrupts enabled. It might differ between bioses but i can imaging that drive access uses hardware interrupts for reading and writing, though i could be wrong..

at least congrats in getting it working and don't worry about the stolen a20 code, it problably the most copied piece of code. i use the code below which is rather small and works perfectly on the machines i have.

Code: Select all

.code16
a20_enable:
    inb         $0x64, %al
    testb       $0x02, %al              //- wait for the keyboard controller.
    jnz         a20_enable
    movb        $0xDF, %al              //- Undocumented PC (AT+)
    outb        %al, $0x64              //- enable a20.
    ret;
regards
Author of COBOS
Post Reply