Index
> OS Construction > OS Doesn't print string!!!Goto page Previous 1, 2, 3, 4 Next |
| Do you think that it is possible to create a semi-useful OS in 512 BYTES??? | |||||||||||||||||||||
|
|||||||||||||||||||||
| Total Votes : 40 |
| Author |
|
|
ASHLEY4 13 Aug 2004, 13:40
I think that all OS entered should be assembled with fasm (as this is a fasm forum) and no external compressing programs can be used or run over OS to compress it.
But this type of code, should be allowed. Code: mov cx,0xffff mov al,20 rep stosb As this is technically decompressing on the fly. Also i think that we should be allowed to use floppy, hdd, cd, etc, as part of a demo of what the OS can do. eg: you can load a program from a floppy, to show that your 512 byte OS can do that, but what it loads can have no bearing on the compotion. \\\\|//// (@@) ASHLEY4. |
|||
13 Aug 2004, 13:40 |
|
|
pelaillo 13 Aug 2004, 18:19
ASHLEY4 wrote: Also i think that we should be allowed to use floppy, hdd, cd, etc, as part of a demo of what the OS can do. Yes, I fully agree. The idea of allow compression is because it is difficult to state when a decompression occurs, as in ASHLEY4's example. In the other hand, ensuring that everything is within 512 bytes is easier imho. And because it adds some more chilli to the sausage.  |
|||
|
13 Aug 2004, 18:19 |
|
|
decard 13 Aug 2004, 20:06
I made some simple tests with compression (zip, aplib and my own lzss library) and actually it was difficult to pack 512 byte bootsector, to gain enough space for decompressor code. Maybe some other algo would give better results? IMO allowing compression could bring new ideas about packing small ammounts of data to the light
Also, what about creating one bochsrc.txt file that all oses in contest will use? All projects would run from the same configuration... |
|||
|
13 Aug 2004, 20:06 |
|
|
ASHLEY4 13 Aug 2004, 23:37
I have been doing some test's, on idea's i have for the compation, and i must say it's not going to be as easy as i thought
 .
