Pointer to some seriously good tutorials needed

[asmLover]

Hi, As my name suggests I love asm and I have currently been toying around with x86 development. My goals are to author my own kernel that works on 16-bit, 32-bit and 64-bit x86 variants (through forking) and learn more about multi-tasking and software<->hardware communication (low-level I/O)

I am currently performing experiments with bootloader test code to explore theories, and build my own documentation. I am using bochs on 64-bit smp (intel core 2 duo & quad core) machines using nasm as a compiler. what I would like to do is find out the how and why (reasoning) as well as the what (code) for things like setting up GDT's and IDT's, checking cpu, fsb and ram frequency and checking system RAM capacity (the osdev eamples seem to hang bochs), accessing PCI and setting up SMP. I would also like to know how drivers and shared objects in assembley work

please help!

[NickJohnson]

The tutorial I initially used was this one. It goes through pretty much all the basics of paging/multitasking. It's written in C, but you should be able to translate any examples to assembly. Beyond that, you can find more detailed information about the x86 through the Intel manuals (available on the Intel website), and broader information about osdev though the wiki and Wikipedia (and, if all else fails, the forums).

[Brendan]

Hi,

Hi, As my name suggests I love asm and I have currently been toying around with x86 development. My goals are to author my own kernel that works on 16-bit, 32-bit and 64-bit x86 variants (through forking) and learn more about multi-tasking and software<->hardware communication (low-level I/O)

In assembly, you write 64-bit code or 32-bit code or 16-bit code. This means you may need to write 3 versions of everything.

It's possibly to design a micro-kernel such that a 64-bit kernel can use 32-bit drivers (so that you don't need to write 3 versions of all those drivers). In theory it may be possible to design a micro-kernel such that a 64-bit kernel and a 32-bit kernel can use 16-bit drivers, but this fails in practice - to hide the differences between real mode addressing and protected mode addressing, you'd need to limit every device driver to 64 KiB of code and data, which makes it impossible to have decent buffers/caches, etc.

Given that most people fail to find enough time to complete one version of their OS, it doesn't seem sane to attempt to write 2 or 3 times as much code as them in a more time consuming (and harder to maintain) language - you'd be failing to complete a quarter of the OS instead of failing to complete an entire OS.

Basically what I'm suggesting is that if you want to write a micro-kernel, forget about 16-bit CPUs and write 2 kernels (one 32-bit and one 64-bit) and write most device drivers as 32-bit (to avoid writing them all twice); and if you want to do a monolithic kernel choose either 32-bit or 64-bit (but NOT both), or use a higher level language instead (where the same code can be compiled for 32-bit or 64-bit with few changes). If you manage to get anything completed (and you're not too old by then to remember your own name), then you can consider porting the entire thing to 16-bit (or ARM or MIPs or...).

Note: This advice may sound harsh, but trust me - I've been writing OSs in assembly for about 15 years now, and I'm still nowhere near finishing anything...


Cheers,

Brendan

[asmLover]

Hello everyone!

thank you for all of your responses, I love Nick's response as that is a massively helpful tutorial in it's explanations of gdt and idt.

While I do recognise that 16->32->64 bit is difficult I will be the first to admit that I am nowhere near even writing a full kernel so at the moment it's sort of irrelevant. I want to be able to understand every intricate detail of my kernel and I know this is going to give me massive long-term benefits as well as short-term headaches. I have yet to write graphics routines (although I have some wonderful svga vesa 3 code I slammed together from ralf brown's interrupt list) and need to put in more checks for technologies used.

thanks for the help and keep it coming