Team
(4)

Contest Details

Microprocessors didn't always have Gigabytes of memory, and Microcontrollers didn't always have hundreds of kB of flash. The Hackaday 1kB challenge is a contest where entrants must create a device which uses 1kB or less of executable program code. The contest is open to any microcontroller or microprocessor architecture. Anything from Arduino board with AtMega328's to ARM and beyond. External hardware such as leds, switches, and 74 series logic chips are allowed and encouraged - but the machine code must be less than 1kB.

Official Rules:

This contest is open to any microcontroller or microprocessor architecture.

Projects must use 1 kB or less of code, including any initialized data tables, bootloaders, and executable code.

<UPDATE> Unavoidable Hardcoded bootloaders such as propeller, ESP8266, or i.mx series don't count toward the 1 kB limit. Entrants can use the bootloader code to start their processor up and get their own code executing. Once things are running though, any calls into bootloader or ROM tables count against you.

Entrants must show how they came to the 1 kB calculation (map files, assembler/linker output, etc)

Existing computer systems can be used (Example - Atari 2600) however, the size of any rom routines or data tables must be included in the 1 kB calculation.

Mask Rom: If you are using a chip with masked rom code, you must include the size of any ROM routines you call in your final executable size calculation. If you wanted to write a program in SPIN for the Parallax Propeller, you’d need to include the SPIN interpreter ROM, which would put you over the 1 kB limit.

Projects can use multiple processors as long as they are running the same 1 kB binary, or if the total size of the ROM being run is less than 1 kB. (Example - two micros running different binaries which are 512 bytes long each)

Projects must fill out the description, details, components, and project logs.

Projects must be open source. Source code, schematics, and board layouts for the project software must be either posted in the files section, or include a link to a public repository such as Github.

Projects must use publicly accessible toolchains. Closed source toolchains (example - IAR or Keil) can be used as long as the demo versions will compile/assemble the contest code.

All entries will be judged by Hackaday staff.

Winners will be announced on or around Monday, January 16th

Hackaday Staff, Employees of SupplyFrame, Judges or the family of any of the preceding are not eligible to take part in this contest. Everyone is still encouraged to build awesome stuff and show it off though.

Judging Criteria:

Does the entry fit within the 1 kB size constraint?

How novel or interesting is the entry?

Does the documentation explain the project?

Are any novel techniques (example: Self modifying code) explained?

How complete is the entry? Projects don’t have to be complete or working to enter, however those which are finished and working by the deadline may be judged higher.

Prizes:

Any Hackaday contest needs some awesome prizes, and this one is no different.

Grand prize is a Digi-Comp II kit from EMSL

First prize is a Maker Select 3D printer V2

Second Prize is a Bulbdial Clock kit from EMSL

Third Prize is a Blinkytile kit from Blinkinlabs

Contest Logs

The 1 kB Challenge deadline has come and gone. The judges have done their work, and we’re ready to announce the winners. Before you jump down to find out who won, I’d like to take a moment to say thanks to everyone who participated. We had some incredible entries. To say that judging was hard is quite an understatement. Even [Eben Upton], father of the Raspberry Pi got in on the action. He created a new helicopter game for the classic BBC Micro. Look for writeups on the winners and many of the other entries in the coming weeks.

Grand Prize

The grand prize goes to [Jaromir Sukuba] for Brainf*cktor. [Jaromir] went above and beyond this time. He created a computer which can be programmed in everyone’s favorite esoteric programming language. Brainf*cktor uses 1019 bytes of program memory in [Jaromir’s] PIC18F26K22. You can write, execute and edit programs. [Jaromir] ran into a bit of a problem with his LCD. The character tables would have thrown him over the 1 kB limit. Not a problem – he designed his own compressed character set, which is included in the 1019 bytes mentioned above. All the clever software takes physical form with a homemade PCB, and a case built from blank PCB material. Best of all, [Jaromir] has explained his software tricks, as well as included a full build log for anyone who wants to replicate his project. All that hard work will be rewarded with a Digi-Comp II kit from EMSL.

First Prize

First prize goes to [Dumitru Stama] with M0S – CortexM0 RTOS in 1024 bytes. Operating systems are complex beasts. Many of our readers have toyed with the Linux Kernel. But writing a real-time OS from scratch? That’s quite an undertaking. [Dumitru] didn’t shy away from the challenge. He designed a Real-Time Operating System (RTOS) for ARM processors, written completely in ARM thumb assembly instructions. This is no bare-bones executive. M0S has a rich list of features, including preemptive task scheduling, mutexes, and inter-process communication. [Dumitru] even gave us memory allocation with an implementation of malloc() and free(). The OS was demonstrated with a NUCLEO-F072RB board from ST-Micro.

[Dumitru] didn’t just drop a GitHub link and run. He documented M0S with seven project logs and a 37-minute long video. The video uses electronic whiteboard drawings to clearly explain all the internal workings of the operating system, as well as how to use it.

[Dumitru] is the proud new owner of a Maker Select 3D printer V2!

Second Prize

Second prize goes to [Cyrille Gindreau] with 1K Challange Laser. Vector lasers generally take lots of memory. You have to manage galvanometers, laser drive, and perform all the magic it takes to convert a set of vectors to lines drawn in space. The project uses 912 bytes of program and initialized data memory to command an MSP430 to draw an image.

Proving that flattery will get you everywhere, [Cyrille] picked the Hackaday logo as the subject. The Jolly Wrencher is not exactly simple to convert to vector format, though. It took some careful optimizations to come up with an image that fit within 1 kB. [Cyrille] wins a Bulbdial Clock kit from EMSL.

