OSDev.org

hi...
i'm a very new to kernel dev so please pardon my ignorance
So far i've build up a kernel which is an asm file (calls the k_main() here) and a C file linked together to form the "kernel.bin"

I'm using a bootloader BOOT02....which doesn't enable A20...moreover if i try to use intrupts my PC reboots...why?how do i switch to real and protected mode...i thought protected mode would be a good thing!..but then i read somewhere it can't handle BIOS inturpts

i use nasmw and gcc

wel how do i enable A20?

my kernel so far can print chars on the screen so the next step as you would u think is to read keyboard inputs

i tried using ints (int 16th..) but that just crashes my PC...

now i'am totally confused as what exactly is and the need of GDT and intrupt table!..please try to help or provide helpful links....


is there a source code available for keyboard inputs which uses inport() and outport()...to read the keyboard input?

well if using another bootloader would solve the problem can u tell me which ones are good...
all i want is my kernel to be loaded from a floppy drive
the bootloader should set up the FAT file system
enable A20
and wouldn't make my PC crash when i use interupts!


please help if u can

You really want to get the Intel manuals if you haven't already http://developer.intel.com/design/penti ... m#sdm_vol1

The BIOS provides a real mode IDT so it's safe to leave interrupts on most of the time before you go to PMode. When you go into PMode, if you haven't provided a protected mode version of the IDT, interrupts will reboot you computer if they are turned on or called.

As far as using other boot loaders go most people will recommend using GRUB and learning how to write a GRUB Mulitiboot kernel image. Personally I think learning how to write a boot loader is the best place to start for beginning OS developers. Here's an example FAT12 boot sector of mine http://www.osdev.org/f12boot.asm .

If you are trying to call a BIOS int while you're in PMode that's not going to work. You have two options really(neither removes the requirement of you setting up a PMode IDT), the first option is to learn the protocol of the hardware and directly access it and the other approach is to either switch back to real mode or use a virtual86 task to run a BIOS int.

The order of development that I like is:

FAT12 Boot sector(Hello World boot sector)
FAT12 Boot sector which loads and runs a file in real mode (extend Hello World)
FAT12 BS + extended boot loader that starts PMode (PMode Hello World)

After that you have loads of directions you can take, it all depends on if you find a certain piece of hardware the most interesting or maybe PMode memory paging, it's up to you. It'd probably be good to setup a PMode exception handler pretty early on.

aryan_illusion,
You have to make a hard decision.. real mode and protected mode have their own pros and cons:

Real Mode Pros:

• All BIOS interrupts and codes can be used easily.
• Code runs faster and takes less space to write.
• You can set up an interrupt handler by just changing two values.
• You don't have to be referencing and making different tables.
• You don't really have to be worrying about how programs access the memory.
• Unless you use some new commands, like pushing number instead of a register, your OS will work in any x86 computer.. even the 8086.

Real Mode Cons:

• You only get 1 MB in total to fit the BIOS ROM, the video memory,
• your code and other programs your code is running.
• One can easily make a hacking program that skrews with the OS's memory, or other program's memory. It can also do other bad things, like cli, and talk with ports.

Protected Mode Pros:

• You get up to 4 GB of memory.
• The OS has more control over anything programs can do. It can stop programs from executing cli, and other instructions.
• Hacker programs can't skrew with anything. They can only access their own little memory place, and that is it.
• Better multi-tasking control.
• If you really want to, you can enable 32-bit support (I try not using 32-bit very much as I try to keep my OS as small as possible.)

Protected Mode Cons:

• A whole bunch of speed lost because of the constant checks that programs don't do anything bad - assemblers are the main people crying over this.
• Unless you go crazy in optimizations (something that happened to me many times), your code will grow in size greatly.
• No more BIOS interrupts. You now how have to do everything manually... the keyboard, mouse, floppy disk, hard disk.. everything. There are complicated ways of getting in between Real and Protected Modes to temporarily enable BIOS interrupts, but problems come with it - I won't talk about it here.
• You have to reference tables to do anything with memory or interrupts.
• You now have to be more specific on what program can do what and where.

