Computer with floppy

[feare56]

Ok, i see. I'll post back when I rewrite my kernel!

[TightCoderEx]

I'm not sure what your goals are, but in general it's almost always a better idea to use long mode and/or protected mode.

Speaking of goals, you may want to consider UEFI too. My system is going to be designed for the 3 legacy systems I have, but already of the twenty some odd people I know that have computers, 85% are UEFI, so my legacy boot loader wouldn't even work.

[feare56]

I'm not sure what your goals are, but in general it's almost always a better idea to use long mode and/or protected mode.

Speaking of goals, you may want to consider UEFI too. My system is going to be designed for the 3 legacy systems I have, but already of the twenty some odd people I know that have computers, 85% are UEFI, so my legacy boot loader wouldn't even work.

Interesting, would a uefi boot loader work on legacy systems. I'm probably the only odd one that prefers older computers

[Octocontrabass]

Interesting, would a uefi boot loader work on legacy systems.

Not without a UEFI emulation layer, and I doubt anyone will want to use one of those.

I'm probably the only odd one that prefers older computers

I do most of my testing on a PC with a 40MHz 386. (I've also done some work on a computer with a 25MHz 68040, but progress is slow due to lack of documentation...)

[Brendan]

Hi,

Interesting, would a uefi boot loader work on legacy systems.

Not without a UEFI emulation layer, and I doubt anyone will want to use one of those.

The best approach is to build an abstraction layer into your boot code. For example, you can (and I do) have some boot loaders for BIOS and few other boot loaders for UEFI, where the boot loader hides the differences between BIOS and UEFI and ensures that nothing else in the OS has to care what the firmware was.


Cheers,

Brendan

[TightCoderEx]

For example, you can (and I do) have some boot loaders for BIOS and few other boot loaders for UEFI, where the boot loader hides the differences between BIOS and UEFI and ensures that nothing else in the OS has to care what the firmware was.

That pretty much sums it up, as at this level of development you want to be as independent as possible. Linus Torvalds was even a bit more crass about it, characterizing going into protected mode as "turning off the stinking BIOS". There is and has been for sometime now, a level of exclusivity in the desktop environment wherein it's getting pretty difficult to get information about architecture and chipsets from the horses mouth.

In a previous post I said

My system is going to be designed for the 3 legacy systems I have, but already of the twenty some odd people I know that have computers, 85% are UEFI, so my legacy boot loader wouldn't even work.

Most UEFI have a BIOS emulation mode, so I would assume my loader would work under that condition, although I've never tried it.

My impetus in developing for the desktop environment is entirely predicated upon, I've already got a few of these doorstops hanging around, why not use them. I have a reasonable familiarity with X86, so Gizmo 2 has recently caught my eye, mostly due to the information from manufacturer.

[feare56]

Alright, since I'm doing a reboot on my project I have decided to make my code more readable. I'm switching from strictly nasm to nasm when needed and c for everywhere else!

Since it has been a while since I have worked with c in osdev. Would the kernel.c be something like:

Code: Select all

EXTERN kernel;

void main()
{
    printf("Hello Kernel!");
}

To just print Hello kernel?

[iansjack]

Can we assume that you have already written a working printf?

[feare56]

Yes, my main concern is if that section would work. I made it on the fly just to make sure it will work before I have access to a computer