The 1kB Challenge

The only limit is what you can do with 1 kB of program memory

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:

Contest entry deadline is Thursday, January 5, 2017 09:00 pm PST (+8 UTC)
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

Collapse

And the winners are...
Adam Fabio • 01/17/2017 at 06:34 • 4 comments

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...
Read more »
Judicial Deliberations
Adam Fabio • 01/07/2017 at 08:06 • 3 comments

The 1 kB challenge deadline has passed. With 133 entries, this contest has exceeded our wildest expectations! Thank you to everyone who entered. The judges are now hard at work reviewing each entry.
Keep an eye on this space (or in your feed if you follow the contest) for an announcement of the winners!
Thanks again to everyone!
CPLDs, FPGAs, and hard bootloaders
Adam Fabio • 11/23/2016 at 03:15 • 0 comments

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!
Details coming soon...
Adam Fabio • 11/14/2016 at 01:59 • 0 comments

Stay tuned for the official rules and details!

View all 4 contest logs

Discussions

danjovic wrote 11/21/2016 at 18:31

Question: How do PIC instructions count? 1Kbytes mean 8192 bits wich represents 585 instructions in 14bit cores and 682 instructions in 12 bit cores.

Are you sure? yes | no

Adam Fabio wrote 11/28/2016 at 06:35

PIC is at a bit of a disadvantage in that you have less instructions available to you. For 12 bit instructions, you're looking at something around 682 instructions fitting in 1 kB of ROM/Flash

Are you sure? yes | no

danjovic wrote 11/21/2016 at 18:22

If a previous project is allowed, please consider #VGA Blinking Lights as my first entry! It takes 471 words from a PIC microcontroller.

Are you sure? yes | no

Mars wrote 11/22/2016 at 20:31

I am also thinking of using VGA output for mine too, but I would like an official ruling from the judges: The VGA monitor in the picture definitely has a micro in it. Even an old CRT vga montior probably has a micro in it. Unlike a character-rom LCD display, monitors are generally considered an external, separate device. Or should I just dig up an old 60's color TV?

Are you sure? yes | no

danjovic wrote 11/23/2016 at 22:45

I don't think the micro in VGA monitor will count. One could have a CRT monitor with analog circuitry only and our projects would still work.

In my opinion the LCD alphanumeric display ROM should not count as well. The same for the BIOS routines in retro computers, since such routines are already there and you simply use them. Of course using ROM tables/routines will allow one to make more complex stuff, but the complexity of the result by itself is not a good measurement of the quality of your project and the judges should be able to evaluate that. At least is what I think.

Are you sure? yes | no

deʃhipu wrote 11/21/2016 at 17:29

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

This is a bit vague. I assume by "code" you mean "source code", so the source of the program. But later you are talking about map files and linker outputs and bioses, so that sounds like program binaries? So which is it? Source code or program binaries?

Are you sure? yes | no

Greg Kennedy wrote 11/21/2016 at 17:49

Binaries is my understanding.

Are you sure? yes | no

Adam Fabio wrote 11/28/2016 at 06:36

Yup - binaries. Your source code can be as long as you want, but the assembled/compiled/linked binary must fit in under 1 kB.

Are you sure? yes | no

Greg Kennedy wrote 11/21/2016 at 15:12

So, x86 entry needs to be done as 2x boot sectors? Does the BIOS count against me?

Are you sure? yes | no

deʃhipu wrote 11/21/2016 at 18:03

Also, don't forget your processor's microcode, and the code running on the hard disk driver's chip.

Are you sure? yes | no

deʃhipu wrote 11/21/2016 at 18:19

Oh, and the graphics card...

Are you sure? yes | no

Yann Guidon / YGDES wrote 11/21/2016 at 19:02

I understand the rules as :
"the amount of bytes (or entropy) you inject in the existing system to change its operation in such a way that it does what you decided" :-D

Are you sure? yes | no

deʃhipu wrote 11/21/2016 at 19:52

But then how much information does the choice of the system carry?

Are you sure? yes | no

rubypanther wrote 11/21/2016 at 10:39

My rules questions:

What about analog components like op-amps and transistors? Can I assume that "external hardware such as leds, switches, and 74 series logic chips" includes any sort of discrete component that doesn't have stored program code? Or are transistors cheating?

If I use a sack of 74xx NAND chips do I need to calculate pull-ups and pull-downs as code bits, or are those free even if hardwire "programmed?" Or are they only free when connected to GPIOs and programmed from the MCU?

