OSDev.org

I wrote boot loader for floppy, it works, it loads my mini kernel but
it hangs, it should write to screen "This is Thunder OS".
I wrote such code in mini kernel:
begin:   
   mov   ax, cs      ;Get the current segment
   mov   ds, ax      ;The data is in this segment
   add   ax, 0x1000   ;Compute next segment
   push   ax      ;Build return address
   xor   ax, ax
   push   ax
   retf
%macro bios_print 1
mov si, word %1
ploop:
   lodsb
   or al,al
   jz done
   mov ah,0xe
   mov bh, 7
   int 0x10
   jmp ploop
done:
ret
%endmacro

;************************************
; begin of 16 bit
; THUNDER OS KERNEL
;************************************
[org 0x7c00]

msg db 13,10,13,10,13,10,'This is Thunder OS ver 0.01',0
   call begin
   xor ax, ax
   mov ds, ax
   bios_print msg
; start of real kernel
   jmp main

main:


Please write to me !!!

Ok... you bootloader doesn't even work! Look:

1) At 0x7c00 you MUST have an instruction, NOT a message definition!

2) The first sector (the bootloader) MUST end with 0xAA55

3) What's with the "jmp main" if it's located right after?!?!?

Anyway, go read some texts and get some code to look at (see the "baby steps" tutorial on this board).

i also dont know what you are doing with your return address and adding 64kb

i also dont know what you are doing with your return address and adding 64kb

it's usual to copy the bootsector at higher place and then jumping on the copied code when making a MasterBootRecord or something that has to load another bootsector and make that sector believe it has been loaded by the BIOS itself, but i don't see the point here

moreover, there's no copy loop so that jump is just plain silly !

and the msg string is in front of all the code

Thunder: What is the location of the 'begin' label? Is this literally your assembly listing?

If so, then 'begin' is being placed at address 0x7c00 when it is loaded, but Nasm doesn't know that. It thinks begin is at address 0, followed by some code, followed by a huge gap until 0x7c00, where your message is.

You need to miss out everything between the 'begin:' line and the macro. Look at pretty much any boot sector on the net (such as crazybuddha's listings on this very forum) for examples of a working boot sector.

This is code of kernel...

OK, let's start from the top, so that we're all following the same logic here. Line numbers are in hex.

First off, where in physical memory is the origin, that is, what address does the bootstrap load it at, and just what does it load? This could be a crucial point in understanding the following code. Perhaps you should show us the boot loader, too.

At line 01 we start with the label 'begin', which initially appears to be the entry point; a quick look down at line 1E, however, shows that it must be a subroutine of some kind. Proceeding with lines 02-04, the code sets the data segment to overlap the code segment. Then, it pushes a FAR address just past the end of the code segment, into what is, as far as I can tell, uninitialized space, and RETFs to it. Why? Does the bootstrap load two sets of code, one segment length apart from each other, and if so, for what purpose?

Immediately following this is a macro definition (bios_print) that is, well, a bit confusing; if nothing else, it should have been more clearly marked off from the 'begin' code, though that's a stylistic issue. Not to sound overly critical, but there seems to be some confusion between macros and subroutines here, unless there is a reason for the RET opcode that I'm simply missing. Macros don't return; they are inserted into the code stream directly before assembling. This probably ought to have been defined as a subroutine, possibly with a macro wrapper to simplify the passing of arguments. Again, this is a matter of style, and you may prefer it as written for all I know.

At line 1D, we come to an ORG statement, which is itself something of an oddity at this point in the code. It sets the code offset to 0x7C00, which is the entry point for the boot loader; at this stage, I'm very puzzled at this, as it seems to imply that the boot loader overwrote itself, perhaps. More likely, this is a mistake or confusion of some kind.

Odder still, at what seems to be meant as the 'real' start of the code, is a define byte for a banner string, zero terminated. This is utterly inexplicable, so far as I can tell; the processor will go wierd trying to interpret this as code. Unless there is something missing which jumps past the banner (but where? There are no labels beyond it, except one at the very end, leading nowhere!), this alone will cause the kernel to fail.

Remember, a define byte is exactly that: it defines the value of a byte or series of bytes. The processor, however, has no way of knowing if a given byte in memory is meant to be code or data, and will happily try to run your message banner, interpreting it as who-knows-what (well, actually, you could determine what the byte values would be as opcodes, but it would be a rather tedious and pointless excercise). Similarly )apropos the 'begin' routine), if you define a subroutine before your code entry, it will in fact be assembled at that point, not rearranged to fit your design. All the org statement does is set the address counter to the new point for the code following it; it has no effect on where the entry point is (and even if it did, the boot loader would not have any way of determining where it is; all it knows is where it loaded the code into).

At line 20 we have what I assume is supposed to be the real entry point of the code, though how the boot loader will find it is anyone's guess. It immediately calls 'begin' which, as we already established, jumps into hyperspace and never returns.

At 21-22, the data segment gets reset again, this time to the address base, 0x0000. It then does nothing with it, but instead runs the bios_print macro code. after this, it jumps to label 'main', which is followed by... nothing. Clearly it's meant to be something in the future, but for now, it doesn't even HLT or 'JMP SHORT main'. Given that the memory following this could contain *anything* this may not be very wise.

In conclusion, there's definitely some bugs in this test kernel (ahem), but frankly it's still better than most beginners (including myself) did the first try.

If I misunderstood anything, please correct me. I'm only human myself, after all.

Thanks for long explanation...i'll try to correct my mini kernel