Hum, were to start.

[FFA702]

Hello all,first sorry for my bad english.

Okay now i red some topic and did some research about assembly tutorial,but im more used to higth level objet oriented programing,and all this ams code read like chineese for me.So if i have understand correcly,i need to write a botloader in asm(exclusively) and then i can write the kernel in C or someting?

So,can you point me to some "start from scratch" assembly tutorial and what C compiler to use.
Also i have some trubble to understand how to "link" the botloader and the kernel togheter,if i understand correcly the botloader specifie an adress in the memorie were the kernel start?

Thanks in advance,opfully il get started by tomorrow! XD

[NickJohnson]

You don't have to write your own bootloader (although you can if you want,) but you will need to use a bit of assembly. Try looking at the bare bones tutorial. Also, what platform are you developing on?

[FFA702]

Im developing on Windows, and what do you mean by you dont need to program your own bootloader, can i use an open source one*

[Dario]

Okay now i red some topic and did some research about assembly tutorial,but im more used to higth level objet oriented programing,and all this ams code read like chineese for me.

If you really understand OOP, then assembly will be peace of cake.
Assembly is the most easiest "language" to learn. That and the speed is its only benefit.

So if i have understand correcly,i need to write a botloader in asm(exclusively) and then i can write the kernel in C or someting?

Basically you have two choices:
1. start by writing your own bootloader
2. use GRUB as your kernel loader

So,can you point me to some "start from scratch" assembly tutorial and what C compiler to use.

There are many good resorces in wiki. I suggest you start with simple bootloader just to get you some feel(play with instructions, get to know arhitecture, write to screen, r/w to disc...), and then if you decide that GRUB will save you from the hell of PC bootenviroment...something you'll have to decide.

Also i have some trubble to understand how to "link" the botloader and the kernel togheter,if i understand correcly the botloader specifie an adress in the memorie were the kernel start?

Bootsector must be loaded as flat binary since BIOS doesn't understand linkable binary formats like ELF(it jumps straight at the very first instruction in bootsector at address 0x7c00. Inside that bootsector you use BIOS int #h calls to interact with the system(load more sectors, write to screen, extract some info from ROM...) and parse FS or binary formats like ELF to call your first kernel function.

[NickJohnson]

Im developing on Windows, and what do you mean by you dont need to program your own bootloader, can i use an open source one*

You can use GRUB as a bootloader: it's open source and used by most of the people here. Since you're on Windows, you should really set up a cross compiler for ELF if you want to use GRUB; there are instructions on how to do that on the wiki.

If you really understand OOP, then assembly will be peace of cake.

I don't know about that: assembly has effectively nothing to do with OOP, although it does have a lot to do with imperative programming. That said, it's not that bad once you get used to it, and you only need to write a small fraction of any kernel in it anyway.

[Combuster]

All your questions I've seen so far can be answered with a link to the FAQ and Tutorials.

Please search before posting.

[Dario]

I don't know about that: assembly has effectively nothing to do with OOP

I was refering to human logic not to programming languages. If one really understands the inner workings of OOP, then I see nothing in assembly that can be harder then that.
Most of the problems in assembly comes from arhitecture, especially if there are many crappy legacy issues, but assembly it self remains simple...and it's supposed to be that way since instructions are simple operations that CPU can understand.

[Chandra]

I don't know about that: assembly has effectively nothing to do with OOP

I was refering to human logic not to programming languages. If one really understands the inner workings of OOP, then I see nothing in assembly that can be harder then that.

I agree with that but some instructions are really hard to understand when it comes to implementing them. Hence, one need a basic assembly book to accompany him as a minimum requirement. Moreover, to be more specific about what instructions his/her CPU support particularly (for example CPUID), processor manual is the must.