It is your choice. If you never programmed OSs before, I suggest you first learn how to do a couple of things in Real Mode first. (Load sectors, directly write to the monitor memory, make a interrupt handler for the keyboard, etc.) If you want to be challenged and think that documentations are friends, feel free to use Protected Mode.

actually, i will have to correct a few things...

* A whole bunch of speed lost because of the constant checks that programs don't do anything bad - assemblers are the main people crying over this.

this is a common missconception -- those same checks are done in RMode as well -- there just ignored, plus there done in hardware -- which means they dont take any time at all

in fact, on newer computers (begining with the P6 -- that is PentiumPro or PentiumII) PMode is actually much faster than RMode (this is why the PPro never sold well -- there was too much old RMode code still being used, so it was actually slower than the P5 for the typical user -- the PII is essentially the same as the PPro + MMX, but by the time it came around, most old code was gone, so it was much faster)

* You get up to 4 GB of memory.

actually, you get 64GB of physical memory (only 4GB virtual memory per process though) currently (and possibly more in the future)

this is a common missconception -- those same checks are done in RMode as well -- there just ignored, plus there done in hardware -- which means they dont take any time at all

It is a missconception but a true one nevertheless

"take no time" is a propagandistic lie.

It is imposible in physics to do some action in "no time" and no costs. If you like to believe that anything can be done for free in physics well be my guest.

Let me be a little more explicit:

1)The gates to make the checks, the logic behind and the cache for OS tables are there. And the gates do consume power and heat up the CPU and use up space on die. In consequence the CPU has lower cpababilities because of this.

Basically It heats more and has less resources/space available.

2)The information for the checks is not always there and occasinally if has to change (task switch or IRQ-s) and it means costly accesses to external memory.

Since for example: the task switch because of IRQ-s from network is more intensive and this will generally a slow down of the CPU exactly when it has to perfom better.

Of course that this will indeed be neglectable when the CPU is in idle state.

3)The check the gates means a loose of time.

It takes time for the signals to propagate into gates at this speeds (in fact at any speed) and to fill up the capacitance of the signal lines.

The more layers of those checks are done the bigger the delay/latency.

This can be somehow hidden by pipelines but again this in not a good ideea for other reasons (dependency and additional latency).

So the gates in ammonte will have to wait for the gates before them to settle up a valid response and CAN NOT continue until a decent delay.

This delay could be eliminated IF the check was never made...
because of this the CPU would have been faster and simpler.

Theoretically in Real mode it is possible that those checks are stiil done and indeed the presence of "unreal mode" does suggest so.

BUT it could have been made in such a way as NOT TO wait for the result and this would have been even faster...


Oh well, you are right: indeed it is irelevant because the best way today is to use 32 bits protected mode.

BIOS is good, was good and would have been good BUT it was put down simply because the well established rulers did not want others to be able to make an OS very easy after they have done one.

The main breake in hobby OS or new OS is the huge ammount of drivers to be done for a decent hardware compliance... then it would be the Applications but applications are not an OS

Anyway IMHO still sitting there on the grave of the BIOS and Real Mode and crying .... today in 2006 is a nice funy joke.

Understand the situation, the capitalistic reasons for it, that it will never change and probably a protected or Long mode BIOS just to help you make your dream OS easyer WILL NEVER HAPPEN ....

Grow up, use the BIOS in initial real mode part of your OS as much as you can and them say "good byte" and move on to the 32 bits protected mode and/or 64bits Long mode and do what you can...

After ALL doing all that drivers and organization and obtaining all that insight information about the stupid technology of the human race was the the FUN of this RIDE?

or was it not?

hey
thanx for the input guys....i've now setup a GDT and IDT as well as interrupt service routines