flat assembler
Message board for the users of flat assembler.

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???
Yes
47%
 47%  [ 19 ]
No
45%
 45%  [ 18 ]
Undecided
7%
 7%  [ 3 ]
Total Votes : 40

Author
Thread Post new topic Reply to topic
asmdemon



Joined: 18 Jan 2004
Posts: 97
Location: Virginia Beach, VA
asmdemon
i think external assistance meant no netboot, no hd/fd access; but compressing the code means it has to decompress on the fly. It's part of the 512byte limit, therefore it is not being assisted outside of the 512bytes
Post 13 Aug 2004, 11:37
View user's profile Send private message Visit poster's website Reply with quote
ASHLEY4



Joined: 28 Apr 2004
Posts: 376
Location: UK
ASHLEY4
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.
Post 13 Aug 2004, 13:40
View user's profile Send private message Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 878
Location: Colombia
pelaillo
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.
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.

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. Wink
Post 13 Aug 2004, 18:19
View user's profile Send private message Yahoo Messenger Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
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 Smile

Also, what about creating one bochsrc.txt file that all oses in contest will use? All projects would run from the same configuration...
Post 13 Aug 2004, 20:06
View user's profile Send private message Visit poster's website Reply with quote
ASHLEY4



Joined: 28 Apr 2004
Posts: 376
Location: UK
ASHLEY4
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 Shocked.

\\\\|////
(@@)
ASHLEY4.
Post 13 Aug 2004, 23:37
View user's profile Send private message Reply with quote
compilax



Joined: 18 Feb 2004
Posts: 56
compilax
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.
Post 14 Aug 2004, 01:07
View user's profile Send private message Visit poster's website MSN Messenger Reply with quote
crc



Joined: 21 Jun 2003
Posts: 637
Location: Penndel, PA [USA]
crc
Or maybe a series of competitions with varying size limits: 512 bytes, 1k, 2k, 3k, 4k (including boot sectors)?
Post 14 Aug 2004, 01:11
View user's profile Send private message Visit poster's website Reply with quote
crc



Joined: 21 Jun 2003
Posts: 637
Location: Penndel, PA [USA]
crc
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...
Post 14 Aug 2004, 01:18
View user's profile Send private message Visit poster's website Reply with quote
compilax



Joined: 18 Feb 2004
Posts: 56
compilax
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/
Post 14 Aug 2004, 02:33
View user's profile Send private message Visit poster's website MSN Messenger Reply with quote
crc



Joined: 21 Jun 2003
Posts: 637
Location: Penndel, PA [USA]
crc
Quote:
old Unix kernels* written in C were small:

They also ran on non-x86 architectures that allowed denser code Smile

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 Smile

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...
Post 14 Aug 2004, 11:28
View user's profile Send private message Visit poster's website Reply with quote
Gomer73



Joined: 29 Nov 2003
Posts: 151
Gomer73
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
Post 14 Aug 2004, 16:34
View user's profile Send private message Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
I think that 512 bytes (actually 510, you need to spend 2 bytes for boot signature Wink) 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?
Post 14 Aug 2004, 16:42
View user's profile Send private message Visit poster's website Reply with quote
ASHLEY4



Joined: 28 Apr 2004
Posts: 376
Location: UK
ASHLEY4
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 Very Happy.

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 Wink.

\\\\|////
(@@)
ASHLEY4.
Post 14 Aug 2004, 18:44
View user's profile Send private message Reply with quote
crc



Joined: 21 Jun 2003
Posts: 637
Location: Penndel, PA [USA]
crc
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 Smile

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 Smile
Post 14 Aug 2004, 22:22
View user's profile Send private message Visit poster's website Reply with quote
Gomer73



Joined: 29 Nov 2003
Posts: 151
Gomer73
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
Post 15 Aug 2004, 14:20
View user's profile Send private message Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
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 Sad 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
Post 15 Aug 2004, 16:43
View user's profile Send private message Visit poster's website Reply with quote
ASHLEY4



Joined: 28 Apr 2004
Posts: 376
Location: UK
ASHLEY4
Hi decard, Great job Very Happy.
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.
Post 15 Aug 2004, 17:44
View user's profile Send private message Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
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)
2. The maximum size for all code and data required is limited to 512 bytes.
3. The OS should be stand alone and boot without any external assistance.
4. Complexity is given by number of different features.
5. The OS must run in BOCHS (with common settings) because it is the easy way to prove that OS runs in at least one hardware configuration.
6. There is no limits to the used algorithms or data compression as long as decompressor fits within given limit.
7. The winner is defined by public vote and arbitrated by (someone that don't want to participate)


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 Wink
And what about the source code? Do you think that it has to be provided?

regards
Post 16 Aug 2004, 20:15
View user's profile Send private message Visit poster's website Reply with quote
ASHLEY4



Joined: 28 Apr 2004
Posts: 376
Location: UK
ASHLEY4
Quote:
1. Valid entries are those submitted at http://512.decard.net before 1/10/2004 00:00 (GMT)

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

3. The OS should be stand alone and boot without any external assistance, but use of BIOS is allowed.

4. 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.

5. 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.

6. There is no limits to the used algorithms or data compression as long as decompressor fits within given limit.

7. The winner is defined by public vote and arbitrated by (someone that does not want to participate)

8. All entries must be able to be assembled with Fasm and have no external program modify the fasm output.

9. 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.


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
Post 16 Aug 2004, 22:48
View user's profile Send private message Reply with quote
crc



Joined: 21 Jun 2003
Posts: 637
Location: Penndel, PA [USA]
crc
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?
Post 16 Aug 2004, 23:38
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4  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. Also on YouTube, Twitter.

Website powered by rwasa.