OSDev.org

HEY OS DEVERS!

I have been working on an OS called UNICORN OS.

My problem is: Interrupt 0x13...
We all know that this code will move one sector from 0x7c00 to disk 0 (Floppy - A), CHS=0,0,2, right?
When i look at the disk in a hex editor, sector 1 and two SHOULD be the same. They're not.

Interpreter is tested and working.
The jump to "start"-label works.

What happens is:
My OS boot, and my command line is showing as expected.
I type in "cmd2", and press enter. This makes the program jump to cmd0104.
The floppy drive motor turns on, and then strange things begin to happen.
At the upper left corner of the screen it prints a few symbols in various colors.
The machine goes into a hang, and i can't even ctrl+alt+del it to a reset.

The strange thing is: I used int 0x13 in the bootloader, and it works there.

What is wrong here?
Thanks in advance!

You're missing out on loading ES.

The bootloader sets all segment registers to 0x0000, since i'm creating a VERY VERY simple OS, not using segmentation.

I tried setting es to 0x0000 just before the rest of the code for int 0x13, just to be SURE that it was zeroed. It still generates the error described before.

you don't want to run your code in segment 0x0000. you're probably overwriting entries in the interrupt vector table, making the CPU jump to erroneous locations in RAM when interrupts are triggered, causing essentially a lockup. you're probably also overwriting values in the BIOS data area. try having the bootloader load your kernel into segment 0x100. make sure all of the segment regs (ES, DS and SS) are then set to 0x100. then far jump to 100:0000h (or modify the offset to wherever your entry point is if not 0) hex code for the far jump: EA 00 00 00 01 .... alternatively, you could push 0x100 and 0x0, in that order. then retf.

oh, and set your SP to 0xFFFE.

you don't want to run your code in segment 0x0000

His segment is fine. ES=0, 0:0x7c00 is the same as 0x7c0:0 where the bootloader is. Although, both cases assume ORG is 0. If not, that could be the issue.

Does the sector ever get modified? If not, the INT call might be failing (I dont see any error checking in your code.) What you describe sounds like a memory corruption issue. Posting a bochs crash log might help provide more information.

yeah, but i was assuming his kernel wasn't built into the bootsector. is it? because then yeah, as long as all the code as above that point it should be fine of course. and as long as he isn't trying to use the IVT or BDA for data storage or scratch RAM or something.

My org is 0x8000 for system code, and 0x7c00 for the bootloader.

But since you mention it: i think it is the SP!
When i push something, does it then count UP?

In case not, i know where the error is. My SP os set to 0x0000, since i assumed it would grow DOWNWARDS in memory!
Oh dear i have failed then?

I have been very careful not to overwrite BIOS memory. Therefore my os does not use 0x0000 to 0x0fff... i thought!


Since i'm unable to test that right now (school), i just need to know: In what direction does the stack grow?

danielbj wrote:My SP os set to 0x0000, since i assumed it would grow DOWNWARDS in memory!

You shouldn't assume, but in this case you are right. On the x86 family of processors the stack grows downwards. Initializing it to 0x0000 is fine as long as 0xfffe and below are free.

I have mapped 0xfc00-0xffff to be stack memory, and all memory from 0xf400-0xfbff is not used.
But:

I remember when i debug, i have written a function to print all registers. Everytime SP was shown to be something like 0x00DC or 0x0048... Why so low? Shouldn't it be like 0xFFDE or such, if it grows downwards?

So somewhere SP is messed up. Trace your code to see where it happens.

I think you're right!

I found out that i did NOT reset SP in the bootloader!
Any other registers to reset?
What happens if i do not reset CS, SS, and DS?
I'm not using segmentation at all in my code, but does any instruction do that automaticly?

Segmentation is always used. You can only hide it by loading defaults in all registers and ignoring them from there on.

Daniel, the answers to your questions are all in the Intel manuals. You may start with the Intel 80386 Programmer's Reference Manual because it is not as huge as later versions, and most of its content still counts for modern processors.

I tried resetting SP at boot, and it works now!

Thank you all!
And thanks for the manual!