flat assembler
Message board for the users of flat assembler.

Index > OS Construction > Should the 512b compo be changed to over 512 bytes

Goto page 1, 2  Next

Should the 512b Compo remain at 512 bytes ?
Yes
68%
 68%  [ 17 ]
No
28%
 28%  [ 7 ]
There should be no 512b compo
4%
 4%  [ 1 ]
Total Votes : 25

Author
Thread Post new topic Reply to topic
Dex4u



Joined: 08 Feb 2005
Posts: 1601
Location: web
Dex4u
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.
Post 01 Jul 2005, 09:32
View user's profile Send private message Reply with quote
smiddy



Joined: 31 Oct 2004
Posts: 559
smiddy
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.
Post 01 Jul 2005, 11:24
View user's profile Send private message Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 878
Location: Colombia
pelaillo
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....
Post 01 Jul 2005, 13:02
View user's profile Send private message Yahoo Messenger Reply with quote
Octavio



Joined: 21 Jun 2003
Posts: 366
Location: Spain
Octavio
Dex4u wrote:
what do you think and would you like another compo ?.
.

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.
Post 01 Jul 2005, 13:13
View user's profile Send private message Visit poster's website Reply with quote
Dex4u



Joined: 08 Feb 2005
Posts: 1601
Location: web
Dex4u
@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 Wink
Post 01 Jul 2005, 15:45
View user's profile Send private message Reply with quote
dasyar



Joined: 27 Feb 2005
Posts: 33
dasyar
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.
Post 01 Jul 2005, 21:16
View user's profile Send private message Reply with quote
crc



Joined: 21 Jun 2003
Posts: 637
Location: Penndel, PA [USA]
crc
Quote:
eg: If i where to make a pmode floppy driver, that fits in 512bytes, that would help OS Dev


Perhaps. But a 4k pmode floppy driver with good commenting would be a bigger help IMO.
Post 01 Jul 2005, 22:22
View user's profile Send private message Visit poster's website Reply with quote
Octavio



Joined: 21 Jun 2003
Posts: 366
Location: Spain
Octavio
Dex4u wrote:
last years winner demo, multitasking in 512bytes, second place demo enabling vesa, going to pmode, bit fonts and a basic ATAPI driver
but is someone using this code?
Quote:

, and a pacman game is a about the same as tetris game in size,


see compo 22
http://www.hugi.scene.org/compo/compoold.htm#compo22
Post 02 Jul 2005, 09:23
View user's profile Send private message Visit poster's website Reply with quote
Dex4u



Joined: 08 Feb 2005
Posts: 1601
Location: web
Dex4u
@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
Post 02 Jul 2005, 10:54
View user's profile Send private message Reply with quote
zhak



Joined: 12 Apr 2005
Posts: 490
Location: Belarus
zhak
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.
Post 02 Jul 2005, 12:06
View user's profile Send private message Reply with quote
Dex4u



Joined: 08 Feb 2005
Posts: 1601
Location: web
Dex4u
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.
Post 02 Jul 2005, 12:30
View user's profile Send private message Reply with quote
drh3xx



Joined: 11 Sep 2004
Posts: 34
drh3xx
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?
Post 02 Jul 2005, 19:25
View user's profile Send private message Reply with quote
DennisCGc



Joined: 03 May 2004
Posts: 24
Location: Zoetermeer, The Netherlands
DennisCGc
mm, some questions and thoughts from me:

Quote:
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.


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 Smile)

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

'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.
Post 02 Jul 2005, 23:31
View user's profile Send private message MSN Messenger Reply with quote
YONG



Joined: 16 Mar 2005
Posts: 8000
Location: 22° 15' N | 114° 10' E
YONG
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
Post 03 Jul 2005, 14:33
View user's profile Send private message Visit poster's website Reply with quote
Dex4u



Joined: 08 Feb 2005
Posts: 1601
Location: web
Dex4u
@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.
Post 03 Jul 2005, 16:37
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
i agree with YONG too
Post 03 Jul 2005, 18:25
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
And proably there won't be as many entries to split them into categories.
Post 03 Jul 2005, 19:26
View user's profile Send private message Visit poster's website Reply with quote
YONG



Joined: 16 Mar 2005
Posts: 8000
Location: 22° 15' N | 114° 10' E
YONG
Quote:
... some entry's may come under more than one category ...

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.

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

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
Post 04 Jul 2005, 05:22
View user's profile Send private message Visit poster's website Reply with quote
adefeo



Joined: 12 Jan 2004
Posts: 46
Location: Bellmore, Long Island, New York
adefeo
YONG wrote:

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.


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.
Post 04 Jul 2005, 07:34
View user's profile Send private message Visit poster's website AIM Address Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
YONG wrote:
I'm for keeping the 512-byte limit, which tests our skills to write compact and highly optimized code.

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. Smile
Post 04 Jul 2005, 17:34
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.