OSDev.org

Ok, allow me to introduce myself. My name is Nelson Carrillo I am 16 years old and I know some basic C/C++ and know some ASM. I began wanting to write an OS because I wanted to try something (to me at the time) I thought was unexplored and never imagined to find such a huge community willing to help people. I have written a BootLoader that enters protected mode, checks your processor (386+) and can print text onto the Screen. I am in need of advice of what my next step should be after this. I am currently developing my OS under Windows XP and compling with NASM while running on VirtualPC to eliminate the need to reboot every few seconds. If anyone can give me some advice it would be greately appreciated.

Regards,
Warrior

Usually once you can write to the screen you progress to writing interrupt support and paging then the scheduler.

Most people use BOCHS to develop their OS in as it has an extensive debug interface and helps track down bugs by dumping registers, the stack, the gdt/idt and tracing instructions.

Forgive me if I am wrong but isnt BOCHS a loader like LILO and if you use BOCHS you cannot load your Operating System independently?

Do you know of any good articles for paging and a scheduler?

Thanks for your help.

Regards,
Warrior

BOCHS is a free x86 emulator.

you are wrong and forgiven.

Bochs has nothing to do with LILO: it's a free, open-source, multiplatform PC emulator. While it has limitations that makes it unsuited for running PowerPoint XP from a linux PC, it perfectly fits the OSdever's need and has verbose and meaningful (once you made sense out of it) error messages compared to products like e.g. VMware ...

@scheduler, see post about linux scheduler in this week's posts.

@paging, look out for virtual memory management in freeBSd (that should be on Bona Fide

I suggest you start with the Wiki, Bonafide is good a source of tutorials and OS Resource Centre can also be a good reference point

(And to repeat what bubach said, BOCHS is an x86/x64 emulator, much better for OS Development than Virtual PC or VMWare due to it's debugging interface)

EDIT: Pype got in just before I posted

Alright thanks. My problem is I dont have a *working* floppy disk. What I was doing was making it into an ISO and mounting it on VirtualPC something I am unsure can be done in BOCHS. I also would like to know how to load other sectors from the ISO since I think I reached the size limitation on my bootloader (NASM wont compile if I have any more line) besides that I was thinking leave it up to the kernel to execute something I perform on boot (processor checking) to maybe shorten the length of my Bootloader .. ?

You can use floppy disk images in BOCHS (you can also use the hardware directly), I'm unsure about ISOs, it may support them.

The bootsector is there usually to merely load the second stage loader which can be any size. What compile error does NASM give? if you've got "times 510-($-$$) db 0" then the error is because you've broken the equation in it by pushing it beyond 510bytes from the start. You counter that by jmping over it:

You use the bootsector to load the bootloader, then that loads the Kernel. You can load the Kernel directly using the bootsector if you want, but the filesystem may get in the way by not allowing you to have more than X sectors of bootsector.

Thanks for shedding some light on that. So with BOCHS built in bootsector, would it load a seperate ASM file I made to be the bootloader which can check the processor type and prepare itself to load the kernel?

Bootsectors aren't built in, the bootsector is sector 0 of the drive, it's loaded by the BIOS.

You would have a second program which is the bootloader that does all that sort of work.
BootSector (Loaded by BIOS) - Finds Bootloader and loads it
Bootloader - Performs all checks and loads the Kernel then creates the desired environment
Kernel - The core of the OS

Bochs emulates /THE ENTIRE COMPUTER/. Not just the CPU or anything, it does what a normal computer would do with each byte in your programs, rips it apart, checks it out, calculates what to do with it and does that with fake registers. Then, it goes on to the next function.

It thus allows you to have a fake entire computer, in which you control /EVERYTHING/, which you can literally stop and put on single-step mode. For assembly-level instructions.


Also, it emulates a floppydrive, a harddisk (if you so desire), a cdrom drive, network card, sound card... loads of stuff you can use, you can enable and you can make the fake computer make pretend even if you don't have any of them. Bochs "creates" them, so you can use them.

Let me start off by saying Thanks alot for all your help. I am now using Bochs after about an hour of screwing around with it (pitiful right ) I got my OS to load off it. Even though something weird happens which cuts off the first line it's all good. Anyways. Now I want to know if It would be better to just straight load the kernel and do the processor checking (if possible) via inline assembly? I guess for that to happen I'd need to know how to load a Kernel. I read the tutorial on writing a C Kernel and understand I need to implement my own printf function among other things since they are OS Dependent. What I dont know is, if I am going to have multiple .c files how am I going to link them all?

For my last question in your guys' opinon what SHOULD be done in the Bootloader and what should be done in the Kernel. I'm hoping to implement a filesystem once I understand them fully as well.

Thanks for all your help!

You compile the C files using GCC, my makefile uses a compilation line something like:

(I overkilled on the "no floating point math" parameters, especially since I don't even use floats or doubles )
I suggest you get a copy of the docs for the command line parameters, I figured them out by just using "gcc --help" and googling the ones that weren't described properly.

Once you've compiled all the files, you link then using LD:

An example linkscript (LinkScript.ld parameter) can be found in BareBones in the Wiki. This will create a complete executable image based on the parameters in the linkscript.

The Bootloader should probably be a combination of 16 and 32 bit code, it'll be responsible for displaying the "which/how boot menu" (if you want one), loading the kernel and any associated files, and creating the desired environment for the kernel (Getting the memory bitmap from the BIOS, protected mode, paging, set video mode, etc) then jumping into the Kernel.

The Kernel initalisation should all revolve around the Kernel's runtime (preparing the scheduler, memory managers, starting the first process, etc). Code that has to configure and prepare the environment [that is only run once at startup] will simply waste RAM after it's no longer needed (unless you devise a way to drop that memory when it's no longer needed)

[NOTE: How or what you do is up to you, I'm only making suggestions based on common practices, you can do it anyway you want]