This years 512b compo will be started on the 1 AUGUST 2005 and end on the 1 OCTOBER 2005, but some people want to expand it to say 2k, what do you think and would you like another compo ?.
I posted this to get peoples ideas before the compo starts.

Well, unlike my previous post in the other thread, I think it is probably best to keep in one sector or 512 bytes. This limits the amount of stuff that can be crammed into an OS. Though I wonder, is that everything or just startup and kernel? Perhaps installable devices could be used too? Just a thought, since a practical OS would have basic IRQs, a console at the very least. Hey, maybe that's it, define the basic requirements and see who does it the smallest:

kernel ; manages devices (no APIs)
console ; interface between user and screen and keyboard minimum
ability to load a flat file to run.

Just thoughts...comments, gripes, etcetera are very welcome.

Hey, this year we could move into another quest:

I propose a compo of making an efficient file system for "hobby" OSes.

The rules are almost the same but without size limitations. The smaller/quicker among the most featured is the winner.

October 1st seems a good deadline and lets the tradition continue....

What about doing something useful?
Like a true type font renderer, usuful for those of us that are developping a OS.
Or some libraries like prinf,malloc,graphics etc useful for all programmers, is the fasm library already dead?
Or a small game like PACMAN ,there are already to many versions of tetris.
Or a very simple 3d engine.
I don´t like to spend a lot of hours writing a useless demo.

@Octavio, thats the point, you can do all those things in 512 bytes, last years winner demo, multitasking in 512bytes, second place demo enabling vesa, going to pmode, bit fonts and a basic ATAPI driver, and a pacman game is a about the same as tetris game in size, so any of those things you can make.
And the idea is to make a bootable part of a OS, that way you know the code is self contained.
eg: If i where to make a pmode floppy driver, that fits in 512bytes, that would help OS Dev

Let me put in my idea; since their is a lot of interest in the protected mode area, I propose an OS contest with the following criteria:
1. Access to FD or HD
2. Functional keyboard
3. Functional monitor
4. OS to RESIDE within a 1024 bytes of memory
5. Of the 1024 bytes, 150 or 200 bytes reserved for running a program.

Something like this would force tight code; probably display some unique code styles, would address things like file system, memory mangement, possibly creation of files, ..., etc.

Perhaps. But a 4k pmode floppy driver with good commenting would be a bigger help IMO.

but is someone using this code?


see compo 22
http://www.hugi.scene.org/compo/compoold.htm#compo22

@Octavio, yes lots of people use the cdpod code, i do not know about the rest.
I agree with crc, that to be more helpfull to OS Dev's, it needs to be bigger.

I propose use "bootprog" for the compo, this is a boot loader that loads a com or mz exe from the floppy.
We could restive the com file size to 2k. the rule would be that the com file must be 2k in size, but it can use as much memory as it wants, it must be self contained and use no other out side OS function other than BIOS.
People will be able to run the com file in windows, dos, emulator etc.
but to win it must boot from the bootprog floppy.
You can get more info on bootprog here: http://alexfru.chat.ru/epm.html#bootprog

To my mind it is better to compete in creating something that could be useful. Not an OS, but, for example one driver or, as Octavio said, font renderer or smth. else and to make it as small, and quick, and stable (and fully functional according to the task) as possible. The TASK can be loaded with a predefined loader to make things organized.

I will say this once more and i have said it from the beginning, the compo is not to fit a OS in 512bytes, but to "FIT PARTS OF A OS IN TO 512 BYTES" , a driver is part of a OS, is that not clear enough.

And the basic idea was to compeat with one another, and may be usefull, but now the enthusiasm is more on being usefull to OS Dev's.

I voted to change size from 512B.
I think 2KiB is a better size to aim for as it means less pressure to use BIOS calls to save space.
Also perhaps the 2KiB limit should only be for the kernel itself?

mm, some questions and thoughts from me:



What do you mean? Just a design or a fully-working implementation? Does it have to be only efficient or some cool features? Is it okay to include an VFS?

