Ok, it's not that great yet.
The kernel now supports reading some scancodes and only in keyboard mode 2.
Only uncapitalised alpha characters are supported, so you can hit enter, backspace and the space-bar all you want. The system just doesn't give a visual reaction. For the rest, the thing works like a charm now.
I will split the code away later as it isn't really supposed to be implemented in the interrupt code but will rather have a dedicated keyboard file, which will support the different modes and the other keys on the keyboard. This, by the way, is all for the future.
Further more, I'm working on the timer and when it is implemented maybe I can start scheduling.
I also have figured out that I want the high memory kernel to be presented as a binary image just like Linux' initrd is now presented in the same way. This will result in me not having to implement a file system and hard disk drivers in the low memory kernel.
Wednesday 27 April 2011
Monday 25 April 2011
Interrupted
As the title may suggest I've got hardware interrupts working.
I have written all the IRQ stubs (just used macro's, which speeds up progress quite a lot) and have lead it to a C handler. The C handler resets the PIC and returns.
Before this could be used though I had to configure the PIC itself. Here is where the issues started as the device has quite a number of options.
My sources in this case were both the OSDev wiki and the Brokenthorn article.
If you want to just have code and not understand what it does, I recommend the OSDev Wiki as it provides you with readable code snippets. The wiki also provides you with plenty of information, but just in case you want to know what the initialisation control words are, I recommend the Brokenthorn article.
This too offers a code sample which is in plain NASM assembly. I personally prefer to have C code but if you want the speed enhancement assembly offers (which by the way isn't that much because you have to wait for the PIC to get ready every time), you can also use the sample in the Brokenthorn article.
Click here to see the commit this whole post is about.
I have written all the IRQ stubs (just used macro's, which speeds up progress quite a lot) and have lead it to a C handler. The C handler resets the PIC and returns.
Before this could be used though I had to configure the PIC itself. Here is where the issues started as the device has quite a number of options.
My sources in this case were both the OSDev wiki and the Brokenthorn article.
If you want to just have code and not understand what it does, I recommend the OSDev Wiki as it provides you with readable code snippets. The wiki also provides you with plenty of information, but just in case you want to know what the initialisation control words are, I recommend the Brokenthorn article.
This too offers a code sample which is in plain NASM assembly. I personally prefer to have C code but if you want the speed enhancement assembly offers (which by the way isn't that much because you have to wait for the PIC to get ready every time), you can also use the sample in the Brokenthorn article.
Click here to see the commit this whole post is about.
Friday 15 April 2011
Repo's and schedulers.
Just did some work on the repositories.
I now have one repository dedicated to my kernel, which I merge into the OS itself when ready to do so.
This means that all development on the kernel is done independently from any other project within the operating system.
There will be a boot loader in the future which I want to merge in the same way as I did with the kernel. And the same goes for basically every other aspect of the OS as well. The central repository is nothing more than a beginning of a source based package manager.
Also Christiaan (@csrakowski on twitter) has made a scheduler for me in pseudo code, which he is now trying to implement in actual code. He had some humour I'm not going to include in the repositories as I feel it might offend some people who don't know him.
His design was a basic round robin scheduler, which (for the novices) is a scheduler which gives each process on the system equal priority, without exceptions.
I personally prefer priority based scheduling in which case for example the sound daemon would get a higher priority as it simply needs more time to provide you with the sound quality you so much desire.
It still is in need of a timer, so if you have (A)PIC code for me to implement, which is GPL compatible, then please offer me a pull request.
The sources of the kernel are now found at http://github.com/bemk/andromeda.
I now have one repository dedicated to my kernel, which I merge into the OS itself when ready to do so.
This means that all development on the kernel is done independently from any other project within the operating system.
There will be a boot loader in the future which I want to merge in the same way as I did with the kernel. And the same goes for basically every other aspect of the OS as well. The central repository is nothing more than a beginning of a source based package manager.
Also Christiaan (@csrakowski on twitter) has made a scheduler for me in pseudo code, which he is now trying to implement in actual code. He had some humour I'm not going to include in the repositories as I feel it might offend some people who don't know him.
His design was a basic round robin scheduler, which (for the novices) is a scheduler which gives each process on the system equal priority, without exceptions.
I personally prefer priority based scheduling in which case for example the sound daemon would get a higher priority as it simply needs more time to provide you with the sound quality you so much desire.
It still is in need of a timer, so if you have (A)PIC code for me to implement, which is GPL compatible, then please offer me a pull request.
The sources of the kernel are now found at http://github.com/bemk/andromeda.
Wednesday 13 April 2011
Spinlocks
Oh god, not spinlocks!
Yes spinlocks.
When I wrote my memory allocation code I didn't have thread safety in mind, however while walking the dog I got to the conclusion it was better to make it safe than to do it when multiprocessing is actually implemented. That's why I have implemented spinlocks.
Why spinlocks?
They're simple and easy to understand. I know that they have drawbacks such as wasted CPU-cycles and everything, but right now it's the only form of mutex I can implement with the existing resources.
Right now I'm thinking about paged memory and how to implement it. The concept is rather simple, but the implementation needs some careful planning, as the memory allocation code needed too. (Remember, the memory allocation code cost me 2 rewrites to get it right.)
Where will we go when paging is finished?
I don't know yet. I will either start work on the (A)PIC or on image loading. The latter has a higher priority, but on the other hand, when loading from disk it can be nice to have the disk warn you that it's cache is ready.
Why were you doing this again?
I just want to learn as much as possible about the workings of the PC at software level, and I think the best way to do that is to understand a kernel. And think about it, what is the best way to learn the ways of the kernel? Right, to write one your self.
How long is this project going to last?
I seriously haven't got a clue. I think I'll write my kernel, finish it and then play with it a little. I doubt that this kernel will ever take off, since it's just for plain fun. I would think it's cool however if other people start writing software for the system and help me making it usable. As for now however, it still has a long, long, long, loooong way to go before it's anywhere near that point.
Yes spinlocks.
When I wrote my memory allocation code I didn't have thread safety in mind, however while walking the dog I got to the conclusion it was better to make it safe than to do it when multiprocessing is actually implemented. That's why I have implemented spinlocks.
Why spinlocks?
They're simple and easy to understand. I know that they have drawbacks such as wasted CPU-cycles and everything, but right now it's the only form of mutex I can implement with the existing resources.
Right now I'm thinking about paged memory and how to implement it. The concept is rather simple, but the implementation needs some careful planning, as the memory allocation code needed too. (Remember, the memory allocation code cost me 2 rewrites to get it right.)
Where will we go when paging is finished?
I don't know yet. I will either start work on the (A)PIC or on image loading. The latter has a higher priority, but on the other hand, when loading from disk it can be nice to have the disk warn you that it's cache is ready.
Why were you doing this again?
I just want to learn as much as possible about the workings of the PC at software level, and I think the best way to do that is to understand a kernel. And think about it, what is the best way to learn the ways of the kernel? Right, to write one your self.
How long is this project going to last?
I seriously haven't got a clue. I think I'll write my kernel, finish it and then play with it a little. I doubt that this kernel will ever take off, since it's just for plain fun. I would think it's cool however if other people start writing software for the system and help me making it usable. As for now however, it still has a long, long, long, loooong way to go before it's anywhere near that point.
Tuesday 12 April 2011
Booted from Grub
Just tried to boot from Grub legacy. Is quite simple to do actually. Grub2 is more difficult as the only system I have it installed is my laptop, which I like to keep running.
I have looked into the config files for Grub2, and I'm not amused. The config files are less intuitive imho.
I have looked into the config files for Grub2, and I'm not amused. The config files are less intuitive imho.
First tag
Hello.
I've been working on my kernel for a while now. Started last summer. Did some experiments and I think I'm ready to go now.
I have been working on memory allocation (which isn't entirely finished yet, because I still need to implement paging) and on exception handlers.
After working on a bug in the exception handling code for about 7 days, I finally have it fixed and now I can focus my attention on paging.
I just made the first tag in the repository to mark this moment. It is the first moment in the history of the project that the code is at a level it might be considered to be viewed in the future.
Now I'll start working on the paging code, and I see lots of trouble heading my way so having a fixed working point to revert to without remembering the exact 24 characters long sha1 key might be a nice thing.
Tag is called 0.0.1. This is the version number, which is this low because we still have a long, long, long, long, long, long way to go.
Tag is called 0.0.1. This is the version number, which is this low because we still have a long, long, long, long, long, long way to go.
Subscribe to:
Posts (Atom)