hm... right now the best KBD driver I have only supports normal and left shift key press. No FDD driver yet.

As the closing date approaches you should do the following to ensure your entry is both valid and safe from others copying (if that worries you).

1. Zip all of your source code and any dependent data/include files into one single file
2. Get the SHA1 hash of the zip file and post the hash publicly here before the closing date
3. Do not change the zip file in any way, just keep it with you for upload later
4. After the closing date you can then post the zip file either as an attachment in this forum, or as a link on a public website that you have permission to use

If the zip file hash and the SHA1 hash match then your OS will be considered as an entry. If the hashes do not match then your OS will not be considered as an entry. It is very important that the hash output be posted here before the closing date. This forum shows all post times and you will have to the last minute to post the hash. That means if you post on XX:07 then the hash is accepted, if you post on XX:08 (the same minute as the original announcement) then the hash is too late for entry. XX will depend upon you time zone settings. Note: that some time zones are on the half hour so for those zones the submission cut-off time would be XX:38.

Now this will allow you to complete your OS and make a final zip file and submit the signature (the hash) in time for the closing date without having the reveal the source code or the executable file. When the closing date passes then you can safely post the code somewhere without concern about others copy/pasting into their submission. If someone were to try to copy/paste then the signature would change on their zip file and their entry is no longer valid.

If you don't have a SHA1 generator then download one, there are many free versions available. Or, for fun, you could also write your own. Doesn't matter which, up to you, but make sure it produces the correct hash!

Oh my. The proper way of finding RAM sizes > 1mb is to use the BIOS. The only other way is probing, which:
a) Doesn't work
b) May damage your hardware

Its seems high-res is out of the question, as by theres rules no vesa is possable .

Too bad this time I don't have time to participate... I've got somewhere a nice FAT32 driver that operates on IDE ports directly which I once wrote. Perhaps could be useful for such competition.

Yeah, I have also seen the scare stories about damaging hardware with RAM probes, but I doubt they are true. However if you feel strongly about not probing, then just limit the RAM usage to 1MB.

The most important part is that it doesn't actually work. REAL OSes (like Linux) use the bios for this.

Well there is some commonality between display boards and register settings. (Hint: Go and look at the old VGA specs). If you can figure out a way to set up a nice high-res mode then that would be potential for a few extra votes. It was a common thing to do in the old DOS days where each program had to figure out your display hardware and act accordingly.

Use you imagination. There is no reason why an app running under your OS can't be run by the user with switch settings to say what display modes it wants. Perhaps you can include drivers for some of the more common displays and the user can command the OS to switch modes after start up. Think outside of the rectangle, there will be a way.

So, the MBR is allowed to use the BIOS? (Rules indicate non-BIOS use begins at boot sector. )

I consider the MBR to be the boot sector. It is the sector that is loaded by the BIOS and the point at which the BIOS relinquishes control to your code. Once your code gets control then the BIOS is out of bounds.

revolution:
is it possible to allow the usage of INT13h in the MBR because if we want it to be a real OS, we need to be able to load the second stage from any volume supported by BIOS transparentlly.
and it is very impossible to make a generic disk driver able to read from floppy, harddrives and usb pens within the 512 bytes MBR.
then, this part should use the BIOS INT13h and maybe INT10h just to switch in the wanted screen mode.
after MBR, it will be totally forbiden to use BIOS code, even copying the code somewhere else and use it as a non bios code.

but i repeat, if we want to be able to load second stage from the current drive transparently, we should use the bios.

But the MBR is usually just mostly empty. A few lines to find the active partition, load a sector, jmp.

I tell you what, as a compromise, if you find this part too onerous, entries will be accepted that allow the MBR to use INT 13h if and only if the MBR is a standard, simple MBR that has one purpose: to load your single boot sector into memory from the active partition and jump to it. From there you are not permitted to use the code from the MBR (i.e. the calls to INTs etc.) that is in the memory.

We can call this the "edfed MBR variation". And all entries must clearly state if they are using the "edfed MBR variation".

Is that acceptable? I don't want to make it such a burden so I'm okay to compromise on some things.

But just to know that I have done this myself under the original rules (yes I tested that it can be done before posting) so this change is not really needed.

BTW: There is no requirement for the OS to support partitions/MBR. Up to you.

but, then, we will be forced to create at least 3 MBRs.
one for the HD from IDE
one from the HD from SATA
one for the floppy.

and then, to test the os, we will have at least 3 images, one for a sata drive, one fro a ide drive, and one for a floppy drive.

edfed: I don't get you meaning. Why are you forced to create so many MBRs?

I thought by definition you can only have one MBR.

one mbr on the drive, but wich drive will be used?
if i use floppy for tests, i will use a floppy mbr
if i use the hd for definitive use, i will have a ide mbr.
etc etc.

Up to you how you want to organise your code. But there is not any requirement to support multiple booting environments either. I have left all these small details for you to decide.

I think you are trying to run before you can walk. Would it not be best to get something working first before starting to support alternative booting scenarios? Anyhow, like I said, it is all up to you.

Learn CD ROM boot spec. EL TORITO, you can tell at BIOS
when boot from CD how many virtual sector ( 512 byte) load to 7C00 or also
choice another address for your Boot
Of course you must write a manual ISO compilant with
EL TORITO.
Firts Hacker then programmer

Which violates the rules because them state that the BIOS must load no more than 512 bytes.