Here are last year's rules:


Rules:

• Valid entries are those submitted at http://512.decard.net before 1/10/2004 00:00 (GMT)
  
• The maximum size for all code and data compiled, is limited to 512 bytes, but there is no limit on size of memory used.
  
• The OS should be stand alone and boot without any external assistance, but use of BIOS is allowed.
  
• The winning OS will be the one, judged to have the largest number of different features, or the best single feature, that fits in the given limit and is self booting.
  
• It is in the interest of the participant to make it run in BOCHS, as this is what most people will test it with, but not mandatory.
  
• There is no limits to the used algorithms or data compression as long as decompresser fits within given limit.
  
• The winner is defined by public vote and arbitrated by me (decard)
  
• All entries must be able to be assembled with Fasm .
  
• All competitors must provied source code for their OS, but not until, after the 1/10/2004 00:00 (GMT), if after 1/10/2004 00:00 (GMT) the winner does not provide the source code they will be disqualified.
  
• Only Fasm Forum Members will be allowed to enter and vote, no participant can vote for there own entry, and each member is limited to one entry.
  

Most of them proably are OK, just now each competitor can submit up to 3 entries (one in each category). What do you think about them?

-Well obviously #1 must be changed to the correct date and time. And http://512.decard.net/ is a dead link, so you'll have to modify that (or make the link "alive").
-IMHO #2 should be changed to "510 bytes" since we need a 55AAh at the end, and therefore only 510 bytes can actually be used.
-#3 should be changed to "Other than BIOS the OS must be standalone and boot without any external assistance."
-I can't figure out #10, please clarify!
-The second part of #11 ("no participant can vote for there own entry") is impossible to enforce, correct? So maybe this should be taken out, since it is a rule that can easily be broken by anyone. Besides, if every participant votes for their own entry, then it won't affect whether someone wins or loses, because the count of votes for each person will be one more. Besides, this would throw the correctness of the poll off if participants are allowed to vote for the entry of someone else, but not for their own entry.

Also, #11 should mention that only FASM Forum Members may enter the contest - I assume this is true; if non-members can't vote, why should they even be allowed to enter the contest? Besides, most FASM users are already members, and other languages aren't allowed, as #9 states.

With these exceptions, the rules are already clear and understandable, and other than making these ammendments I would say they are good enough.

But nothing prevents you from using those 55AAh as actual data in your code

No, but it's not likely that anyone would need to do that, want to do that, or have any reason to do that. You could say

or something to that effect.

I think the rules look good, baring any hair splitting.

We are going to keep the same rule as last year, but add that there are three
category to enter:

- operating systems
- applications
- games

You can enter up to one entry per category.
Members can vote for the best one in each category.
The winner from each category, will then become the other all winner, by have the highest number of votes, from the category winners
each one will be placed first, second, or third.

And the prize is you beat your fellow programmers

If I win, I want to beat my fellow programmers with a wet noodle.

i hope usage of FPU, MMX, SSE etc. is allowed (it'll be more interesting...)

@vid, it is up to you, but if they do not work on old PC, that people test the entry's on, they will not vote for you, so its in your interst to make you entry run on as many PC as you can .

I will check this by checking user's IP number. I know that it is easy to cheat, but we do trust each other, don't we?

You're right about 510 bytes, of course. But 512 is just a nicer number (0x200 to 0x1FE)

It should be enough to say that the output file should be exacly 512 bytes and it should be able to boot without any additional assistance.

I don't think that it is a good idea. I like Bochs, but it is very buggy, yet.
I use Virtual PC, VMWare and Bochs together, and Bochs fails to execute a part of my code. An example is sending IDENTIFY PACKET DEVICE to a cd-rom in Bochs 2.2. It returns smth like "a command is issued to a non-disk". It doesn't support some BIOS interrupts as well. And it emulates ATA-2 hdds as I know, but I'm not sure for 100%. VMWare does everything well. It is number 1 for me.

That's another issue. Bochs was just an example. It has an advangae that it is freeware, and easy to use. I'm planning to place sample Bochs script on compo's website so it would be easier to test entries. If someboty prepares some scripts for VirtualPC or VMWare, I will put them there too.

and

lead me to believe that this rule should be more broader, such as:

Actually, this is more of a suggestion or recommendation, so you might want to leave it out of the rules (or create a separate section for it and other suggestions that aren't necessarily rules).
You might mention that Bochs is used by a lot of us forum members, and may be used during testing, instead of a physical PC. However, if it works in Bochs but not in a physical PC, that's even worse than the other way.


Agreed. Tomasz Grysztar, you have a way with words!