That's actually one of the first things I thought of too:Neo wrote: John Fines bootf02 does this IIRC. so wheres the challenge in doing this?
"How many variations on John Fine's work will they get?"
There's no doubt you can stuff all the required elements into a bootsector, my problem with the challenge is that the final code will be so brittle as to be useless.
How many A20 methods are they expected to use? Or are they just expected to run through the keyboard controller method and pray that it works?
How many methods of determining memory should they use? Or are they simply going to rely on e801 being present (e820 would require more space thanks to interpreting the map)?
Are they supposed to do ANY error-checking at all aside from the disk interrupt? I say this because the first thing I'd kill would be any messages to the user thanks to the space required for strings.
I dunno, I guess if I was in your position I would first have come up with a set of aims for a target OS, then set challenges in such a way that entrants would build towards that target in digestable steps. That way by following the challenges, the entrants eventually wind up with something that works, and more importantly can see that they are progressing towards it. Once they're secure enough in the OS dev environment they can use such code as a reference for their future work.
As it stands I think that you're introducing too many concepts at the same time (Since this is for newbies). It would be better, IMHO, to start out just getting them to load a stage 2 (Less than 64kb size) from a FAT12 disk with error checking. That limits the concepts being used to BIOS interrupts, FAT12, and real-mode assembly which should be a nice digestable chunk.