We've had the 512 byte OS contest, the micro OS contest. Well now is the REAL OS contest.

REAL means you are not allowed to use the BIOS to help you, not for anything whatsoever. Not even one INT xx where xx<32. Also calling the BIOS ROM directly with call yyy is not permitted.

If you need to read the keyboard, then write some keyboard routines. Need to access the screen, then write some screen routines. Need to access the HDD, then write some HDD routines. Need to check for RAM size, write some RAM finding routines. etc.

So the challenge here is that the BIOS will load the boot sector (a sector of your making) into memory and execute it. From the very first instruction is where no BIOS calls are allowed. If your OS needs more than 512 bytes loaded from disc then write HDD I/O routines and load in more sectors.

After that you must provide for applications to access the system resources (screen, keyboard, HDD, etc.) through your OS only. The apps are not allowed to call INT xx with xx<32 and are not allowed to do direct I/O (i.e. not allowed to do IN or OUT). The apps must use your OS for all I/O. You don't have to write any apps, but to give others a chance to test your OS you might consider writing a few simple things, up to you.

So that makes it a REAL OS because it needs nothing more than some execution time and the hardware. The BIOS is only there to load the first sector (your boot sector), and after that the BIOS is never used.

Small print: There is no size limit. There is a time limit of 6 months from today. Entries will be judged by public voting from established forum members only (no new registrants may vote (to stop vote stuffing, okay)). All source code must be released into the public domain for an entry to be valid. Source code can be kept secret (if you want) until the closing date, but after that it must be revealed in full to make your entry valid. All code must be written 100% fasm compilable. The basic hardware system minimum is a freely available VM of your choosing, or real hardware if you so wish. If your code is so specialised that it requires some special hardware to run then most probably other forum members won't vote for it because they can't run it, so it might be a good idea to make it as generic as possible. If you try to sneak in a disguised BIOS call (with equ or a macro or something) then your entry will be disqualified (the members here are smart so they will know if you have done such a thing). If there is only one entry it will win by default. If there are no entries then I am sorry I wasted your time. Most importantly good luck and have fun.

Can you do it?

Hi revolution,
you forgot efi/uefi, modern motherboards have this feature and it is meant as replacement for BIOS-es.
I have same efi samples written in fasm but I'm unable to test them (I don't have efi/uefi motherboard yet).

efi/uefi is e.g. capable to load the whole file from FAT filesystem and execute it at boot stage, the file may have quite big size so there is plenty of space for code for handling hardware. A lot of things like reading/writing disk, keyboard input etc may be called directly from efi/uefi.

Okay, thanks. Obviously using the EFI/UEFI thing is not within the scope of this contest. I am intending that the BIOS (or whatever mobo boot system) will load only a single 512 byte sector from disc. I did say this: So I think that should cover it.

edited as irrelevant, unlike all may other posts...

Done. Thanks.

Thanks, revolution for this outstanding submission to the forum. The contest rules were extremely well written. Great job.
Thanks, Feryno. Umm, what's going on these days with UEFI?

The original specs were published, if I recall correctly, in 2006 by Intel, right? Then, about a year ago, I seem to remember,
version 1.1 was introduced. Wait a minute.

ah yes, the official web site:
uefi specification 2.2
So, is this vapor ware? Still no motherboard? I thought that was the problem last summer in Las Vegas at the Black Hat conference?
Moreover, I thought that UEFI was intended not as a replacement for BIOS, i.e. that both would be coresident, and in that scenario, revolution's excellent contest would still be valid, even on a uefi motherboard. Holy Cow. You mean I will have to actually read the specification to find out...Gosh. What novelty....

Haven't read it yet, but, looking at the table of contents, it would appear that protocols exist for PCI, SCSI, USB, but didn't see anything for SATA drives, nor for Apple's Firewire. The network protocols looked botched, to me, i.e. I didn't see a true seven layer OSI model, just the usual USA designed shortcuts.
All in all, I may have to actually read this thing to find out what is going on. Very tough, since a large part of the supposed specification consists of C gibberish.

EFI and UEFI are not compatible with MY hard ware, and i doubt it is compatible with hardware of every participants.

i will participate to this contest, and i'll win!

Best of luck to you edfed.

thanks.
i start to code this so needed/waited/wanted file system support, and try to don't deviate from this objective .

I think I will try this contest I have learned alot, since I made that ugly contest that is just taking up space on the flat assembler servers

Best of luck to you Coddy41.

Is it OK if I use the drivers I have already written?

everything is OK, you can use code from everybody/everywhere.
and don't think it is simple, all the job is to make the best OS of this contest.

the only 2 rules to respect are:
code it with fasm.
don't use any BIOS INT.
but, you can rewrite INTs, like INT10h or INT13h .

Yes, use whatever you have. No restrictions.

The main test to get the OS together and working. So you can use bits of code from this board, or anywhere (if it meets the rules of 100% fasm compilable). However before using someone else code make sure it is in the public domain, and make sure it does what you think it does (i.e. test it thoroughly else some ugly bug may catch you out).

Oh, It is in the Public Domain, (GNU public domain) And 1005 FASM
http://dex.7.forumer.com/viewtopic.php?t=385 here my current OS

Are you sure it doesn't use any BIOS calls? If it does then you would be disqualified So, like I said, be careful with using someone else's code.

Um... I will go through it, patch it, It still is in Beta... now that I think about it, it does have a Bios call... It has no FDD dirver.

BTW: I don't think the GNU license is public domain, it has restrictions and conditions etc. Read the rules carefully, you wouldn't want to be disqualified on a technicality

What about... NO LICENSE!!! Its perfect, if I don't protect my work... WHO CARES!!! YAY!! will that work?

Yes, if all the code is able to be released as "no license" then fine.

But you can't just take some GNU protected code and re-release it as no license. Not allowed, and also not good manners towards the original writer(s), they might get angry with you.