OSDev.org

JamesM wrote:Zacarias - did you look at my tutorials? I posted the link above. They're very similar in starting point to Bran's tutorials, I've just started them, and would really appreciate it if you could give them a read and see if they're 'too geeky' too, or any other comments.

link again: http://www.jamesmolloy.co.uk

JamesM

i have looked at it, but the thing is that im kinda weird in some ways. One of the main reasons i like this other tutorial is that only ASM is used. I hate doing all this low lvl stuff in a high lvl language. C IS a fantastic programming language, but i hate it anyway... Atleast i do with this kinda stuff.

Ya, i know its hilarious...

i have looked at it, but the thing is that im kinda weird in some ways. One of the main reasons i like this other tutorial is that only ASM is used. I hate doing all this low lvl stuff in a high lvl language. C IS a fantastic programming language, but i hate it anyway... Atleast i do with this kinda stuff.

Ya, i know its hilarious...

Nothing weird about that at all, many people (like Dex, for example) prefer ASM to C. Personal preference. I was just hankering after some opinions

JamesM

Zacariaz wrote:

Combuster wrote:I suggest you list all of Brendan's posts )

It is funny... Again and again "Brendans" tutorial is mentioned however i have yet to see a link to it.

You are mixing things up - You have Bran's kernel development tutorial (or Brandon, which is his full name), and you have Brendan, which afaik didn't write any tutorial.

I think this tutorial focuses more on the theory side and uses code snippets to clarify rather then solve problems.

The problem with a lot of other tutorials is that they give code without clearly explaining WTF it's doing and how the author actually got to that solution (Like Bran's tutorial). This means that forums like this one have to deal with <insert not so nice words> problems.

B.E wrote:The problem with a lot of other tutorials is that they give code without clearly explaining WTF it's doing and how the author actually got to that solution (Like Bran's tutorial).

I agree. Its stupid how few of these 'OSdev tutorials' actually teach you OSdev - Some of them just tell you step by step how to write each part without explaining why/how, and others just dump code on you.

This tutorial (the one in the first post), shows some promise except for some of the errors in it (the last two sections of the tutorial claim to load the kernel at 1 MB, but instead loads it at 0x10000 (64KB!)).

Sadly, its still better than most...

edit: the tutorials on task switching are good!!
And my task switching code is working fine now!!
At last, I have a working kernel

This tutorial (the one in the first post), shows some promise except for some of the errors in it (the last two sections of the tutorial claim to load the kernel at 1 MB, but instead loads it at 0x10000 (64KB!)). Shocked

As the author of the tutorials, I have been noted of that little problem, and it has been fixed.

Sorry about that

I am currently only using NASM. I personally would like support for different compliers and tool chain, however. I am also very aware of the cross complier solution.

Some of the incorrect technical details I will see if I could fix those...

KEEP UP THE GOOD WORK!
I still think its very nice, and seemingly im ot the only one.

Im currently trying to include a processor architecture section, and microprogramming--something even lower level then machine language itself. It is the language of the hardware itself, either built in or developed using a microassembler and stored in ROM, just like the BIOS POST itself.

This would complete the system architecture tutorial, and explains how software can control hardware.

While this does not relate to the kernel, it does relate to microcontroller programming, as microcode is the language of those microcontrollers.

Afterwords, I will go back to the next new tutorial (It has already started.)

I didn't realise that the x86 architecture had reprogrammable microinstruction decoders?

neon wrote:Im currently trying to include a processor architecture section, and microprogramming

Can't wait

I've never heard of microprogramming until just then. I did a quick Google search on it, and seems very interesting (I'm a person who loves knowing the inside and out of devices, and Software (Operating systems and applications as well)). Is there official documentation on microprogramming.

JamesM wrote:I didn't realise that the x86 architecture had reprogrammable microinstruction decoders?

Microcode is still used, however, in the numerous Intel x86 compatible microprocessors like the Pentium 4 and AMD Athlon. However, within these designs, simple macroinstructions have one to four microinstructions (called uops or Rops, respectively) immediately generated by decoders without control store fetches.

Source

...Yep

Is there official documentation on microprogramming.

Nope. Its very controller and device specific. You can get more information from wikipedia: HERE

Anyway i would suggest finishing and "finetuning" og tutorial or parts of the tutorial, before starting on the next.

Cant wait fpr whats to come

Taking microcode to new extremes, there is a project in my university that is a CPU on an FPGA (field programmable gate array). This isn't new, but they're trying (successfully) to make it so that part of the CPU can be changed (reflashed, whatever - changing the layout of the FPGA to essentially make a different piece of hardware) on the fly, while another piece is still running. This means that, for example, when booting a game, the CPU could change itself into a super matrix-mathematics machine, and be uber fast, then transform back into general purpose when it's finished. I love the idea!

That sounds very cool!

I hope their project succeeds!:D

Anyway i would suggest finishing and "finetuning" og tutorial or parts of the tutorial, before starting on the next.

I have been wanting to do that, actually.

I should probably note that I do not plan on ever going back into real mode. I plan on producing chapters for programming each controller directly from protected mode.

This is what I hope, anyways. i.e., basic mother board drivers.