\\\\|//// (@@) ASHLEY4. |
|||
|
13 Aug 2004, 23:37 |
|
|
compilax 14 Aug 2004, 01:07
How about "smallest OS that meets these requirements: some kind of filesystem other than the user saying 'load sector 762', some kind of ABI allowing use of the filesystem, etc..."?
The rules would be a bit more complex, but the results would be far more interesting if code was still meant to be tiny, but not limited to 512 bytes. |
|||
|
14 Aug 2004, 01:07 |
|
|
crc 14 Aug 2004, 01:11
Or maybe a series of competitions with varying size limits: 512 bytes, 1k, 2k, 3k, 4k (including boot sectors)?
|
|||
|
14 Aug 2004, 01:11 |
|
|
crc 14 Aug 2004, 01:18
Quote: I have been doing some test's, on idea's i have for the compation, and i must say it's not going to be as easy as i thought . I'm finding it hard to fit things in as well. I have a console driver (keyboard + text screen), 32-bit pmode (linear memory), etc in 469 bytes (slowly being pared down), but it's not useable yet. Another 200-300 bytes would fit my HDD driver too... Maybe I can pare this down enough to be a usable monitor though. It's going to take a while... |
|||
|
14 Aug 2004, 01:18 |
|
|
compilax 14 Aug 2004, 02:33
MenuetOS kernel is ~90kb, and it has sound blaster, HD support, GUI, etc.
old Unix kernels* written in C were small: - 5th edition Unix: "The kernel's image size was around 26 Kbytes" - 6th edition Unix: "The kernel's image size was around 29 Kbytes" - 7th edition Unix: "The kernel's image size was around 51 Kbytes" Although a kernel can be quite small, I think, for x86 at least, 512 bytes is too small to get anything interesting. Too much space is wasted switching into pmode (if used), and read/write filesystem stuff would be hard to squeeze in. maybe 512 byte bootloader and 10kb kernel+data+apps? that would allow for a small shell and filesystem and drivers. Also, it may be large enough to make compression worthwhile, which will zest it up a little. I see an opportunity for a lot of people to get past the "hello word" stage if there are lots of people doing different small OSs at the same time - because everyone will be discussing how to get past various obstacles, and a lot of people will be left with a base for a better OS, along with all the other kernels/OSs from the competition as a reference. I think the last thing the OSdev community needs is _more_ real mode OSs that can use a floppy without a filesystem. It just keeps people thinking an OS = a very simple CLI that allows you to cryptically use the floppy and gives people the assumption that making something with a GUI or CD drivers is way too hard for anybody without the resources of a huge company like microsoft. It doesnt exactly throw up much innovation either. I think the osdev community does need more intermediate projects though - something between an Altair demo program and FreeBSD onto which people can build a better OS. *information about Unix from http://minnie.tuhs.org/UnixTree/ |
|||
|
14 Aug 2004, 02:33 |
|
|
crc 14 Aug 2004, 11:28
Quote: old Unix kernels* written in C were small: They also ran on non-x86 architectures that allowed denser code
Quote: Although a kernel can be quite small, I think, for x86 at least, 512 bytes is too small to get anything interesting. Too much space is wasted switching into pmode (if used), and read/write filesystem stuff would be hard to squeeze in. My init+switch to pmode is 80 bytes, leaving 430 bytes for me to use. I think a useful monitor program can be written in 512 bytes. Nothing fancy, but enough to load files off a filesystem and run them. On the other hand, embedding games or simple programs in a boot sector could be quite interesting. Quote: maybe 512 byte bootloader and 10kb kernel+data+apps? 10k allows for a lot. An older version of RetroForth/Native was ~10k, and provided a full Forth system, editor, debugger, and persistant data storage via hard drive in that amount of space. These days I could fit even more functionality into it. But 10k defeats the goal of minimalization. The idea is to test programmer skill by setting extreme limits and seeing what can be done within them. I say let's do a 512-byte OS competition. Later do others with varying sizes (1k, 2k, ...) and see what can be achieved. At least it would provide us with a way to determine the minimal amount of space needed to provide a "real" OS
Quote: I think the last thing the OSdev community needs is _more_ real mode OSs that can use a floppy without a filesystem. It just keeps people thinking an OS = a very simple CLI that allows you to cryptically use the floppy and gives people the assumption that making something with a GUI or CD drivers is way too hard for anybody without the resources of a huge company like microsoft. It doesnt exactly throw up much innovation either. I think the osdev community does need more intermediate projects though - something between an Altair demo program and FreeBSD onto which people can build a better OS. Hmm, I agree with the real-mode part, that needs to go, but Floppy, hard disk, and CD drivers aren't necessary for many hobby-oriented things. They are useful, but complex. And GUI isn't always the best way to do things. Let's face it: GUI's are not essential for most tasks! You can do a LOT within a purely text-based environment. Anyway, back to coding... |
|||
|
14 Aug 2004, 11:28 |
|
|
Gomer73 14 Aug 2004, 16:34
512 bytes is probably too limiting.
There would be no reason to go to protected mode. Protected mode would only be for accessing a lot of memory(not required for a 512 code limit thing). If you consider one screen worth of text is 4K, that would mean 8 times the size of our code limit. We have enough crap code floating around and setting such a low limit on size encourages poor programs. I can make a program to read a disk sector in protected in about 50 bytes however my protected mode disk driver is over 2k. I think it would impove the programming standard to focus on speed or features(ie. how clock cycles to do something like draw a line, or the most effiicient dma driver). Basically the only thing you can do with 512 is some basic character stuff, kind of boring. Just my thoughts, ...Gomer73 |
|||
|
14 Aug 2004, 16:34 |
|
|
decard 14 Aug 2004, 16:42
I think that 512 bytes (actually 510, you need to spend 2 bytes for boot signature
) is enough to code something interesting. See what people can do in just 256 bytes: http://www.256b.com/home.php. 512 byte os wouldn't proably do such stuff as disk access, but you can still fit something interesting there (I don't mean graphical intro, something more interactive can be coded too). Maybe some editor? a command interpreter? |
|||
|
14 Aug 2004, 16:42 |
|
|
ASHLEY4 14 Aug 2004, 18:44
What if we change the compotion from the 512 byte OS with the most features, to the best program that fits and runs from a 512 byte boot sector.
eg: it could be a bootable game, a cdplayer, pmode floppy driver, a pmode cd driver, a editer, debugger,etc. Then people could vote for the bootable program that they most like and were impressed with. This would do two things 1)help us make small floppy drivers, editers and other useful program etc, which we could all learn from. 2 )Also show people how much bloatware there is out there. From this compo we could move on to 1k,2k etc. The rule should say that the program should be no more than 512 bytes fit on a floppy boot sectore and use no external code other than bios, but you can use external programs for demoing floppy/cd driver's etc. Also the size of memory used does not matter. We could move on from this compo,to a compo for the best bootable program no size limit, a bootable web browser, can wait  .
ps: compilax, I must say to make a pmode CD driver is alot easyer than a pmode floppy driver. it may be possible to fit one in 512 bytes at a big squeeze. you could do a cml cdplayer in 200 bytes .
\\\\|//// (@@) ASHLEY4. |
|||
|
14 Aug 2004, 18:44 |
|
|
crc 14 Aug 2004, 22:22
Quote: What if we change the compotion from the 512 byte OS with the most features, to the best program that fits and runs from a 512 byte boot sector. That might just be a better choice. An x86 OS really needs >512 bytes to do anything major
A simple real-mode kernel should be able to comfortably in 1k (+512 bytes for bootsector); a complete OS (kernel, syscall interface, apps, drivers) should able to fit in a nice small 4-5k of space. Pmode in 512 bytes is a bit limiting, but *is* doable. I have a simple pmode 'notes' app that's almost able to fit in 512 bytes now |
|||
|
14 Aug 2004, 22:22 |
|
|
Gomer73 15 Aug 2004, 14:20
My recommendations would be that if this is an OS competition, it should be an OS competition as compared to an application competition.
I don't think any OS out there nowadays is aiming to be a real-mode OS, otherwise they couldn't access the memory available on the system. What does an OS need to do then? 1.) Use it's own code for keyboard, mouse, disk, etc. drivers. 2.) Access a file system. 3.) Handle memory management. My recommendation would be to have the competition be a protected mode competition. Since getting into protected mode takes up some space anyway, going into protected mode would be done first and wouldn't be part of the competition. All the descriptor tables would be loaded according to what is needed for the mini-os. A template could be provided so people wouldn't need to worry about coding the protected OS switch. Also variables could be stored outside the 512 byte code prior to going to protected mode for things that can't be done easily in protected mode(getting the video LFB address). All interrupt vector routines would need to be stored in the 512 byte limit, as well as any code, but the interrupt and global descriptor tables would not. Data(ie pictures or text, even keyboard mappings) may be stored on disk or floppy, but no code. I think if we did this we would get some more spectacular results and it would be more useful. This would qualify more as an "OS" competition. It just doesn't seem right to have something called an OS competition if it does none of the basics that an OS would need to do. I would glady write the protected mode OS switch template if this is the way you wanted to go. With the tables stored elsewhere I think we aren't really cheating, we are just using what bios would provide for us in real mode. This could also be a seperate competition, a protected mode competition. ...Gomer73 |
|||
|
15 Aug 2004, 14:20 |
|
|
decard 15 Aug 2004, 16:43
I have prepared a website for the contest. You can submit entries, comment them and give your ratings. Don't care what's written there (I mean the rules, I have just copied them pelaillo's post), plese test the mechanism. Try to upload some dummy projects (files up to 10kb can be uploaded), and comment them to see how it works. What do you think about the idea?
The layout isn't best, but I just don't have enough graphical skills  The logo is a bit inspired by pelaillo's homepage. I will do some fixes to the layout soon.
Please test how it works. If you will like this, we could use it for future contests. http://512.decard.net regards, Mateusz Last edited by decard on 15 Aug 2004, 20:45; edited 1 time in total |
|||
|
15 Aug 2004, 16:43 |
|
|
ASHLEY4 15 Aug 2004, 17:44
Hi decard, Great job
.
It would be great if we could use it for the compo. Hi Gomer73, To me the important thing, is that it is self booting , a OS is a layer between hardware and your program,we are just putting the two together. I would love to have program's that self booted so it does not matter if i have linux or windows. Thank's again decard. \\\\|//// (@@) ASHLEY4. |
|||
|
15 Aug 2004, 17:44 |
|
|
decard 16 Aug 2004, 20:15
So now lets discuss the rules. Here's pelaillo's orginal draft (slightly modified):
Quote: 1. Valid entries are those submited at http://512.decard.net before 1/10/2004 00:00 (GMT) Let's stay with 512 bytes, it's still enough to code something interesting, and it is a good size for the first contest IMO. I added "common settings" to point 5, as I wrote above I think that one common bochsrc.txt should be prepared - all oses would run on the same machine then. Do you agree to this rules? We could add that each entry has to be written in FASM, that's obvious
And what about the source code? Do you think that it has to be provided? regards |
|||
|
16 Aug 2004, 20:15 |
|
|
ASHLEY4 16 Aug 2004, 22:48
Quote: 1. Valid entries are those submitted at http://512.decard.net before 1/10/2004 00:00 (GMT) Above is the rules, i would like to see, and i would also like to see all entries in fasm in a 512byte BIN file format. \\\\|//// (@@) ASHLEY4. Last edited by ASHLEY4 on 17 Aug 2004, 11:07; edited 1 time in total |
|||
|
16 Aug 2004, 22:48 |
|
|
crc 16 Aug 2004, 23:38
Quote: 1. Valid entries are those submitted at http://512.decard.net before 1/10/2004 00:00 (GMT) Is that January 10, or October 1? |
|||
|
16 Aug 2004, 23:38 |
|
| Goto page Previous 1, 2, 3, 4 Next < Last Thread | Next Thread > |
Forum Rules:
|