OSDev.org

I strongly believe that's the reason for the BIOS freeze.

Another thing: Would you mind telling the repository link? Or don't you have the code online?

I agree this is a better place than Stackoverflow to ask this kind of question, I'm going to give you a piece of advice I wanted to share in a comment on SO but never did. Often problems people have are often not directly related to the code they post. Switching in and out of protected mode and not getting it right could cause issues. Maybe you aren't reading enough sectors of your kernel. Maybe something is not initialized properly. Maybe you have used undefined behaviour. Maybe an optimization bug. Maybe a problem in how you build the project.

What would really help is if you posted your complete project on something like GitHub including build scripts makes files and everything else to build your kernel and allow people to see everything.

Debugging on real equipment can be a real pain. Back in the day using In Circuit Emulators for debugging were very powerful and useful. If you don't have an in circuit emulator you may wish to consider investing time into adding a gdb stub into your kernel. You can then debug over a serial port.

I did this:

But nothing

But how come that the code works on one hardware but not the other?
Regarding sectors, I only need one.

One more thing, the working hardware is where I actually compiled/assembled the code. So far it haven't worked on the 2 other (older) systems.

EDIT: I found something. I am more confused now.

I can actually call some BIOS routines! I used 10h to reset video mode and used my own 16-bit subroutine to that prints strings using 10h and it all worked! Right until int 0x13!
Then I tried to reset disk using int 13h. But no even that didn't happen.
my modified code:


If real mode has problem, how am I able to call a function from the boot loader to print a string but not even reset the disk system?!

The INT 0x10 routines tend to be very self-contained for a variety of reasons, so they're less likely to break if you fail to restore all of the things you've changed before you switch back to real mode.

Do you manipulate any hardware while you're in protected mode?

hardware? I have drivers accessing keyboard, display is memory mapped so no problems there, but I use a small function to disable cursor, I also use rtc to get time. That's it I guess.
edit: my kernel is compiled in C, and I have only written specific functions in assembly to assist kernel. Does the code generated by compiler change hardware in some way?

Does your keyboard driver use interrupts? Do you configure the interrupt controller at all?

No no, My keyboard driver is polling based. I can't use interrupts as I need bios interrupts later, right? So I disabled interrupts in protected mode.(re-nabled it in this subroutine in real mode)

Your keyboard driver must generate a lot of heat.

Do you change the IDT at all?

No. But that does mean the BIOS routines should work, right?

I'm planning to set up interrupts later. By the way, but would you suggest an easy method for USB (HDD emulation, I think) driver to read my drive?

Only if you haven't made a mistake somewhere else. It's best to load all of your data before you switch to protected mode so you don't need to worry about running BIOS routines.


Emulation is only available for INT 0x13. You need proper USB drivers to use USB without the BIOS.

I did, and my kernel is working. The problem arises when I try to load files from my "filesystem". This is when I check for the existence of a filesystem in my drive, or if I disable it(then it lands into kernel successfully)if I try to load a file or filelist. And the problem is not there on my laptop which I use as daily driver.

So that means I'm stuck with int 0x13. I am using a USB and I tried to look up how USB drives work, and understood nothing(Please explain if easy).

Yes, this is the exact same thing I read.
what about my current setup? It actually works on my current hardware, so it almost usable.