OSDev.org

Hello.
I have lost ;D.
I want to ask you what i need to do next?
I have programmed Bootloader, A20 line, PMode, and now I am on kernel.
In kernel I have programmed a simple Print function and simple Clear Screen function.
What i need to do next? What I need to program to make a console type OS, that checks the simple commands like help and other:). Just simple.
So can someone tell me what I need to program now?
I think you understand what I mean.

Im not an expert on this, but I guess you should (I did so) write a memory manager. If your OS doesnt support interrupts yet, I suggest you implement it, since you need that for reading the keyboard and stuff like that.

It all depends on what you want to do with your OS

But yes, having interrupts working will be an idea.
Also implementing a malloc will be good too.
But after that, you should decide what to do

HTH

So now I need to make my interupts working? So what i need to do first. Maybe someone can tell me a manual to look at it?

Here?s a pretty good tutorial:
http://osdev.neopages.net/tutorials/int ... ?the_id=39

You will need to write interrupt handlers (pretty easy). Then you?ll have to load the IDT(a table that tells the CPU which functions it should run when an interrupt occurs).

If your OS doesnt support interrupts yet, I suggest you implement it, since you need that for reading the keyboard and stuff like that.

You can get by without using interrupts for the keyboard. Consider the following code sample from my OS:
Then you just call [tt]read_key[/tt] and it will wait for a keypress. When a key is hit, it returns the ASCII value in EAX.

But that's what interrupts are for: to avoid busy waiting for things that may or may not happen. No, best is to implement interrupt and exception handling. It eases life and fits exactly in the scheme of things in a modern CPU.

Does What order should i follow page of the FAQ helps ?

** edit ** i'm updating this page right atm...

But that's what interrupts are for: to avoid busy waiting for things that may or may not happen. No, best is to implement interrupt and exception handling. It eases life and fits exactly in the scheme of things in a modern CPU.

I agree: it's generally a good idea to implement them. But for what Vladaz stated that he wants to do (a simple console that checks simple commands), interrupts aren't needed. I must admit though: I haven't supported interrupts in my OS kernels since early 2000

and what about CTRL+C for aborting tasks you've started ? or about using the mouse (which use the same controller as the keyboard) ?

Really. Interrupt support is a *must*, and rewriting things to support them is a pain ...

Pype.Clicker wrote:Really. Interrupt support is a *must*, and rewriting things to support them is a pain ...

Ixnay. The importance of interrupt support is entirely dependent upon your OS architecture and its objectives. Much like multitasking: if you want it at all, there are still multiple ways to go about it, each with its own advantages and disadvantages. It may very well be the kind of issue that the OS/kernel ought to keep its grubby paws off and let the apps deal with as they wish. Or not. It all depends on what you're trying to achieve.

crc wrote:I agree: it's generally a good idea to implement them. But for what Vladaz stated that he wants to do (a simple console that checks simple commands), interrupts aren't needed. I must admit though: I haven't supported interrupts in my OS kernels since early 2000

crc = Charles R. Childers? Aren't you too busy releasing new RetroForth versions faster than I can download them to be posting here? No sooner do I download 7.0 than 7.1 is available, and 7.2 beta goes up before I get around to downloading 7.1! :LOL: Welcome, in any case... ;D

crc = Charles R. Childers? Aren't you too busy releasing new RetroForth versions faster than I can download them to be posting here? No sooner do I download 7.0 than 7.1 is available, and 7.2 beta goes up before I get around to downloading 7.1! :LOL: Welcome, in any case...

Yes, that's me. And yes, I am somewhat guilty of "excessive" releases... It'll be a while before 7.2 is "officially" released though; I've paused work on it to finish the new RetroForth/Native system (Conversion to FASM is complete, a couple of bugs left to kill...) and get the docs finished. Give me another week, and all versions will be at 7.2 though

You are right: interrupts are not essential to all kernels/OSes. I'm playing with some cooperative multitasking schemes that don't use interrupts, and I've had less trouble with my interrupt-free kernels than with ones that used interrupts. Of course, I don't follow conventional approaches to OS dev anyway...

crc wrote:You are right: interrupts are not essential to all kernels/OSes. I'm playing with some cooperative multitasking schemes that don't use interrupts, and I've had less trouble with my interrupt-free kernels than with ones that used interrupts. Of course, I don't follow conventional approaches to OS dev anyway...

For a lot of applications, particularly in small or embedded systems, it just plain makes more sense. Cooperative multitasking is a lot faster than preemptive multitasking, plus, so many other problems that plague preemptive systems just disappear. No need for semaphores/mutexes, no race conditions, etc. When you're doing embedded work, you or a small group of people are writing all the applications that will run on the platform, so ensuring everything cooperates nicely is easy, and you don't have to worry about hostile apps refusing to yield without reason. Really, cooperative multitasking should be chosen over preemptive multitasking whenever you can get away with it. It just doesn't work well for general purpose OSes when you can't ensure everything will be cooperative.

In these same sorts of situations, it is often more efficient to use polling than to use interrupt handlers for I/O. Not always -- sometimes certain hardware needs to be serviced immediately rather than when an app gets around to it, but unless that is the case, you can again avoid some overhead and wasted cycles by using polling rather than interrupt-driven operation, thus, somewhat paradoxically, making the system more responsive by avoiding the use of interrupts. Unless you're worried about people typing faster than you're polling, having an ISR queue keypresses and then the app dequeue them is adding a bunch of additional work when the app could simply read the keyboard whenever it's ready for the next byte.

If you're designing the next great desktop OS, obviously none of this applies. But for many OSes, this is the best way to do things.

I would even claim that using polling makes your system more reliable because you don't have to deal with unpredictable stuff. You can just poll at every timer tick and see whether something is there.