1 KB Challenge: And The Winners Are…

January 13, 2017 by Adam Fabio 55 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 be over, but these projects are now out there for others to build, enjoy, and learn from.

I’ve wanted to organize this contest since [Jeri Ellsworth] and [Chris Gammell] took on the 555 contest way back in 2011. The problem is creating a set of rules that would be relatively fair to every architecture. I think 133 entries to this contest proves that we found a very fair set of constraints. It is safe to say this won’t be the last 1 kB Challenge here at Hackaday, so if you have ideas for future editions, share them in the comments!

Tiny Game Of Simon On An ATtiny13

December 31, 2016 by Elliot Williams 13 Comments

How much game can you get out of a chip with only 1 kB of flash memory and (five or) six free GPIOs? Well, you can get it to play the classic memory game, Simon. [Vojtak] is submitting this project for the 1 kB Challenge, but it looks like it’s already been used to teach simple microcontrollering to teenagers as well, so the code is actually straightforward to read, but full of nice features.

Neat tricks include sharing button-press sensing and LED driving on the same pin, which was necessary to make everything work on such a small chip. A simple linear-congruential pseudorandom sequence provides the variation, and it’s seeded by slow-clock/fast-clock timing jitter, so you’re probably not going to see the same sequence twice. (It’s not the best random number generator ever, but it’ll do.) If that weren’t enough, high scores (and the random seed for the game) are saved to EEPROM so that you can brag to your friends or re-live your previous moments of glory.

The board is easily solderable together as well. This is a fantastic beginner project, with details in the code that everyone can learn from. It’s a great game, and a great demonstration of what you can do with a dollar’s worth of parts and 1 kB of code.

Continue reading “Tiny Game Of Simon On An ATtiny13” →

Character Generation In 144 Bytes

December 15, 2016 by Adam Fabio 34 Comments

[Jaromir Sukuba] has an awesome BrainF*ck interpreter project going. He’s handling the entire language in less than 1 kB of code. Sounds like a great entry in the 1 kB Challenge. The only problem is the user interface. The original design used a 4 line character based LCD. The HD44780 controller in these LCDs have their own character table ROM, which takes up more than 1 kB of space alone.

[Jaromir] could have submitted the BrainF*ck interpreter without the LCD, and probably would have done well in the contest. That wasn’t quite enough for him though. He knew he could get character based output going within the rules of the contest. The solution was a bit of creative compression.

Rather than a pixel-by-pixel representation of the characters, [Jaromir] created a palette of 16 single byte vectors of commonly used patterns. Characters are created by combining these vectors. Each character is 4 x 8 pixels, so 4 vectors are used per character. The hard part was picking commonly used bit patterns for the vectors.

The first iteration was quite promising – the text was generally readable, but a few characters were pretty bad. [Jaromir] kept at it, reducing and optimizing his vector pallet twice more. The final design is pretty darn good. Each character uses 16 bits of storage (four 4-bit vector lookup values). The vector pallet itself uses 16 bytes. That means 64 characters only eat up 144 Bytes of flash.
This is exactly the kind of hack we were hoping to see in the 1 kB challenge. A bit of creative thinking finds a way around a seemingly impossible barrier. The best part of all is that [Jaromir] has documented his work, so now anyone can use it in the 1 kB challenge and beyond.

If you have a cool project in mind, there is still plenty of time to enter the 1 kB Challenge! Deadline is January 5, so check it out and fire up your assemblers!

Hackaday Links: December 11, 2016

December 11, 2016 by Brian Benchoff 31 Comments

We have a contest going on right now challenging you to do the most with 1 kB of data. If you want to get into this, here’s how you do it for a dollar. Use the PIC12C508A. It’s an 8-pin DIP, has 768 bytes of program ROM and 25 bytes of data RAM. [Shaos] is trying to generate NTSC on this thing.

Remember that Internet of Cookie Oven Kickstarter from the links post a few weeks ago? It was funded. It has a heating element that is ‘more energy efficient than traditional electric elements’, and there’s still no consensus over how a resistive heating element can be more efficient. It’s either 100% efficient, or 0% efficient, depending on how you look at it.

[Matthias Wandell], master of wood gears recently built a 20″ bandsaw from scratch. It’s a wood frame, wood wheels, a (currently) underpowered motor, and a few bits of metal and rubber. The video build log is fantastic, so start here and work your way forward.

Way back in the day, Sparkfun sold a Bluetooth rotary phone. Yes, at some point in the past, phones didn’t have touchscreens or even buttons. In any event, Sparkfun hasn’t sold these phones for quite a long time. Now there’s a new hotness: giving these rotary phones a GSM module.

