512-byte coding contest
for the 20th anniversary of flat assembler

It has been 20 years since the first official release of flat assembler, and to celebrate I launched a new 512-byte coding contest, focused solely on creations made with help of fasm or its younger sibling fasmg. Anyone can enter, as long as the submission adheres to the rules listed below.

General rules

An entry to the contest must be a source text that can be assembled with fasm or fasmg to no more than 512 bytes of code/data. There are no constraints on what the code should do - it can be a graphical demo, a text-based demo, a miniature operating system, or perhaps something distinct and unique. Please show us something new and interesting!

The entry should assemble with the latest version of the assembler available at the time of the submission. There is no need to ensure that it may be assembled with older versions, therefore all features of fasm/fasmg, including the recently added ones, may be used.

If the source code uses any additional headers (like instruction sets or other macros) that are not in the base packages of fasm/fasmg, it should either come packaged with these files, or include a note where to get them, provided they are published and maintained in freely accessible place (for example on GitHub).

Entries may only by submitted by their original authors. Every entry should come with a license, which may be chosen by the author, but should allow for the source code to be published (indefinitely) on the website of the contest for anyone to view, download, assemble and execute. If the author has no specific preferences, a suggested license is the 2-clause BSD.

Entries may be submitted by posting them in dedicated thread on the fasm's message board, or by sending them to contest@flatassembler.net. No matter which method is used, every entry is going to be published on the website of the contest (although the author may request that their entry should not be published before the final date), however it may get immediately rejected (and therefore not published at all) if it does not conform to the above rules.

The submissions will be accepted from March 15h to June 19th 2020.

The prize pool, sponsored by 2 Ton Digital, is 512 EUR. It is going to be split among the top contestants, depending on how many awards are given. This is going to be decided by a jury consisting of Tomasz Grysztar, Jeff Marrison (from 2 Ton Digital), and revolution (the author of FASMARM).

The prizes are going to be awarded in two categories:

PC Booter category

An entry in this category should be a valid boot sector for x86-based PC BIOS, with last two of the 512 bytes being the "55 AA" signature.

In the classic PC boot process the code is loaded and executed at physical address 7C00h, and this should be assumed, but the code should not rely on CS:IP being 0:7C00h (some implementations have been known to jump to 7C0h:0 instead). Also, other registers and flags should be assumed to have unknown values.

The functions of PC BIOS and/or Video BIOS may be used freely, but taking into account potential differences in feature sets between various generations.

Since the most accessible method of running such code is through emulators, the entries are going to be tested in DOSBox (with BOOT command) and Bochs. However, it should also be possible to test them on a real hardware. For this reason each entry should state its requirements. There is no need to limit the code to original IBM PC hardware, but we should know what kind of CPU, graphics adapter, etc. we need to be able to try it properly.

Free form category

This category allows entries for any architecture, not only x86, as long as they fit in 512 bytes. Each entry must provide not only a precise declaration of hardware requirements, but also a guide how to load it and test on said hardware or in an emulator. The required setup should be as simple as possible (and not try to circumvent the 512-byte limitation by hiding additional data in the setup guide).

A file produced by the assembler may need to be larger that 512 bytes because of the format/architecture constraints. For example, if Intel HEX format is used, file containing 512 bytes of code is going to be larger than that. Or perhaps padding to a larger size may be needed for some machine. But only the actual code and data that is going to be extracted from the file needs to fit in 512 bytes. The fulfillment of this requirement is going to be judged on an individual basis.

An entry in this category might be a program for x86 PC, a code for a microcontroller or for a known virtual machine. If an entry is a polyglot, it needs to include a setup guide for each of the environments it can be executed on.

While technically any entries from the first category would also be valid for this one, any entry that can only be executed as a PC boot sector is going to participate in the contest in the first category only.