OSDev.org

Yea, I think I know what I'm going to do now.. I'm thinking I could make an at least partial FORTH interpreter... that would be pretty neat and the syntax is easy enough to parse in assembly(without tearing my hair out)

Well, apparently quite a lot of other people were in fact interested in this fourth 512 asm compo.
Nice !

Let's hope we can set the closing date..

I propose 2010 january 15th ?
What do you think ?

About an eventual prize, I don't think it's so important..
The previous compos did not feature a winning prize, AFAIK, and I guess we like to compete for the fun, anyway...

Concerning the compo requirements (SSE2, etc..), there are none, except for the obvious :

-the compo entry shall fit a 512 bytes binary single file
-it must be bootable by an x86 compatible BIOS + CPU in real mode
-it's a damn plus if we can quick test it with qemu, bochs, etc..

other than that, everything is allowed !
(8086, pentium 4 instructions sets; BIOS interrupts, etc...)

I assume that 64bit is allowed also then(if someone dares to tackle that in 512 bytes)

and yea, a little update to my project..

My forth OS so far is going pretty well but running out of space fast(now at 470 bytes)..
It will print `ok` at the end of commands. It supports a stack of 4096 bytes. It supports the standard +,-,@,and ! words/operators. Also, I put in 2 extensions for `^` and `&` for writing and reading the current segment data will be writtent o(respectively)

My next task will be implementing the do while word, which could make it sorta close to turning complete(if you double the while structure as an if structure)

A byte is a byte...

Here's a hack for the gamers in you.

To understand / use such a thing, you need a twisted mind -- but I guess anybody trying to write a 512-byte demo has one.

It increments / decrements two registers representing x and y position when you press left/right/up/down arrowed keys. And it's only 28 bytes, including jumping back to the main loop at the end of the work, and not blocking if no key was pressed (so you can continue redrawing the screen while no key is pressed). I included a few pieces of code to make a mini-demo out of it, but that's not counted in the 28 bytes.

It works by building an inc/dec bx/dx opcode from scratch into ax, moving this value just before the main loop (overwriting the initialization stuff you left there) and jumping to that location.

If somebody knows a smaller hack to achieve the same result, I *really* am interested.

Have fun !

Note: If you can't download the attachments, I've stored them here too : http://jahvascriptmaniac.free.fr/2010/p ... tkey-hack/

My friend, this is one of the most clever tricks I have seen for quite a while!
We could do with a size hacks wiki page or something like that for these things.

[font=small]Note : if this is too much off topic, please tell me, I'll move it into a new topic.[/font]



Thanks

I actually spent a whole day on it, maybe two...
I investigated the following possibilities, in approx. order of size, decreasing :

Trivial, unoptimized, but you can easily change the keycodes



A "tree" of bit-testing hacks
Choose HACK1 so that :

Choose HACK2 so that :

Choose HACK3 so that :




Choose jump adress hack
The arrow keys scancodes have the following property : if you zero out their least significant bit, then they each have their first bit counting from the right in a different position. Luckily, the 'bsf' (bit search forward) instruction returns the position of the rightmost set bit.

0101 0000 DOWN
0100 1000 UP
0100 1101 RIGHT
0100 1011 LEFT



Dynamic code generation
The hack I used

Code as data hack
I didn't try this one.

Principle : when you have some random data, say the adress of your back buffer, you can actually put a value that represents one or severall opcodes. Then, at some point, you jump onto those opcodes. better be a jump you must do anyway, cause otherwise you'll use up two bytes for the extra jump.

It's even better if you can dynamically generate an opcode just before those data-code bytes

@js: nice job !

I'm sure it can help some guys to shrink bytes and improve their 512 asm compo !

Maybe you can even participate yourself ?

What about choosing a deadline ?

Are there more people interested, or should we keep the 15th januray 2010 ?

That's why I posted it


Of course I am participating...


I'm ok with that deadline. I discovered this thread on december 30, (when this deadline was suggested), and started coding immediately...

Hi,

Here's my 512 Byte OS. It's the well known game "Snake". You've to compile it with FASM. NASM will create a file which is a little bit larger than 512 bytes.

There was a FORTH interpreter in the first 512b compo, so it can be done.

Was it a complete enough Forth implementation to be turing complete? Cause I'm seriously giving up if so lol

Wow, we have now quite a pretty amount of entries !

Thank you all for your enthusiasm !!

I edited the main post to list the already submitted entries, with proper links..

The deadline for the compo has been accepted as January 15th 2010 (friday)

Yet I'm not too sure how we will process the votes...

Can somebody with previous experience give some hints how to set up the votes ?

Hi,
I am in this time.But I am in the middle do lot many things .I am not sure,whether I will be able to make it.I am writing a small speaker piano .You press some buttons and you hear music from the pc speaker .

--Thomas

Hi,

This is my contribution to this contest. It's an OS running in real mode which is capable of sending an ARP network packet over an RTL8139 network card. That means you can resolve IP addresses to MAC addresses in the current LAN. Once it's started, you enter your IP and the IP to be resolved. Then it'll print your MAC and (hopefully ) the destination's MAC address.

You need to assemble it with FASM, maybe it also works with NASM, some adjustment and -O99.

There's a constant in the code called "Os_level". You can choose a level to reduce the size of the binary (though it's always 512 bytes if you don't remove the padding at the end). The code contains detailed explanations of all five levels. Here are the resulting sizes (with "times 510-($-$$) db 0" commented out):
Os =

• 0: 507 bytes
• 1: 441 bytes
• 2: 414 bytes
• 3: 388 bytes
• 4: 312 bytes

PS: If you don't have an RTL8139 card available, you can test it with qemu and:

Qemu won't care about your IP (as far as I know), though only values between 10.0.2.15 and 10.0.2.254 are in the narrow sense correct. As a destination you may try 10.0.2.2 (the gateway and DHCP server) or 10.0.2.3 (the DNS server). There should also be another server on 10.0.2.4, but I didn't find anything.

@XanClic: amazing !!!