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!
Reminds me of the Star Trek (TOS) backgrounds on the bridge and engineering. Very cool design with minimalist parts. Like it.
Admittedly pedantic but VGA Blinking Lights can only almost but not quite hide behind a quarter. Neat project though, generating VGA or any video signal with a pretty limited microcontroller is generally kind of difficult to do given the bandwidth (and sometimes pin count) needed.
Would be nice to see more powerful “real time” type microcontrollers out there that can do HDMI but at a more reasonable price point. Looking at you BBB. Raspberry Pi is getting though but it’s not really a microcontroller. Are there any out there that do this that are not $100 or more each?
Let’s see a 4K version at 120 Hz challenge next. Might need more than 1Kb for that though?
It could easily be built with SMT, making it amazingly small.
If you can create VGA you can create HDMI, simply attach a DVI transmitter IC instead of the VGA DAC. You could look into the Orange Pi Zero. It is a quad core ARM with 512MB RAM and HDMI. It costs around 7€ delivered. It also has wifi and ethernet.
There’s no HDMI on the Orange Pi Zero, though. Just sayin’ b/c I’m in the middle of writing up a review.
The point that there’s a ton of SBCs that’ll do HDMI is still spot-on.
Very cool project. I don’t own a PICKit or else I’d order the components today. I may look into converting the source to AVR assembly this weekend though. Hats off to danjovic on a very neat project!
PicKit programmer is kind of opensource so you can get them for under $10 on ebay
I’m tempted to do thins in VHDL for the 1k competition as a bit of a stir.
I recon it would take about 16 bytes of RAM an zero bites of code. A highly unfair advantage.
How big do you think the FPGA bitstream would be?
Well Only very small, so small that it will fit into a small CPLD.
The real question is – how relevant is the size of the bitsream?
The binary limit for the contest is 1K.
Yes but including all of the bitstream for a CPLD/FPGA would be like including the tape out data that was sent to that manufacturer of a CPU/MCU of other projects.
Nah I reckon the 1K limit counts, if you’re cheeky enough to submit “code” in VHDL. How about the source code has to be less than 1K? You’ll have to use single-letter variable names and things. Or maybe check the bitstream, I’ve no idea what unencrypted CPLD bitstreams look like, but you could limit it to 1K of “active” information, the rest all being 0s or FFs or whatever CPLDs use for “tie it to GND”.
@[Greenaum]
Well yes but the 1KiB limit is a run-time limit. A CPLD/FPGA bit-stream only specifies a State Machine and a beginning state. It can be a Turing complete state machine just like a Micro-controller with registers and sRAM if you want.
I think it would be fair to count the Bytes that create the initial state but not the Bytes that create the state machine itself because the a Micro-controller is also a state machine and the the Bytes that created the logic of the chip (AISC) are not included.
The problem is this: How do you subtract an initial state (in Bytes) from the state machine in HDL?
https://www.youtube.com/watch?v=qucJMObCUpI
This is done with 6 pin AVR in 312 bytes… should I submit this as an entry? :P
Yes. It’s a valid entry and although it doesn’t do that much – there is probably not much more that could be done close to the 246 byte mark.
Maybe I should make it do something more fancy then, there’s still 200 bytes of flash free on that huge chip ;)
My apologies. After re-reading my comment I realize that it didn’t come out quite right.
Perhaps I should have worded it this way:
There is probably not much more that could be done close to the 256 (sic) byte mark. This light weight code will probably hit higher on the bang for byte scale than it’s heavier competitors.
So Yes. It’s a certainly a valid entry.
Kudo’s, excellent code. I hope it gets included.
Thanks!
I just need to figure the following mess out to schematic: https://drive.google.com/file/d/0B2dTzW9TMeBxbTQ5WVVRTTRsa3M/view
:D
Absolutely submit it!
Can you add a few more bytes to enable degaussing the monitor?