Here’s a little Hackaday Events housekeeping. On January 23rd, we’re going to have a meetup in NYC. We’ll also have a meetup in LA sometime in January as well. Also in January I’ll be attending CES, reporting on the latest Internet of Toasters. A week later, Hackaday will be at ShmooCon in Washington, DC. At ShmooCon last year, we had a breakfast meetup in the DC Hilton. This year, I want to do something similar. If you have an idea of what to do, leave a note in the comments.

Bitbanging VGA Fits In Under 1 KB

December 8, 2016 by Adam Fabio 21 Comments

Don’t throw those old VGA monitors away, turn them into works of art with [danjovic] and VGA Blinking Lights. This circuit uses a PIC16F688 to generate VGA video. Not just a random spray of monochrome dots either. VGA Blinking Lights puts up an ever-changing display of 48 colored squares.

Originally created for the square inch contest, VGA Blinking Lights could hide behind a quarter. [Danjovic] dusted his project off and entered it in The 1 kB Challenge. The code is written in PIC assembly. The final hex used to generate the squares clocks in at 471 words. Since the PIC uses a 14 bit word, that’s just over 824 bytes. Plenty of space for feature creep!

Video is generated with a twist on the R2R DAC. [Danjovic] tweaked the resistor values a bit to obtain the correct voltage levels for the VGA standard. The color of the squares themselves are random, generated using a Galois Linear Feedback Shift Register (LFSR).

With only a handful of components, and a BOM cost under $5, this would be a fun evening project for any hardware hacker.

If you have a cool project in mind, there is still plenty of time to enter the 1 kB Challenge! Deadline is January 5, so check it out and fire up your assemblers!

Assembly Required: Subroutine Calls And The 1K Challenge

December 7, 2016 by Al Williams 35 Comments

The first computer I personally owned had 256 bytes of memory. Bytes. The processor in my mouse and keyboard both have more memory than that. Lots more. Granted, 256 bytes was a bit extreme, but even the embedded systems I was building as part of my job back then generally had a small fraction of the 64K bytes of memory they could address.

Some people are probably glad they don’t have to worry about things like that anymore. Me, I kind of miss it. It was often like a puzzle trying to squeeze ten more bytes out of an EPROM to get a bug fix or a new feature put in. I though with the 1K challenge underway, I might share some of the tricks we used in those days to work around the small memory problems.

Continue reading “Assembly Required: Subroutine Calls And The 1K Challenge” →

The ESP: A New 1kB Contender Appears

November 30, 2016 by cnlohr 28 Comments

The ESP8266 is officially checking into the Hackaday 1kB Challenge. Doing something meaningful in 1kB of compiled code is tricky; modern SDKs like the ones often used for ESP8266 compile even the simplest programs to nearly that size. If you want to use this hardware in your 1kB Challenge entry, I have a solution for you!

The ESP8266 now has a barebones build environment focused on minimizing code size, as little as 131 bytes to boot up and blink an LED. It also “supports” some new, insane clock rates (like 346 MHz) and crazy development cycle speeds. The WiFi is stuck in “airplane mode,” but it will be worth your time to consider the ESP for the next non-WiFi project you’ll be doing.

Far too often, we follow design patterns that ‘just work’ instead of looking for the ones that are optimal because we’re afraid of wasting time. The benefits of keeping code tight and small are frequently overlooked. When code is small and environments minimal, RAM and FLASH become easier to come by, compiled binaries shrink and time wasted by compiling and flashing can decrease by an order of magnitude! We rarely see just how much value is added when we become a good engineer: being done only when there’s nothing left to remove from a design. Nosdk8266 will let you see what it’s like to test out code changes several times a minute.

Just a month ago, when preparing the ESP8266 for a USB bootloader, I had to make a stripped-down environment for it. It’s not based on the Official Non-OS SDK or the RTOS sdk, but an environment that can boot up and blink an LED. Not just blink an LED, but tweak the clock in some totally unexpected ways and even run the I2S bus (used for espthernet and Color NTSC Broadcast Video). If you’re not at the submission phase for your 1kB challenge, you can even use the mask ROM for printf! Now you can tweak your code and — in under 2 seconds — see what the new code does!

Even in PICO mode, the part still has to use the mask ROM to be loaded, but thankfully, the 1kB Challenge has added an exception for unavoidable bootloaders. No longer bound by the shackles of WiFi, I can’t wait to see what you’ll do with the ESP8266. Just beware that the processor may not work reliably when overclocked at 346 MHz (332.5%,) and you’ll certainly be voiding any warranties you may have. Sounds like fun, right?

Editorial Note: This is a guest article from Charles Lohr, aka [CNLohr]. Although he has written a few other guest articles, he is not a regular contributor to Hackaday and therefore, this article does not disqualify him from entering the 1kB Challenge. We felt it more fair to publish this article which shares the tools he’s using to make code smaller, rather than to keep them to himself for fear of disqualification. While we have your attention, we wanted to mention one of Charles’ articles which was published on April 1st — we still think there’s a lot of people who don’t realize it wasn’t a prank.