OSDev.org

Posted: **Sat May 05, 2007 5:11 am**

Thank you,
Lster

Posted: **Sat May 05, 2007 7:41 am**

Any ideas?

Posted: **Sat May 05, 2007 8:03 am**

Do you get a 1 on the screen?

Posted: **Sat May 05, 2007 8:15 am**

Yeah, 1 is displayed, but _not_ 2.

Thanks,
Lster

Posted: **Sat May 05, 2007 8:30 am**

It's been a long time since I attempted to write a bootloader. Eventually I gave up and used GRUB, but that's by the way...

As far as I can remember, you should enable something called the 'A20 line' in the keyboard controller before enabling protected mode. I could be wrong though.

Good luck,
Senaus

Posted: **Sat May 05, 2007 8:35 am**

Well ds is the segment used to access data. It is used whenever you do an operations such as mov [0xB000], al. SS is the segment used to access the stack. It is used whenever you do a push or a pop. Most OSs just set DS and SS to the same descriptor since they are basically the same type of operation.

Posted: **Sat May 05, 2007 8:39 am**

Oh and here is some code that should enable the A20 line. Should be run before enabling protected mode.

Code: Select all


        xor cx, cx
        
clear_buf:

        ; get input from keyboard status port
        in al, 64h
        
        ; test the buffer full flag
        test al, 02h

        ; loop until buffer is empty
        loopnz clear_buf

        ; keyboard: write to output port
        mov al, 0D1h
        
         ; output command to keyboard
        out 64h, al
        
clear_buf2:

        ; wait 'till buffer is empty again
        in al, 64h
        test al, 02h
        loopnz clear_buf2
        
        ; keyboard: set A20
        mov al, 0dfh

        ; send it to the keyboard controller
        out 60h, al

        ; this is approx. a 25uS delay to wait
        ; for the kb controler to execute our
        ; command.
        mov cx, 14h
wait_kbc:                       
        out 0edh, ax            
        loop wait_kbc

Posted: **Sat May 05, 2007 9:06 am**

Thanks everyone, I really appreciate your help.

@senaus, now added A20 enabling code.

@frank, Im still not 100% sure on ds and ss. What can I set them to? And what does that do?

Ive also added that 'A20-enable' code as the first thing I do; Im still getting errors...

Thank you guys for your time,
Lster

Posted: **Sat May 05, 2007 9:35 am**

If you know anything about SS and DS in real mode then the concept is almost the same except for the addition of a few things, such as protection and a bunch of other useless stuff. Here are some tutorials on that stuff:
http://members.tripod.com/protected_mod ... tmode.html
http://www.osdever.net/tutorials/pm.php

One more question, do you have bochs? If you do then you can use the integrated disassembler and step though your code line by line to see where something goes wrong.

Posted: **Sat May 05, 2007 10:05 am**

A few issues:

1) RBIL says that for INT 13h, AH = 02h, you need to set DL to the drive number. I think you're just relying on the bios clearing it to 0 for you.

2) Its (apparently - I've only just checked) more usual to check CF for error after int 13h. ie you want something like jc reset_drive, instead of testing ah.

3) As you're writing to 0xb8000 in protected mode, this requires ES to be set. Using 010h like for DS should be fine.

Regards,
John.

Posted: **Sat May 05, 2007 1:21 pm**

...

Thankyou all for your great help,
Lster

Posted: **Sat May 05, 2007 1:33 pm**

Lprogster wrote:This is really weird. It seems to work in Bochs but not Qemu (maybe I need to configure it...)... Ill stick with Bochs and Im happy .

Thankyou all for your great help,
Lster

Rather then accepting one works and the other doesn't, It's still a good idea to investigate "why".

QEMU has a built in console if that is at all useful... And an embedded GDB server.

CTRL+ALT+2 will enable the monitor.. And the same key stroke using 1 will bring you back..

http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC12

Posted: **Sun May 06, 2007 11:06 pm**

I've noticed that sometimes QEMU seems to hang in some kind of loop eating 100% CPU when it should triple-fault.
Also I've multiple times managed to produce code which works fine on Bochs (yuck) but will crash (usually triplefault) on a real machine, VMWare and QEMU.

So I'd say that your code triple-faults for some reason and Bochs is too stupid to detect it.

Posted: **Thu May 10, 2007 11:31 am**

Hi - just a quick question:

How many bytes does each instruction take up in 32 bit flat binaries. Does it vary between different instructions? I know how random this must sound - but I really needa' know!

Thanks,
Lster

Posted: **Thu May 10, 2007 11:45 am**

Lprogster wrote:Hi - just a quick question:

How many bytes does each instruction take up in 32 bit flat binaries. Does it vary between different instructions? I know how random this must sound - but I really needa' know!

Thanks,
Lster

On x86, varies between 1 and 15 bytes. That also holds for 16-bit and 64-bit, but the average opcode length would probably scale along with the bitlength a tad.

OSDev.org

Why Doesn't This Work (Boot Sector)

Why Doesn't This Work (Boot Sector)