Third Prize

Third prize goes to [Mark Sherman] with tinygames. Video games have been around for awhile, but they are never quite this small. [Mark] coaxed the minuscule Atmel ATtiny84 to play Centipede with only 1024 bytes of program memory. Even the BOM is kept small, with just a few support components. Control is handled by an Atari 2600 compatible joystick. Video is black and white NTSC, which is demonstrated on a period accurate CRT. [Mark] generates his video by racing the electron beam, exactly the same way the Atari 2600 did it.

[Mark] will take home a Blinkytile kit from Blinkinlabs.

Final thoughts

First of all, I’d like to thank the judges. Our own [Jenny List], [Gerrit Coetzee], [Pedro Umbelino], [Bil Herd], and [Brian Benchoff] worked hard with me in judging this contest. I’d also like to thank our community for creating some amazing projects. The contest may...

It's come to my attention that the rules excluded a few architectures which have bootloaders hard coded to run at powerup. An example of this is the parallax propeller, which must run the spin interpreter before firing off a PASM routine. The spirit of the rules is leveling the playing field - not excluding any particular processor. As such I've updated the rules to allow hard coded bootloaders. Check it out!

Quite a few people have been asking about CPLDs and FPGAs. First off, custom processors instantiated in FPGA's are allowed, and encouraged! CPLD/FPGA external logic is also perfectly fine to use, but remember this is a contest about fitting a lot of function into a little codespace. A ton of perfectly executed Verilog or VHDL code to implement a state machine won't impress the judges as much as a well crafted 1 kB routine. The same goes for Analog or even mechanical entries. Don't worry - there are more contests coming down the pipe for your analog and mechanical hacks!

Among ROMs that one has no control over, there are still significant differences:

* Data like bootloader ROM that you can invoke and give you an unfair advantage over other platforms, and thus should count against you (as in the current rules),

* Data that are not in the microcontroller or external memory-type device (eg. the Character ROM of a HD44780 display) should be free (not count towards the 1k)!

One argument could be: If the character in an LCD display is not free, why is the character in a Nixie tube free? Another is that I just think of an LCD dispay as a black-box unit that has nothing to do with memory (disregarding the addressable RAM inside).

I hope the next time these kinds of 'trivial' ROMs will be free, whereas ROM containing code or images, stay non-free.

I can accept the use of ROM and characterset defined in ROM. However the display on the ZX Spectrum is done by the machinehardware where on the ZX81 it is done by software in the ROM. Do you get the point

Planning on entering my 1K hires games for the ZX81. Only 1K RAM but still full screen (normally 6K buffer) playfield.However, rule state that I must count in ROM-routines used. If I built hardware that would support the screendisplay it would be ok.When I must count in the ROM-routines which are needed for screendisplay I will lose 265 bytes already.(Characterset of displayed characters not counted for yet, so any letter will cost 8 bytes too)

So I would like to have a strict defintion of ROM-routines used. Anyone with an answer.Worst case: I can't enter since I need to count too much used ROM-routines that kills the bytes I need for the code.

Hi, if I have understood well, an FPGA can be used (or external hardware).But, I can do a ROM/LUT in FPGA, and as external hardware I can use external EEPROMs.So, 3 questions:Are the projects inspectioned to avoid "memory definitions" inside FPGAs, or are allowed? What about external EEPROMs? And the integrated ones, like in the Atmega328?

I really don't understand why the hd44780 display with ROM would be a problem, because for me, when you send your data to the module, it's out of the scope. You don't have to write the firmware of the HD44780, the data is already on. The only thing you can actually write to are those 8 special characters? There are currently 3 or more projects in this contest with those displays and they look great. But then the hardcoded bootloader thingies aren't a problem? Or the GPS project, that's also fine?

So please, if anyone has the time :) explain. Or point me to the right comment. But don't let me google. I'm confused.

Totally agree! Code that is out of scope should not count. The complexity of the result should not be taken as a measure of how good your code is. I mean, a script that run "doom4' is a lame project while the brainf*ck computer or the 2048 game are cool projects and I think that the contest judges are smart enough to realize such difference.

If you want to borrow the tiny "tom thumb" font and display driver code (PIC) in OKOS for one of those i2c SSD1306 OLED displays, feel free. With a limited character set, it will fit in just over 200 bytes. If you look in git history, you can find an earlier version that has full 96 printable character ASCII support in under 400 bytes. You can still do something interesting with the remaining space.

Hey Dave - The idea is to have a contest where you can look at the submissions and say "hey, look at this awesome thing which was done with less than 1 kB of rom".

The idea of a 1 kB sized program doing the work starts to get watered down if it's talking to a TFT LCD with an ARM based controller, a full sized keyboard with a controller of its own, etc, etc. Deciding where to draw the line is hard - and I drew it on the strict side for this contest.

All that said - I don't want to disqualify anyone. If the point of your project is to work with a device that has RAM/ROM of it's own, then we can concentrate the judging on the work you've done, not what's sitting on the other end of that interface. An example of this would be something that is working with the CAN bus on a car. If you can handle OBD-II CAN bus and do something cool with less than 1 kB of code, awesome. The judges are not going to count all the other controllers on the CAN network against it.

I have a device using a 12f635 that measures voltage phase and current on a 240 (or other) AC supply network. The problem is that though the PIC code could be under 1k it just sends long series of numbers out through a 433 radio to a Raspi where the numbers are crunched down to give the values. As it is only complete with the Raspi is it still acceptable or is the Raspi included in the 1K? It is for use in substations where you may have 60 or so sensors connected to one Raspi that is connected to the Internet.