My first steps in OSDev.
Posted: Sat Aug 29, 2009 4:48 pm
Hello, I am making an OS for the first time.
Preamble:
Being new to this forum I may fail at getting anyone to care. In that case, the "tl;dr" is:"I'm about to make an OS the lamest way ever so you will have to educate me!"
This thread may fail on the "specefic question" criteria, because I intend to bump it every time I have another question... Better than making a new thread every time, don't you think? And all the info you may require is in one place that way.
Despite it's been said that all the people who know what they're doing here are busy, even a really busy person may be bored at times, and by chance could even help me
If it seems obvious for you that noone will help me, kindly say so.
Now that's out of the way, here is the usefull text:
Specifications are appended to the bottom of my post.
My life story:
The OS I am making will be run on emulated, simplified hardware, in a game actually - Garry's Mod - but don't think I'm just some gamer kid who doesn't know what he's talking about. We have tried and succeded in building computers before...
It runs on a homebrew CPU, and so I may alter the CPU when beneficial. I believe I have a basic idea of how to make an OS, but it feels like I'm missing something very important.
How my OS would boot (and thus all the features it has):
0) run BIOS
1) Check for boot flags/options.
2) Detect devices on simplest level.
3) Periodically report the the progress.
4) Find the boot sector and load the OS loader into RAM.
5) Load filesystem API.
6) Configure HDD and RAM memory protection.
7) Load drivers (at first, only those associated with current devices).
8 ) Init thread pool.
9) Init scheduler.
10) Init RAM pager.
11) Init event messanger.
12) Check settings.
13) Start window system.
14) Start all programs in the "run on start-up" list.
Schedule:
The OS uses round-robin algorythm of pre-emptive multitasking. Scheduler is run by a timed interrupt (I don't think interrupts will disrupt the work of a thread in any way), lets some thread continue running a few times based on priority, then switches to next. It also handles requests to start or end a thread. There can be alot of threads, I'm thinking up to a hundred. CPU states are quickly saved/loaded every switch, but if it runs out of space to store states, it alerts scheduller, and it has to clean up some space. Either by killing a thread, or dumping part of state memory into RAM. And politely ask the user to stop running more stuff than he could ever need.
The CPU:
Instructions:
- read, write, move.
- goto, sub, endsub.
- if - if constant value = register, do next command, otherwise skip it.
- operate - number of math operation and destination register.
- IO - like mov but with CPU's outputs and inputs.
- copystate - used for interrupt support and thread switching.
- change adressing mode for next command: movable or not, indirect or absolute adressing.
- mode - change some settings and defaults.
10 general purpose registers - all others are only acessable through mode command.
1 register for relative adress shift of current thread's code (for movable code).
2 selectors of source registers for math operations.
1kb of fast memory that stores cpu states (the above 13 registers).
1 register shows how many state slots are left in fast memory.
1 register stores current thread's permission level. (Userlevel / kernel level, is it allowed to modify security settings?)
2 registers store "canvas" of ram that current thread is allowed to acess.
2 registers store range of inputs/outputs that are only for kernel level.
Well, I don't really know what to say. I basically want you to find any imperfections in my plan. Oh and, there offcourse will be assembler and C compiler. So, an OS would have tons of code, so it's important for me to know: What can I write in C, and what should I write in assembly?
Preamble:
Being new to this forum I may fail at getting anyone to care. In that case, the "tl;dr" is:"I'm about to make an OS the lamest way ever so you will have to educate me!"
This thread may fail on the "specefic question" criteria, because I intend to bump it every time I have another question... Better than making a new thread every time, don't you think? And all the info you may require is in one place that way.
Despite it's been said that all the people who know what they're doing here are busy, even a really busy person may be bored at times, and by chance could even help me
If it seems obvious for you that noone will help me, kindly say so.
Now that's out of the way, here is the usefull text:
Specifications are appended to the bottom of my post.
My life story:
The OS I am making will be run on emulated, simplified hardware, in a game actually - Garry's Mod - but don't think I'm just some gamer kid who doesn't know what he's talking about. We have tried and succeded in building computers before...
It runs on a homebrew CPU, and so I may alter the CPU when beneficial. I believe I have a basic idea of how to make an OS, but it feels like I'm missing something very important.
How my OS would boot (and thus all the features it has):
0) run BIOS
1) Check for boot flags/options.
2) Detect devices on simplest level.
3) Periodically report the the progress.
4) Find the boot sector and load the OS loader into RAM.
5) Load filesystem API.
6) Configure HDD and RAM memory protection.
7) Load drivers (at first, only those associated with current devices).
8 ) Init thread pool.
9) Init scheduler.
10) Init RAM pager.
11) Init event messanger.
12) Check settings.
13) Start window system.
14) Start all programs in the "run on start-up" list.
Schedule:
The OS uses round-robin algorythm of pre-emptive multitasking. Scheduler is run by a timed interrupt (I don't think interrupts will disrupt the work of a thread in any way), lets some thread continue running a few times based on priority, then switches to next. It also handles requests to start or end a thread. There can be alot of threads, I'm thinking up to a hundred. CPU states are quickly saved/loaded every switch, but if it runs out of space to store states, it alerts scheduller, and it has to clean up some space. Either by killing a thread, or dumping part of state memory into RAM. And politely ask the user to stop running more stuff than he could ever need.
The CPU:
Instructions:
- read, write, move.
- goto, sub, endsub.
- if - if constant value = register, do next command, otherwise skip it.
- operate - number of math operation and destination register.
- IO - like mov but with CPU's outputs and inputs.
- copystate - used for interrupt support and thread switching.
- change adressing mode for next command: movable or not, indirect or absolute adressing.
- mode - change some settings and defaults.
10 general purpose registers - all others are only acessable through mode command.
1 register for relative adress shift of current thread's code (for movable code).
2 selectors of source registers for math operations.
1kb of fast memory that stores cpu states (the above 13 registers).
1 register shows how many state slots are left in fast memory.
1 register stores current thread's permission level. (Userlevel / kernel level, is it allowed to modify security settings?)
2 registers store "canvas" of ram that current thread is allowed to acess.
2 registers store range of inputs/outputs that are only for kernel level.
Well, I don't really know what to say. I basically want you to find any imperfections in my plan. Oh and, there offcourse will be assembler and C compiler. So, an OS would have tons of code, so it's important for me to know: What can I write in C, and what should I write in assembly?
