Damn I feel stupid ... stuck at the Hello World.

[alamme]

Just before I develop anything else, I tried to rip a bootstrap procedure and make a little C++ program that displays "Hello World" or something ...
It's a boot procedure that continues to a kernel file called Kernel.bin ...

When I compile the little program, I use my following batch program (I use DJGPP) ...

gxx -c Kernel.cpp -ffreestanding -fno-builtin -fno-rtti -fno-exceptions
nasmw -oboot.bin boot.asm
ld -Ttext 0x100000 --oformat binary -o Kernel.bin Kernel.o
copy kernel.bin A:
COPYBOOT BOOT.BIN 0
ATTRIB A:\Kernel.bin +S

The booting procedure seems to work fine (I print some values on the screen and it works fine until it reaches the Kernel.bin) ...
Then it seems to hang immediately ...

Is anyone familiar with this problem ???

Thx, Arjen.

[Tim]

Yes, I'm very familiar with the computer hanging or rebooting. It means you've got a bug in your code.

[The Pro from Dover]

No need to feel stupid; we all have problems like this, especially when starting out. It comes with the territory, trust me.

However, some additional information would help us help you.

To begin with, which boot loader are you using (I'm guessing UBL/JOSH or some variant thereof, but I have no idea if that's right or not) - can you provide either the source code, or a a pointer to where you got it from? Also, did you modify it in any way yourself?

Second, are you certain that it will read kernel.bin as a regular file, or does it have to begin in track 0, sector 2 for the loader to read it, the way IO.SYS has to be for MS-DOS to work? Ultimate Boot Loader and its derivatives will load any file named kernel.bin, but most others won't (this was part of why I thought it might be UBL).

Third, are you sure that the bootloader transfers into protected mode before running kernel.bin (UBL doesn't)? The DJGPP gcc compiler only produces 32-bit p-mode code; if the system isn't in p-mode beforehand, your C++ code won't run at all.

Fourth, are you using any standard library calls in the C++ code? The existing libraries for DJGPP are all written to work with the DOS Protected Mode Interface; they won't work in your kernel, as they use system calls specific to DPMI. You will have to write your own I/O code for printing to the console and similar functions.

Can you post the code here? It would help tremendously if we can actually see what we're talking about. HTH.

[alamme]

Thx all for your reactions ... at first I heard of the protected/real mode, but don't know how to switch between these 2 ...

I tried it with and without std-calls in a C++ ... tried it first without and out of pure desperation, I tried with the stdio ...
Also I tried a normal C code just with "Hello World" ...

The bootloader I ripped was from JOSH and I only modified it to debug, but the standard remains finally ...

There isn't any recent "good" source for now ... I think it will help a lot if I just knew how to load/compile the binairy kernel ...

Thx a lot,
Arjen.

[The Pro from Dover]

Thx all for your reactions ... at first I heard of the protected/real mode, but don't know how to switch between these 2 ...

That is a fairly big, and fairly complicated, subject in and of itself, and has been the topic of many discussions on this board. I'd recommend checking out the p-mode tutorials on OSRC, and searching this forum archives for earlier posts on the subject. Several of the books listed in the book thread will also help as well, such The Indispensable PC Hardware Book.

I tried it with and without std-calls in a C++ ... tried it first without and out of pure desperation, I tried with the stdio ...
Also I tried a normal C code just with "Hello World" ...

Unfortunately, this isn't going to work, for the reasons I'd said above; the 'standard library calls' do not mean just the std ('stream-directed') class library, but any functions not part of the core language. All of the 'normal C code' you are likely to have used relies on the library functions - [f|v|vs]printf(), [f]puts(), [f]putc(), and so forth. None of these will work at this stage, as they all use system calls of some sort.

Rather, you will have to write functions to handle I/O yourself - which, in this case, means writing directly to the video text pages. Any other approach, short of dropping back into real mode and calling the BIOS (which would require a fair amount of assembly code), simply cannot work at this stage. Later, when you write the appropriate device drivers, you'll be able to port the standard libraries to your OS - but for now, you don't have even a simple BIOS interrupt at your disposal. Again, this has been discussed extensively in this forum, and a search on the archives should turn up quite a lot of information on how to write a simple print function.

The bootloader I ripped was from JOSH and I only modified it to debug, but the standard remains finally ...

That, at least, tells us something about what we're dealing with. Thank you. The JOSH tutorial is fairly popular and well-understood, which means that there should be few problems in helping you work with the boot loader.

There isn't any recent "good" source for now ... I think it will help a lot if I just knew how to load/compile the binairy kernel ...

Even 'bad' code would be better for us than trying to work blind, actually. Without it, all we can do is second-guess what you have done and where any problems lie.

One last thing: if you haven't already, please read through "How to Ask Questions The Smart Way" and take the advice to heart. A bit more care in posing questions would have saved a fair amount of time for you right off the bat, and avoided the inevitable snide retorts that such a broad posting as your first one will get. After all, Tim did in fact answer you correctly; it wasn't his fault if your question was inadequate. Neither time nor patience are infinite; a little thought when you post will save both for everyone involved. That you didn't know that this was a good idea was simply because of inexperience, and no one will fault you for it so long as you learn from it and to do better in the future.

[Freanan]

I am pretty sure that the problem is, that you did not switch to protected mode!

I highly recommend the following tutorial to get into the switching into protected mode. I think the code is as simple as possible and it is explained for newbies.

http://osdev.neopages.net/tutorials/bru ... ial_02.php

It also includes links to part one and three of this series (above you see part two). So you can find the complete stuff about booting, pmode switching and loading a kernel on this site.

But i found out that the code of part three does not work properly, because gcc needs also enabled a20 line and this bootsector does not enable it -but you can read somewehre how to do it and just fill in this code.
The code to enable a20 you can find somewhere at http://osdev.neopages.net/
You find there also more tutorials about protected mode and its possibilities.

Have fun ; )

[Pype.Clicker]

i confirm freanan's response: since GCC produces 32bits code for a flat protected-mode environment, having the code called from another environment (16bits realmode in your case) will result in nothing but crashes.