512b Operating System Contest
http://512.decard.net

512b contest is an open competition, which goal is to create an operating system that will fit in one sector (512 bytes).

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 entries, must provied source code for there 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.
  

Good luck!

so you can decompress to ANY size

Jaques wrote:

so you can decompress to ANY size

But the problem will be fitting in the decompressor and the decompression source into 512 bytes...

Just remember that you only have 510 bytes to play with... since the last 2 bytes should be the boot signature (AA55h).

I'll see what I can do...

If you don't mind, I'll post this to news://alt.os.development. Some of the guys there are really good...

The more the merrier .

\\\\||////
(@@)
ASHLEY4.

[quote="decard"]512b Operating System Contest
http://512.decard.net

512b contest is an open competition, which goal is to create an operating system that will fit in one sector (512 bytes).


(kernel+aplications )<512 bytes or only the kernel is limited to
512 bytes?

Whole OS is limited to 512 bytes. Actually it is to small to code anything very complicatd, you need to think of some good idea, what your OS will do.

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 (512bytes) and is self booting.

\\\\||////
(@@)
ASHLEY4.

decard wrote:

Whole OS is limited to 512 bytes. Actually it is to small to code anything very complicatd, you need to think of some good idea, what your OS will do.

Then is a 512 bytes demo not a OS , just like a DOS .com program that only uses bios functions, and there are many demos that could reach the requirements with a minimum changes.

OS must do nothing by itself ,a simple OS loads
aplications and provide some IO services to this aplications.

actually you're right: it is a demo. But it works in special conditions (no DOS interrupts available, etc) so looking at this side it can be called an OS. But it doesn't actually matter how do you call it

The idea is very much like a demo, but demo's are to show what good graphics and sound you can fit into a small size.
This is the same, but we want to show what small floppy,hdd,cd,mouse,keyboard drivers and menu's and image viewer's etc, we can fit into 512bytes and if we make it look nice, then we get more vote's.
The entrys may not be a usefull OS in them selfs, but put togeather they may make a very small usefull OS, + we can all learn from it.

PS: Remember it was because of a little OS, that we have Fasm.

\\\\||////
(@@)
ASHLEY4.

If the small demo is able to operate your system, then it is an OS.
Nobody expects an OS to work with or to operate all the hardware, but it is interesting and creative.

This reply is from Ben, an alt.os.development subscriber:

> For those interested, one of the FASM board members is running a Create an
> OS competition... details can be found here:
> http://board.flatassembler.net/topic.php?t=2164
>
> Anyway from the post:
>
> 512b Operating System Contest
> http://512.decard.net
>
> 512b contest is an open competition, which goal is to create an operating
> system that will fit in one sector (512 bytes).
>
> Rules:
>
> a.. Valid entries are those submitted at http://512.decard.net before
> 1/10/2004 00:00 (GMT)

(1st Oct 2004)

> b.. The maximum size for all code and data compiled, is limited to 512
> bytes, but there is no limit on size of memory used.

Which means that we can not assume anything about any of the data on
the remaining sectors of the disk.

> c.. The OS should be stand alone and boot without any external assistance,
> but use of BIOS is allowed.
>
> d.. 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.
>
> e.. 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.
>
> f.. There is no limits to the used algorithms or data compression as long
> as decompresser fits within given limit.
>
> g.. The winner is defined by public vote and arbitrated by me (decard)
>
> h.. All entries must be able to be assembled with Fasm .

This I have to ask why? I have an idea, but is this a *must*.

> i.. All entries, must provied source code for there 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.
>
> j.. 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.

I think all should be allowed to enter, just have to be a member to vote.

> Just for those interested...
>
> --
> Darran (aka Chewy509)...

Now for the assumptions:
- what can we assume about register contents upon execution
of first instruction of our code?
- dl = disk drive
- usually, but not always, ds = 0x0040
- will a valid stack be setup
I would say that only DL can be assumed, and we must
set up a valid stack if we use a stack.
- Do we have to have the JMP xx/NOP bytes at the first?
- Can we assume it is a 1.44meg floppy?
- Can we assume that the text display is valid and at 0x0B8000?