Thoughts:

designing a FS is great, but that's not programming, more designing.
games programming, could be.

I rather suggest something that's useful, or at least workable. (a bit like Zhak said). Another option would be something to create a simple OS that demonstrates a driver. (protected mode )

(Or we just could post our OSes , but I would definetely lose )

'bout the size; mm, depends what the project is going to be. Of course, how smaller it is (and it should be workable/useful) the better it is.
Again, depends what the project is going to be.

DennisCGc.

I'm for keeping the 512-byte limit, which tests our skills to write compact and highly optimized code.

Also, I think we could divide the contest into, say, three categories:
- operating systems,
- applications, &
- games.
And there would be a winner in each category.

This would create a relatively fairer platform for the contestants to compete with each other and would make it easier to judge the submissions.

YONG

@YONG, I agree with you, but some entry's may come under more than one category.
eg "CdPod" would come under "applications" as a cdplayer and operating sys for the vesa and ATAPI driver.
So the person entering the compo would after state the category.

i agree with YONG too

And proably there won't be as many entries to split them into categories.

Right. The contestant should, based on the unique feature of his/her submission, pick the appropriate category. Arguably, since all submissions would have the basic bootloader feature (i.e., having the boot signature at the end), they could all come under the OS category. To me, "CdPod" would be more like an application than an OS.


It's difficult to say. Perhaps we can set up a poll to see how many members are going to take part and in what category.


YONG

I think that there will still be a fair amount of entries. I MIGHT enter, not sure if I'm going to yet.

Anyway, I set up a poll about this, I hope you don't mind, Dex4u, since it is sort of your compo.

I cast a no vote in the poll above, and disagree with Yong and Vid, et al, in fact, refused to participate in last years competition, because the notion of restricting the size of the entry seems to me to be both childish, and counter productive.
This is not 1969.
Maybe 36 years ago, MAYBE, back then, for lunar spacecraft, it was important to write: "compact and highly optimized code...", but today, in the real world, with real employment opportunities, it is necessary to:
1. NOT WRITE CODE, but instead create programs.
2. NOT WRITE in a "highly optimized", but rather in a highly READABLE manner.
3. NOT WRITE "compact", i.e. saving memory, but rather write USING MEMORY GENEROUSLY, because there is a lot of it, and it is free. By implication, one would use ARRAYS, not pointers, because there is no benefit from using pointers. What, Speed of execution??? Yeah, perhaps, but that's not important. Readability, and more importantly MODIFIABILITY is crucial in software development, not speed of execution. If one genuinely needs speed faster than 3 ghz, why bother with Intel/AMD?. It is difficult to modify arrays of pointers, and structures with pointers to arrays of pointers. It is SO MUCH EASIER TO READ if data is presented in tables and arrays, than if presented as dynamically allocated structures defined by a single pointer. Of course, that will eliminate LOTS of famous intel instructions won't it? In fact, whole modes will disappear. There we have it: a useful competition: WRITE AN OS using only DIRECT MODE programming, no pointers, with a maximum of 40 different instructions. Ah, that will be challenging.
So, instead of thinking that assembly language is the language of choice for developing applications that can fit on a single "sector", i.e. presumably some ancient component of a long since obsolete DOS specification, why not a competition to see who can write:
NOT THE FASTEST,
NOT THE MOST COMPACT,
NOT THE MOST OBSCURE,
but rather, the most readable, most easily modified (portion of) component of an operating system--one which is so transparent that ANYONE can understand how it works.
For those who imagine that compact, concise, code is preferable to verbose, well documented PROGRAMS, please check the advertising section of your local newspaper to see how many employers seek employees who have mastered the art of keeping to themselves what they propose to accomplish for the company, by writing CODE, that is understandable to only themselves.
I can honestly write, that I do not find it "skillful" to create: "compact and highly optimized code", particularly if "optimized" is defined as meaning FASTER IN EXECUTION.