Are you sure? yes | no

Eric Hertz wrote 11/21/2016 at 11:48

LOL I snorted... pull-resistors!

Are you sure? yes | no

K.C. Lee wrote 11/21/2016 at 12:53

This is not just a coding contest. You want to shows what the uC can do in a project.

IMHO I think "cheats" shows innovation and creativity. That's just the hacker's way. Anything not nailed down or prohibited by the rules are free game.

You can implement algorithms in hardwired finite state machines (TTL'ers) or old fashion analog or neon tubes. :)

Are you sure? yes | no

Yann Guidon / YGDES wrote 11/21/2016 at 19:03

or relays

or diodes

or... whatever :-D

Are you sure? yes | no

jaromir.sukuba wrote 11/21/2016 at 07:36

Adam, thanks for the update with official rules. I didn't want to speculate before the rules are out, so some questions now:

1, Character LCDs - just like classic 16x2 LCD. Those do contain ROM for character generator. The ROM isn't accessible from outer world and isn't executable by microcontroller (or at least I can't imagine how). I assume this ROM isn't taken into 1kB calculation, is that correct?

2, What about FPGA or CPLD in project? Are those allowed in contest? Not sure about how to calculate the "code" (or more precisely, configuration) size.

3, There are platforms with other than 8-bit multiple of program FLASH word size, for example 12 or 14 bits (as opposed to "classic" 8, 16 or 32 bits). Should I consider 100 words of 14 bits in size to be 1400 bits or 175 Bytes? So, within the limit is: 1024 words of 8 bits, or 682 words of 12 bits, or 585 words of 14 bits, or 512 words of 16 bits, or 341 words of 24 bits or 256 words of 32 bits. Is that correct?

************EDIT***********

4, If there are configuration bytes/fuses in FLASH (used to setup oscillator, BOR, watchdog, code readout protection etc..) are those included into 1kB calculation? Those are usually not executable, often in completely separate memory region, so it shouldn't be included into calculation - is that correct?

Are you sure? yes | no

jaromir.sukuba wrote 11/22/2016 at 08:18

Uh, so character LCDs are banned after all?

http://hackaday.com/2016/11/21/step-up-to-the-1-kb-challenge/#comment-3282797

Are you sure? yes | no

yorgle wrote 11/22/2016 at 19:21

Related: Pac-Man (and similar) hardware have a graphics ROM for characters and sprite display. The entire graphics subsystem can be seen as a black box. You cannot access this ROM data at all, you can just set video memory and assume it's getting displayed as expected. Would this be off-limits, since the graphics ROMs are required for operation, but would not need to be provided for running on real hardware?

For example, If my 1k program fit in one ROM. You pop the ROM off of the Pac-Man arcade board at 6E, shove in my ROM, containing my 1k of new code/data, and it runs. It leverages off of the hardware's graphics ROM already there..

Or would I have to also provide the Graphics ROMs, (ostensibly with just the glyphs I intend to use, to save bytes). I could also see laying out the ROM space in 1 kbyte such that the same ROM image can be burned as Program ROM (6E), character ROM (5E) and sprite ROM (5F)... Which I think fits more in the spirit of this challenge.

Thoughts?

Are you sure? yes | no

johansc wrote 11/20/2016 at 22:30

Woohoo, this will bring back warm memories of getting the most out of these legendary 16F84 PICs in assembly language!

Are you sure? yes | no

ep.hobbyiest wrote 11/20/2016 at 18:41

8-bit controllers only can make code within 1kb program space .

Are you sure? yes | no

matseng wrote 11/21/2016 at 05:42

Lolwut? Why would a 8 bit microcontroller have a 10 bit addressing limitation? Most 8-bitters support 64k memory - that is they have a 16 bit address bus.

Are you sure? yes | no

Tophat Tech wrote 11/18/2016 at 16:42

Well, gotta go dig out the Trinkets and shift registers.

Are you sure? yes | no

Max Chan wrote 11/18/2016 at 08:54

I wonder if self-decompressing encapsulation count as cheating. Such encapsulation copies a decompresser to the end of target flash, jump to it decompressing the compressed payload code into Flash overwriting the uploaded 1k, then jump into it?

Are you sure? yes | no

K.C. Lee wrote 11/20/2016 at 16:49

Let's say you can fit the decompression, FLASH writing routine and other support code into 200 bytes, then your compressed payload has to fit within the remaining 824 bytes.

The compression ratio has to be high enough to be worth the effort. That effort could have been redirected in the actual project to make it unique and impressive.

Are you sure? yes | no

Yann Guidon / YGDES wrote 11/21/2016 at 19:07

That's where #Recursive Range Reduction (3R) HW&SW CODEC is useful, it requires less code and temporary data to decompress. Unfortunately it doesn't work on executable binaries.

Are you sure? yes | no

Thomas Jager wrote 11/17/2016 at 23:17

Do these things have to be useful? I'm thinking of just a fun project with no real-world goal, but that provides some entertainment. (And which may one day defeat a malevolent AI)

Are you sure? yes | no

Adam Fabio wrote 11/18/2016 at 17:21

Nope - your project doesn't have to be useful! Some of the best projects I've seen haven't been "useful" in the classic sense.

Are you sure? yes | no

danjovic wrote 11/19/2016 at 13:16

Can a driver itself count as an entry? I have some I2C drivers for joystick port of MSX computers that can fit in 600~700 bytes, but to demonstrate them working It would be necessary to write at least a Basic program. Do I have to restrict such program to the remaining 300-400 bytes or no?

Same question about another possible entry which is a kind of a framework. Will the framework count itself or the demo application will count too?

Are you sure? yes | no

Kirk Robinson wrote 11/22/2016 at 22:13

Can I2C devices be used or is it restricted to 74xx series components?

I am still not sure on the rules if the 1KB includes RAM. If your code is 900 bytes, does that mean you can only have 100 bytes of RAM? Is there a RAM restriction? i.e. 1 KB of ROM that decompresses 500 bytes of data to RAM .

The mention of self-writing code would imply that either RAM is written to or the ROM is flashed based.

Are you sure? yes | no

mosaicmerc wrote 11/17/2016 at 20:49

Processors without math in hardware or much functional modules like the venerable 6502 are definitely at a disadvantage. I used to code and sell LADS, C-64 Assembly to Compute!s gazette 27 years ago. I'll be doing a Microchip submission in ASM. Are the details going to limit the chip size (pinout wise)?

Are you sure? yes | no

rubypanther wrote 11/17/2016 at 07:48

I'm warming up my shift registers and 74xx ICs! This is gonna be awesome.

Are you sure? yes | no

Mars wrote 11/17/2016 at 00:49

I don't think a bootloader should could against you as long as you aren't cheating by jumping to the 'bootloader.' For instance, I make things with the raw AVRs, no Arduino loader. If I have a 1k hex file, I can load it in via the ISP header. But, I usually use the Chip45 bootloader and just load it over the serial port. As long as I don't use the chip45 loader functions in my program, I wouldn't feel like I'm cheating. The same should apply to Arduino users. You could load an Arduino-compiled program into a blank (no bootloader) AVR via ISP. But the bootloader makes it easier for you.

Are you sure? yes | no

Adam Fabio wrote 11/17/2016 at 06:48

The final 1kB has to be your code, without an external bootloader. I'm not trying to limit people here, but it would be harder to judge each entry if we allowed bootloaders. There is nothing wrong with developing with a bootloader, then switching to a stand alone binary at the end - if I were entering, that's how I would do it.

Are you sure? yes | no

Yann Guidon / YGDES wrote 11/16/2016 at 23:01

Are people mistaking this challenge with the IOTCC ? (Internet of Obfuscated Twisted Code Cheats)

Are you sure? yes | no

James wrote 11/16/2016 at 20:58

Time to brush up on my Assembly skills again!

Are you sure? yes | no

Alex wrote 11/16/2016 at 19:44

I thinking about using as much as possible off-core peripherals like DMA or a Event Sysrem. So 'only' some setup code must fit into the 1kB. I hope this will be allowed.

Are you sure? yes | no

[skaarj] wrote 11/16/2016 at 18:44

Good challenge - packed data chunks are suitable here. Entire code can fit in 1 KByte but when executed, it expands itself into the RAM and you can have... 100 kbytes. Or more. This means some assembly compression magic. Anyone ready for that? And... will the official rules include any prizes in liquid form (beers)?

Are you sure? yes | no

Mars wrote 11/16/2016 at 20:34

You can't run AVR programs in RAM, unless you write an interpreter. I would take 1k of program space to mean you have a hex file that writes to 1k of the AVR flash. 1k of code and data for an AVR. If that code decompresses itself and writes to more AVR-flash, I would take that to be OK: It's not any different than other self-compressed demo executables. But, if that code goes and loads a bunch off stuff off an SD card, and writes that to AVR flash, I would take that to be cheating.

Are you sure? yes | no

[skaarj] wrote 11/16/2016 at 22:22

Demo Scene style, yes. No cheating. Maybe load stuff from punched paper tapes/punched cards but not from SD. But if no beers, no magic. Simple.

Are you sure? yes | no

Patrick Van Oosterwijck wrote 11/17/2016 at 00:19

One of the many excellent reasons to never touch an AVR. Unified memory FTW.

Are you sure? yes | no

Voja Antonic wrote 11/17/2016 at 21:18

"machine code must be less than 1kB". It is precisely defined, and no one said that it must be in ROM.

Are you sure? yes | no

Peter Noyes wrote 11/16/2016 at 17:56

As a 6502 developer I am pretty excited about this contest!

Are you sure? yes | no

Adam Fabio wrote 11/17/2016 at 03:48

A few folks on the staff said they doubted any 6502 folks would enter - I'm hoping you will prove them wrong!

Are you sure? yes | no

Garth Wilson wrote 11/18/2016 at 02:01

I have tons of experience with 65c02 and PIC16, and I find that on the average, the 65c02 only needs about half as many instructions and half as many clocks to do a given job as the PIC16 requires (if the PIC16 can do it at all), because the 65c02's instruction set is so much better. I have to ask though, how will code quantity be counted on processors that use odd instruction widths, like the PIC16's 14-bit instructions? 8Kb, ie, 1024 x 8 bits, is 8192 bits, which is 585 14-bit program words.

Outside a brush with Fortran IV in school in 1978, my first experience programming was on a TI-58c calculator, followed soon after by a TI-59 which had about 1K of memory and a card reader. I had one program that didn't fit in memory, so I had it do as much as it could with the initial load, then prompted for other cards when needed, and it overwrote the part of the program that wouldn't be needed for a while in order to accommodate the part that was needed next, kind of like a cache.

Are you sure? yes | no

Arduino Enigma wrote 11/18/2016 at 11:58

The KIM-UNO is an excellent platform to develop 6502 code. This contest sounds interesting...

Are you sure? yes | no

RigTig wrote 11/20/2016 at 12:23

I first used 6502 on a Synertec VIM-1 board about 1978: 1K RAM, hex keypad and 6x7-segment LEDs for output. After several upgrades and lots of learning, I did get FORTH running in 8K RAM. You can get a lot of heavy lifting from 1K of compiled FORTH code, especially if it is headless. Mmm...maybe I'll find a FORTH running on a modern device and see how big the code might be. Anyone know of a FORTH running on ESP8266?

Update: PunyForth runs quite well, but since the rules now include ROM code used, then kills using any Forth due to the 1K limit.

Are you sure? yes | no

Ed S wrote 11/23/2016 at 14:48

I hear you only need 512 bytes for Conway's Life on a 6502...

Are you sure? yes | no

Marek wrote 11/23/2016 at 17:32

I think I saw once an under 256 bytes implementation of GOL (with random colony and random sound) on a C64. Plenty of space, 1 kB to make it a feature rich implementation. :-)

Are you sure? yes | no

davedarko wrote 11/16/2016 at 09:34

Love those smaller contests so much and how everyone is already freaking out and asks questions although there aren't any rules posted yet :) :) :) hype :) :) :)

Are you sure? yes | no

Previous Next

The 1kB Challenge

Contest Details

Official Rules:

Judging Criteria:

Prizes:

Contest Logs

Collapse

And the winners are...

Grand Prize

First Prize

Second Prize

Third Prize

Final thoughts

Judicial Deliberations

CPLDs, FPGAs, and hard bootloaders

Details coming soon...

Submissions View all 133 submissions »

VR Skateboard with Arduino and Google Cardboard

Dice10

8008 1k Tiny BASIC

drillPresseur - Drill-Press with Force-Feedback

Discussions

The 1kB Challenge

Become a Hackaday.io member

Just one more thing

Contest Details

Official Rules:

Judging Criteria:

Prizes:

Contest Logs Collapse

Grand Prize

First Prize

Second Prize

Third Prize

Final thoughts

Submissions View all 133 submissions »

Enjoy this contest?

Discussions

Become a Hackaday.io Member

Eager to get building?

Report project as inappropriate

Send message

Remove Member

Contest Logs

Collapse