SauOS: ready for code!
Re: SauOS: ready for code!
I commited r37, with my sc2ascii.
Current work on a OS: SauOS (project homepage: http://code.google.com/p/sauos/)
-
- Member
- Posts: 2566
- Joined: Sun Jan 14, 2007 9:15 pm
- Libera.chat IRC: miselin
- Location: Sydney, Australia (I come from a land down under!)
- Contact:
Re: SauOS: ready for code!
You say it should work... How do you know it does? Have you tested it, at all?
Re: SauOS: ready for code!
The code doesn't make much sense. i guess you are not finished yet, but i not sure what you are trying to achive
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Re: SauOS: ready for code!
K, I've seen enough bashing from everyone. Lets quit this before I start handing out warnings to everyone here.
Re: SauOS: ready for code!
It looks to me like you are just getting started, so I wont comment on your mistakes. However, some friendly advice, try to find a way to combine these two things, then find a way to combine to it the SHIFT+Key characters e.g. A, B, C, !, @, #, etc:
Allow the design to define itself. Take a look at this link for help doing that: Scancodes -- Hint: Look for a common pattern.
Code: Select all
char *characters[] = {"1","2","3","4","5","6","7","8","9","0","-","=","q","w","e","r","t","y","u","i", "o", "p", "[","]","a","s",".","d","f","g","h","j","k","l",";","'","z","x","c","v","b","n","m", ",", ".", "/", " "};
int scs[] = {0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1e, 0x1f, 0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f, 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x39};
Re: SauOS: ready for code!
I know about SHIFT modifers. But, this complaitices my sc2ascii... and so we go again...purage wrote:It looks to me like you are just getting started, so I wont comment on your mistakes. However, some friendly advice, try to find a way to combine these two things, then find a way to combine to it the SHIFT+Key characters e.g. A, B, C, !, @, #, etc:
Allow the design to define itself. Take a look at this link for help doing that: Scancodes -- Hint: Look for a common pattern.Code: Select all
char *characters[] = {"1","2","3","4","5","6","7","8","9","0","-","=","q","w","e","r","t","y","u","i", "o", "p", "[","]","a","s",".","d","f","g","h","j","k","l",";","'","z","x","c","v","b","n","m", ",", ".", "/", " "}; int scs[] = {0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1e, 0x1f, 0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f, 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x39};
I am working. Sh...
Current work on a OS: SauOS (project homepage: http://code.google.com/p/sauos/)
Re: SauOS: ready for code!
I see you do use a lot of source code from bkerndev. As I learned with ScorchOS 0.0.7, it is not always a good idea to base off of tutorial kernels (especially as it opens you up for criticism, regardless of any work you've put in), but it is good for learning how kernel development works.
I can't find your shift modifier code? Whatever happened to it?! lol You seem to add interesting new features then remove them when they don't quite work (paging for example) - sometimes it is worth sticking with things to get produce something good.*
I've just sent you a pm - if you're interested in a helping hand with your project then drop me a line. It shows potential and could make good use of the much more stable code I would have included if I had stuck with my bkerndev-based kernel.
*To avoid accusations of hypocrisy here, I chose to rewrite my kernel in FreeBASIC as I thought it would be an interesting thing to do and produce a clean break from the previous criticisms. If it were not for my interest in that language I would have stuck with the same kernel but rewritten a lot of it to optimize Scorch for a particular purpose.
I can't find your shift modifier code? Whatever happened to it?! lol You seem to add interesting new features then remove them when they don't quite work (paging for example) - sometimes it is worth sticking with things to get produce something good.*
I've just sent you a pm - if you're interested in a helping hand with your project then drop me a line. It shows potential and could make good use of the much more stable code I would have included if I had stuck with my bkerndev-based kernel.
*To avoid accusations of hypocrisy here, I chose to rewrite my kernel in FreeBASIC as I thought it would be an interesting thing to do and produce a clean break from the previous criticisms. If it were not for my interest in that language I would have stuck with the same kernel but rewritten a lot of it to optimize Scorch for a particular purpose.
ScorchOS: http://sites.google.com/site/scorchopsys/
"The golden rule: RTFM, check the wiki, google it and have a go BEFORE asking the question!"
"The golden rule: RTFM, check the wiki, google it and have a go BEFORE asking the question!"
Re: SauOS: ready for code!
Now SauOS needs a kernel rewrite, which will occur in a seperate branch. You can help, PM me, then checkout the branch:
Make sure to test everything you fsck up.
Code: Select all
svn checkout https://sauos.googlecode.com/svn/branches/sauast sauos --username <googlecode_address>
Current work on a OS: SauOS (project homepage: http://code.google.com/p/sauos/)
- gravaera
- Member
- Posts: 737
- Joined: Tue Jun 02, 2009 4:35 pm
- Location: Supporting the cause: Use \tabs to indent code. NOT \x20 spaces.
Re: SauOS: ready for code!
I thin that a lot of people severely underestimate the sheer volume of material you shold be reading while doing OSDev. And not just reading things once, and then saying: "I didn't understand: time to post on the forums." There are some things you should read repeatedly. A lot of things actually.
Actually, you should be reading non stop. And Design, from my POV is crucial. There is no such thing as implementation without design when doing something as complex as an OS.
If you want to just code, and you're itching to start, then I suppose it's okay to do somethings like write out the cpu.h file, and your basic, real mode vga.h, etc. Who knows: it's okay to move into writing ELF support, and whatnot, and do the modules that you see are obviously necessary. But before you go into writing parts of the system that interface with other modules, and that sort of thing, you should draft out at least some rough sketches first.
I'm not yet an expert, but i think your OS has so far displayed key symptoms of a badly planned project. Take some time off to do some really serious reading and planning.
-All the best
gravaera
Actually, you should be reading non stop. And Design, from my POV is crucial. There is no such thing as implementation without design when doing something as complex as an OS.
If you want to just code, and you're itching to start, then I suppose it's okay to do somethings like write out the cpu.h file, and your basic, real mode vga.h, etc. Who knows: it's okay to move into writing ELF support, and whatnot, and do the modules that you see are obviously necessary. But before you go into writing parts of the system that interface with other modules, and that sort of thing, you should draft out at least some rough sketches first.
I'm not yet an expert, but i think your OS has so far displayed key symptoms of a badly planned project. Take some time off to do some really serious reading and planning.
-All the best
gravaera
Last edited by gravaera on Sat May 26, 2012 5:04 pm, edited 1 time in total.
17:56 < sortie> Paging is called paging because you need to draw it on pages in your notebook to succeed at it.
Re: SauOS: ready for code!
The following was sent as a pm after a brief pm conversation. I made some contributions to the project to start porting some old ScorchOS code over but I have since stopped now as a new kernel is in development. I have stated to the recipient that the conversation will now move to the forums, as there is no reason why things should not be public
PM:
PM:
Please do not misunderstand what I say in this message. I offer the following as advice. It is up to you whether or not you take it.
I personally won't contribute to a dead kernel - one does not develop a product with the purpose of later porting it! I have made this mistake before when moving from ApolloOS to ScorchOS. The shell and drivers didn't fit the new kernel, The only way it would fit was with a lot of recoding and temporary fixes (which lead to instability until I patched the 0.0.7 release). If you are writing a new kernel, I would recommend building from the ground-up (using tutorials and possibly the ScorchOS code as a reference) - that way you can make every decision with your end goal in mind and therefore create a stable base for the future.
I think at the moment your scope is a little wide. You sound like every other project which is creating a 'general purpose' OS when you say that it will work with servers and desktops. Consider exactly what hardware platform you want to support, which users you are targetting and ultimately what sets you apart from the other 150 OS projects which will disappear in the next 6 months (that was number in 2006, I am led to believe this has risen).
And finally, be positive! Initially you will be coding your kernel on your own. That is inevitable. I have had people contribute to the wiki and ask me questions, but I have mostly coded ScorchOS alone. It seems scary, but if SauOS is your project it is only right that you make the biggest contribution to start with! Programmers are not born, they are made - experience comes with time. You also have the good fortune to have good advice from people who've been there before so you can avoid their mistakes and make a good kernel. Who knows, in time you may even create something great?! The osdev community is here to get you started.
ScorchOS: http://sites.google.com/site/scorchopsys/
"The golden rule: RTFM, check the wiki, google it and have a go BEFORE asking the question!"
"The golden rule: RTFM, check the wiki, google it and have a go BEFORE asking the question!"
Re: SauOS: ready for code!
I have decided the final goal: A realtime sever OS is SauOS' goal, and it will still try its best to be UNIX-like and POSIX-comforming.
Current work on a OS: SauOS (project homepage: http://code.google.com/p/sauos/)
Re: SauOS: ready for code!
In that case I wish you luck with your new kernel. Please feel free to use the ScorchOS source code for reference (it isn't perfect, but it seems to work! ). If you have any questions post them here, or if you have a particularly urgent question I will answer by pm (just be aware I will assume I have your permission to repost your pms here).
ScorchOS: http://sites.google.com/site/scorchopsys/
"The golden rule: RTFM, check the wiki, google it and have a go BEFORE asking the question!"
"The golden rule: RTFM, check the wiki, google it and have a go BEFORE asking the question!"
Re: SauOS: ready for code!
@Scorch: I beg to differ, programmers are, in a sense, born, not made...
It's about like an artist to me. There is no way to teach someone to be a great programmer, but anyone can be a good programmer, and a great programmer without a nudge in the right direction can be the worst programmer of them all.(i.e. Black hat)
It's about like an artist to me. There is no way to teach someone to be a great programmer, but anyone can be a good programmer, and a great programmer without a nudge in the right direction can be the worst programmer of them all.(i.e. Black hat)
Re: SauOS: ready for code!
I was trying to be encouraging! lol
tbh you are right. Though you can learn to be a good programmer, there is that something extra which distinguishes the good from the great. They usually think in a particular (logical) way or come up with interesting ideas for implementation no one has thought of before. Who would we say on that criteria we mark as 'great' rather than 'good'?
tbh you are right. Though you can learn to be a good programmer, there is that something extra which distinguishes the good from the great. They usually think in a particular (logical) way or come up with interesting ideas for implementation no one has thought of before. Who would we say on that criteria we mark as 'great' rather than 'good'?
ScorchOS: http://sites.google.com/site/scorchopsys/
"The golden rule: RTFM, check the wiki, google it and have a go BEFORE asking the question!"
"The golden rule: RTFM, check the wiki, google it and have a go BEFORE asking the question!"