I was wondering... what do I need to start my own OS? A start point, tools, knowledge, etc.

[yep, i see this faq section, and i'm looking at some links, but i'm still feeling disoriented]

I don't know if i really want to do a OS, but maybe i'd like to do a simple one just to feel like the things work.

The first thing you need is IA32 manuals and Ralph Brown interrupt list.
Then to decide what type of OS you desire...
Start with tinkering with other peoples code
There are many small OS to learn basics from.
Then maybe progress into more complex like MenuetOS
Start with simple OS like my x3dos or Dex4u MiniDOS
Then check out DexOS and MikeOS for more advanced.
It really depend on OS type (desktop, game console etc...)

an OS is not always a commercial purpose internationally broadcasted code.

it will not always use all the power of the machine, but will just bring the functions you need.

for example, there is no file system explorer in my phone (nokia XXXX) or compiler to execute asm code. but it can do, but it doesn't. and it is not a problem.

then, if you just want an OS that can display chars on the screen with the keyboard, you don't need a lot of code.
after, step by step, you add new functions to your code, and it starts to grow.
etc etc...

i warn you, if you are a noob in asm, in 2 years you will still be ignorant of a lot of things.
Take IA manuals, Ralph browns interrupt list, and Helppc from david jurgens (it is a lot obsolete and incomplete), but a lot of theses obsolete datas are helpfull, even with new PC.

http://board.flatassembler.net/topic.php?t=5275 is a simple, but fairly functional(considering it's size) OS by Dex4u.

Find all the simpler OS's written in FASM that you can, and study them. After reading a few tutorials and documents, though.

Greetings Teehee,

I'm in the same boat so to speaks since I am about to re-start work on my own OS. Having run this path once before I have some experience in what I want to do and what I need. What I am about to suggest is not the easiest course of action, but will pay dividends in the end because your knowledge base will be emense.

1) Write your requirements in a document you can review and keep under control. (This is the stage I'm in write now) Do a version description document outlining your goals.
2) Research ways of implementing your requirements; document your references and save your references. This is where you get your tools in order to do your implementation of requirements.
3) Plan your workload towards acheiving your goals; plan for revisiting you goals/requirements regularly. Document which items you've finished and refresh your mind to what needs to be accomplished next. Additionally, this is your opportunity to make course adjustments based on how things have gone and what you can and can not get accomplished due to your own limitations.
4) Execute; write the code accordingly.
5) Test your code; allow others to test your code getting their particulars. Document bugs, work critical bugs now; work non-critical bugs in order of documented.
6) This is an interative process, therefore rinse and repeat, often.

This doesn't specifically answer your question, it is more of a philosophy towards getting to your end result. This is very top level too, as you can imagine, since writing the requirements and planning will identify those details. I hope it sparks some thoughts and by no means is the end all be all way to do things.

Definitely grab both Intel and AMD manual sets - if you want to plan for or include other advanced features you'll also need the additional specification sheets (e.g. SMP, ACPI, APIC, x2APIC, ...). If you're doing your own boot loader you will also want to look up Ralph Brown's Interrupt List (ints x10, x13 and x15 will be the most useful)

Following on from what smiddy said and having a written plan or roadmap, I suggest you aim to get core features working first and then add the less critical stuff on top of that. A further extension on these points, from my experience, is to manage your code well by making good use of directory structure and files, naming values (e.g. "VBE_SUPPORTED" is more meaningful than just "0x004F", so put VBE_SUPPORTED equ 0x004F in a separate header file somewhere) and then use a version control system such as subversion (SVN) - this will allow you to recover from code changes that go wrong and track changes you have made.

I personally have not made any use of books on operating system design but they may help. There are also several "hello world" boot sectors/loaders around and some example code to hit 32 bit protected mode with out much trouble; it's also a good stepping stone for 64 bit later on.

One final suggestion is to get hold of some virtual machines such as Bochs, VirtualBox and QEMU so you can test your code quickly and esily without having to write reboot, test reboot, rewrite, repeat

BTW, I just ordered the Intel manuals on CD, for free. Go to their website and they will walk you through the process.