OSDev.org

I have got an OS put together called SecOS
It is a bootsector OS capable of executing files, listing a files in the current drive, and printing the contents of a file

http://jouleos.galekus.com/desc.php

go there and the most latest release for SecOS

the command list is
d = dir, list the files in the drive
x = execute, execute a file
t = type, print the contents of a file

All works fine in QEMU. I printed the first file's data, executed the second, and found a directory listing with d.

How much more do you think you can fit in a single sector?

not much...I'm already disabling some stuff to get it to fit
last time I checked, I think I had like 1 byte left

really, I don't know how else I can make it smaller..

but what I plan is to support is an interrupt that will allow applications to easily browse the FS and read files, I won't support writing the files because of hwo much more overhead I'd have to have

hckr83 wrote:not much...I'm already disabling some stuff to get it to fit
last time I checked, I think I had like 1 byte left

really, I don't know how else I can make it smaller..

Compression? Try to fit that in one boot sector, and still have enough room for the compressed OS.

I don't think that's possible without losing space

hckr83 wrote:I don't think that's possible without losing space

It was a joke. Maybe I should have made it more obvious. I'm always forgetting about how monotonous text is. Or is that I just make bad jokes?

hckr83 wrote:not much...I'm already disabling some stuff to get it to fit
last time I checked, I think I had like 1 byte left

Are you using some sort of compression? Especially if you can make the code relatively regular, that can win quite a bit. As long as your decompression code is shorter than the amount of bytes you can manage to compress, you win. As for fitting the decompressor, yeah it can be a bit problematic, but you should give it a try anyway.

Ofcourse, also make sure you don't do any duplication whatsoever. If there are code segment more than a few bytes long, it's probably better to make that a function. As long as the call is less bytes than the function called, you win.

Or take the idea futher: do a bytecode interpreter. With something like 4-bit code (and relevant escapes to get more opcodes/longer immediates) you might be able to pack relatively regular code into truly small size. This is basicly just optimization of the "make it a call" to get the call-instruction encoded as small as possible, so obviously you want to pack as much functionality into each opcode as it humanly possible without causing an expansion in the number of necessary opcodes. Ofcourse normal compression might still be a good idea.

Bootsector is a bit nasty indeed, since it's problematic to fit stuff you need to reduce the size of your code. The key in any case is sharing as much as possible. Also don't be afraid to encode (say) 3-bit information into packed 3-bit format, because sometimes you can save bytes by starting with bits.

The site is dead...

inflater

Try compiling with -Os if you're using C.

ehird wrote:Try compiling with -Os if you're using C.

Are you kidding?

He is writing an OS in the boot sector of a floppy, 512bytes.. You kinda have to write that in 16bit Realmode Assembly..

ehird wrote:Try compiling with -Os if you're using C.

You know... i don't like people to ever get the wrong impression, so i feel i should tell you out right, i don't like you very much. You act like you discovered C and UNIX about a week ago, read everything you could about it from Raymond and then decided to voice many opinions and silly comments in an attempt to sound knowledable... just my view though so if you wish to argue the point i wont respond lol

Very nice for a single sector OS i am most impressed, i have always been more for modularity than optimisation, mostly becuase i don't have the brain cells for such tasks, that is what compilers were written for. Kudos to ya!

The site is dead...

mine?