OSDev.org

http://codewars.osdever.net
http://forum.osdever.net/viewtopic.php?t=464

just read some more on it. I hope you guys will join us and have some good ol' OS hackin phun. We need judges still too.

::) :-* ;D

how r u supposed to fit all that in one bootsector? i guess that we are allowed to use a second stage loader?

I must admit my first impression was "you don't want a lot!" ;D

srg

it's all very simple. Just meet the goal, do it well, code nicely, and be judged. This challenge is gonna be very simple to a lot of people. But don't worry, they'll get harder!

thanks for the feedback :]

my present bootloader meets these requirements where can i submit it. its 2 stage btw

mr. xsism wrote: Just meet the goal, do it well, code nicely, and be judged.

You can't code it nicely in 512 bytes, and with the FAT12/bootsector requirement you've already lost something like 63 bytes anyhow. Sure it can be done, but fitting that much into that little space effectively makes it a test of people's real mode assembly programming, not their OS skills.

maybe we should limit it to 1 stage. I did it in 512bytes. Curifir, bootsectors are part of OS dev, come on dude. You can't ahve an OS without a bootsector.

Like i said, the challenges will get harder. I know most of the people that are readign this can already print text, get keyboard input, etc. This is ment for fun and teaching noobs.

I would appreciate your HUMBLE support. Humility is a great quality when it comes to teaching.

I would see few problems with it, if the rules were relaxed so as to permit you to put most of the work, i.e. a20 gate, p-mode, etc. into the second stage, either a hidden file similar to the MS-DOS IO.SYS, or in the kernel.bin file itself. The problem lies in trying to fit all of that into the 474 bytes available in the FAT12 boot sector (512 - (2 byte bootsig + 3 byte jump and noop + 8 byte OEM ID + 25 byte FAT12 BPB); remember, a FAT12 BPB is a little less than half the size of a FAT16 BPB). While it may be possible, it would require some very butch assembly coding.

EDIT: corrected size of available space. I was half asleep when I wrote that, OK?

mr. xsism wrote:Curifir, bootsectors are part of OS dev, come on dude. You can't ahve an OS without a bootsector.

You can't have an OS without the BIOS. Is that part of OS development? No, it's part of the infrastructure required to get the OS booted. As far as the kernel is concerned, the BIOS's sole job is to get the hardware initialised far enough that it can be loaded from disk and run.

Is the boot sector part of OS development? No, it's part of the infrastructure required to get the OS booted. As far at the kernel is concerned, the boot sector's sole job is to use the BIOS to get the kernel loaded from disk and run.

IMO, boot sectors are entirely uninteresting -- there's only one goal (get stuff loaded) and only one way to do it (load from disk, enter protected mode, JMP).

I hope this first challenge isn't suggestive of what forthcoming challenges will be like (not in terms of "easyness" but in terms of the policy/mechanism balance). Most challenges should be held on modules where there is at least _some_ policy decisions to be made, because this is where the creativity comes in when designing your solution. Mechanism is grunt work that is for the most part the same in various implementations. Bootloaders are an area almost completely dominated by the mechanism department.

so instead you guys would rather just code strictly OS modules dealing with the kernel?

hey tim, maybe we will have a BIOS challenge

mr. xsism wrote: so instead you guys would rather just code strictly OS modules dealing with the kernel?

Well, that's what OS development means to me. nullify hit the nail on the head: it's nicer to have some element of design/policy as well as implementation/mechanism. If it was purely mechanism, then this would be a contest to see who could read the Intel manuals best.

Having said that, I've been hacking on a boot sector today, but with a difference. It enables protected mode and paging first of all, then tries to load stuff off disk.

hey tim, maybe we will have a BIOS challenge

Sounds fun! Hmm, maybe not quite yet.

Tim Robinson wrote: Having said that, I've been hacking on a boot sector today, but with a difference. It enables protected mode and paging first of all, then tries to load stuff off disk.

Sounds incredibly cramped, but a really nice thing if you can pull it off. Keep us informed

I'm going down the route of putting floppy drive code in the page fault handler, then jumping to 0010_0200 to execute the code stored just after the boot sector. I hope I can fit it all in 512 bytes!

John Fines bootf02 does this IIRC. so wheres the challenge in doing this?