A few other rules we may consider:
- The a20 line may not be assumed set.
- The processor will be in real mode, not unreal mode.

Anyway, I just had a few minutes to comment about this contest.
It sounds interesting.

Thanks,
Ben

Back to me now!
Also, is it possible to allow exceptions to "must be board members" rule?

Chewy509...

Quote:

Now for the assumptions: - what can we assume about register contents upon execution of first instruction of our code? - dl = disk drive - usually, but not always, ds = 0x0040 - will a valid stack be setup I would say that only DL can be assumed, and we must set up a valid stack if we use a stack. - Do we have to have the JMP xx/NOP bytes at the first? - Can we assume it is a 1.44meg floppy? - Can we assume that the text display is valid and at 0x0B8000? A few other rules we may consider: - The a20 line may not be assumed set. - The processor will be in real mode, not unreal mode.

My interprentation of the rules are: the default startup state of Bochs is good to assume, you are confined to the 512 byte sector loaded by BIOS (thus the size of the fdd is irrellevant - as it's (>512B) "out-of-bounds"). The processor will likley be in the start up state (real mode), A20, *should* be initally off (remember _compabillity_).
I think 0x0B8000 can be assumed "true" (afaik it's "stanard", isn't it?)
dl, isn't that always set to the boot disk drive?
jump/nop? That's up to you, 'data' at the start or not...

so in short: do what ever OS you can with 512 byte using fasm.

What about the file system? Every OS have at least one? (IMHO) Can we use the remaining storage of the diskette for file system space?

What about processor requirements (FPU, MMX)?

>(IMHO) Can we use the remaining storage of the diskette for file system space?
in my interprentation you could do that (as long as you keep all code+data under 512 byte on the disk (you could create an fs in the memory, sort of "ramdrive")) , you could also simply make all the rest an array of zeros or some fancy strcut with zeros

JohnFound wrote:

What about the file system? Every OS have at least one? (IMHO) Can we use the remaining storage of the diskette for file system space?

You can use the rest of the floppy, but then your 512 byte kernel would need to format it - we assume that the environment is "clear" - no any filesystem, just blank space

Privalov wrote:

What about processor requirements (FPU, MMX)?

Right, we should have thought about it before (and mark it in the rules). But it's just out first compo, in next ones we will prepare the rules better
Now let's give a limit to 486 instruction set and FPU - I think it is enough for an OS. Shall I add it to the rules?

The mane rule for the rules, is "KISS", it seems people are getting a bit carred away.
First people are going on about a OS, it's more parts of a OS, as in the winner will be the one judged to of fitted, the most parts of a OS or the best single part of a OS into 512byte's.
As for using the rest of the disk etc, the rules say you can use a program on say the floppy or cd to demo, that your OS can load from these drives, but what it loads can have no bearing on the out come of the compo.

As for the rest there is NO restrictions on instruction set's etc, it is in the participant's
interest to make it run on as many processor has possible, if it does not run on say, my pc then i will not vote for it, so it up to the participant to make it run on the widest number of pc.

\\\\||////
(@@)
ASHLEY4.

Chewy509 wrote:

Now for the assumptions: - what can we assume about register contents upon execution of first instruction of our code? - dl = disk drive - usually, but not always, ds = 0x0040 - will a valid stack be setup I would say that only DL can be assumed, and we must set up a valid stack if we use a stack. - Do we have to have the JMP xx/NOP bytes at the first?

1) Not all BIOSes init DL to boot drive
2) AFAIK DS is 0x0000 not 0x0040
3) Stack should be safe if you don't use any "free memory" (outside bootsector and system areas, like 0x0040) below 1 MiB as you don't know where BIOS put that stack. Well, you can check that, but "mov sp, your_addr" will take less bytes.
4) Why do you need JMP xx/NOP bytes at the first? That's only required for FAT and derivatives (like HPFS).