What is needed in OS?

[Vladaz]

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.

[Brandon]

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.

[DennisCGc]

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

[Vladaz]

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?

[Brandon]

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).

[crc]

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:

Code: Select all

read_key:
     xor eax,eax      ;  clear eax
.1      in al,64h          ;  Is any data waiting?
     test al,1         ;  Is character = ASCII 0?
     jz .1         ;  Yes? Try again
        in al,60h          ;  Otherwise, read scancode
        xor edx,edx      ;  edx: 0=make, 1=break
        test al,80h      ;  Is character = HEX 80h?
        jz .2         ;  Skip the next line
        inc edx         ;  Update edx
.2      and al,7Fh      ;  Filters to handle
        cmp al,39h         ;  the ignored keys
     ja .1         ;  We just try another key
        mov ecx,[board]      ;  Load the keymap
        mov al,[ecx+eax]   ;  Get the key ASCII char
     or al,al         ;  Is is = 0?
        js .shift         ;  No, use CAPITALS
        jz .1           ;  Ignore 0's
        or dl,dl         ;  Filter for break code
        jnz .1          ;  Ignore break code
; HERE WOULD BE A CALL TO A FUNCTION THAT
; DISPLAYS THE KEY THAT WAS PRESSED, IF YOU
; WANT THAT
      ret
.shift  mov ecx,[edx*4 + .shifts]   ;  Load the CAPITAL keymap
        mov [board],ecx         ;  Store into BOARD pointer
        jmp short .1         ;  And try again
.shifts dd shift,alpha
variable board, alpha
alpha:
  db 0,27,"1234567890-=",8              ;00-0E
  db 9,"qwertyuiop[]",10                ;0F-1C
  db 0,"asdfghjkl;'`"                   ;1D-29
  db -1,"\zxcvbnm,./",-1,"*",0,32,-2    ;2A-3A
shift:
  db 0,27,"!@#$%^&*()_+",8              ;00-0E
  db 9,"QWERTYUIOP{}",10                ;0F-1C
  db 0,'ASDFGHJKL:"~'                   ;1D-29
  db -1,"|ZXCVBNM<>?",-1,"*",0,32,-2    ;2A-3A

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.

[BI lazy]

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.

[Pype.Clicker]

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

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

[crc]

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

[Pype.Clicker]

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 ...

[Dreamsmith]

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.

[Dreamsmith]

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]

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...

[Dreamsmith]

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.

[Candy]

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.