1. Simple low resolution dot drawing
2. A font example
3. A very quickly and badly written demo of pong

The software runs on an Attiny84 micro controller clocked at 16Mhz, paired up with a Microchip MCP42100 dual 100k 8 bit digital potentiometer though the Attiny’s USI (Universal Serial Interface) pins. This is a fast, stable and accurate arrangement, but it requires sending 16 bits every time you want to change the value of one of the potentiometers so its also very piggy. I was just out to have some fun and did not have a proper 8 bit DAC. This was the closest thing outside of building one.
Join us after the break for pictures a (very) brief video and more.

This project has a total resolution of 256x256x1. This sounds like a lot of resolution but don’t get too excited. You can have only a few hundred to maybe 1000 pixels on screen before it starts flickering pretty badly. I am sure this can be solved by someone who is not using GCC commands for almost all of an Arduino script, furiously tying to shove 16 or 32 bits of data out of its SPI port PER PIXEL with an Attiny that has no dedicated SPI.

I had originally thought that I was going to do some form of raster scan display, much like a TV or computer monitor scanning a row of pixels one column at a time. You can see examples of this on electronixandmore in the projects section where the author converts RS170 television, and also VGA to an oscilloscope (along with a bunch of other cool stuff). Also take a look at this project that ran recently on Hackaday: NintendOscope.On my little 84 it ended up being extremely slow to scan each and every pixel and then modulating the Z axis on the back of the scope to change the pixels brightness.

Ok fine let’s keep it simple, how about some vector lines? I copied the site’s logo and quickly traced it out using the gimp using its [Web > Image Map] function. This spits out a file like this:

<img src="Untitled.bmp" width="125" height="120" border="0" usemap="#map" />
<map name="map">
<!-- #$-:Image map file created by GIMP Image Map plug-in -->
<!-- #$-:GIMP Image Map plug-in by Maurits Rijk -->
<!-- #$-:Please do not edit lines starting with "#$" -->
<!-- #$VERSION:2.3 -->
<!-- #$AUTHOR:kevin -->
<area shape="poly" coords="17,16,36,37,49,66,37,98,20,103,19,48" nohref="nohref" />
</map>

By drawing only points in that file I was able to produce the first “image” below. With a little refinement I produced a slightly cleaner result in the second image. As you can see you have to be very mindful where your little pointer is going because it leaves a trail. I was not really happy with the quality of these first try results, though its generally a very fast way to draw out wire-frame polygons (think Asteroids).

I ended up doing a mix. Instead of scanning every row and column, I only scan the rows and columns that have pixels to show. This produces a dot matrix image. I also needed an easy, but not epic, effort to convert images from computer to AVR. This was accomplished using the gimp, the XPM image format, and a little blob of lua.

Using the Hack a Day logo as an example, I roughly cropped out the skull and then used [Image >> Autocrop Image]. Next I went to [Image >> Canvas Size] and changed this to a 128×128 canvas. Finally I used [Image >> Flatten Image] with black set as the color background. The next step is to remove the black background. That’s easy enough with [Colors >> Color to Alpha].

I could display this as a solid raster but it would be way too slow to make out an image with this hardware and software. I need to remove most of the pixels. In order to do this, I use a quickie gimp cheat, go to [Filters >> Alpha to Logo >> Neon]. Now change the effect size to 5 and the glow color to white. Finally, delete the neon glow layer and flatten.

Since I am using a 1 bit per pixel color choice, I use [Image >> Mode >> Indexed], and choose 1 bit with no dithering. This produces a high quality outline of the logo, but it is still heavy on the pixels. In order to trim both ROM space and draw time I removed every other row and column by using [Filters >> Distorts >> Erase every other row]. I want it to fill with background which should be black. I did this once with rows and once with columns, even or odd is your choice, whichever looks better..

I dug in at 800% and touched up all the graphics with a 1 pixel paintbrush and saved as XPM format. XPM format is a basic text format where different characters represent a different pixel and color value. With only 1 bit per pixel you can quite clearly see the image in the text.

I removed the entire header, and so a lua script could phrase it I added “strings ={“ minus quotes so the file looks like:

strings = {
“data”,
“data”,
};

after the bracket and semi colon I added the following little blob of lua:

file = io.open("logo.out","w")
counter = 1;
for y = 1, #strings do
    for x = 1,#strings[y] do
        if string.sub(strings[y], x, x) == "+" then
            file:write(y .. ",".. x .. ",")
            counter = counter + 1
        end
    end
end
print(counter*2)
file:close()

This scans through the data and makes a file that contains a single line of comma separated values of every white pixel of the graphic. It also spits out a number in the command line which is the number of pixels * 2 for number of XY values. You need to know the number of pixels if you want to draw any graphic since the program loops though the lua generated CSV file. It’s basic and big but it works well enough for the example.

If you have lua installed its generally “lua filename.ext”, sometimes “lua51 filename.ext”, minus the quotes.

AvrGCCiberishduino code is an Arduino sketch with void setup, void loop, and I used analog read because there was no advantage to implementing it myself. Arduino’s expandability to other models of AVR and simplified functionality does very good for many things. When you need to bring out the speed it has its issues.

Pretty soon you are twiddling port registers and looking into how to use the USI (universal serial interface) to send out SPI because it is faster than you can do it in software blah blah blah. Eventually I had an Arduino sketch tied to only the attiny84, though one would need to only change pins for other attiny’s like the 85 or 2313.
Atmegas, like what is on a normal Arduino would need different SPI code to function.)

// System
#include <avr/pgmspace.h>
#define cmdOne 0x11 // write to pot 0(X)
#define cmdTwo 0x12 // write to pot 1(Y)

// Graphics
prog_uchar hadlogo[] PROGMEM ={5,19,5,21,5,23,5,25,5,103,5,105,5,107,5,109,6,27,6,101,7,19,7,29,7,99,7,107,7,109,8,21,9,23,9,31,9,97,9,105,11,25,11,33,11,95,11,103,13,26,13,34,13,94,13,103,15,25,15,35,15,93,15,103,17,23,17,35,17,93,17,105,19,7,19,9,19,21,19,35,19,92,19,107,19,119,19,121,21,7,21,11,21,19,21,36,21,91,21,109,21,117,21,121,23,8,23,13,23,15,23,17,23,37,23,89,23,111,23,113,23,115,23,121,25,9,25,39,25,87,25,119,27,10,27,41,27,85,27,118,29,11,29,43,29,83,29,117,30,13,30,45,30,115,31,15,31,47,31,81,31,113,32,17,32,111,33,19,33,21,33,23,33,25,33,49,33,57,33,59,33,61,33,63,33,65,33,67,33,69,33,71,33,79,33,105,33,107,33,109,34,103,35,27,35,51,35,53,35,55,35,73,35,75,35,77,35,101,36,99,37,29,37,31,37,49,37,77,37,97,39,33,39,47,39,79,39,95,41,35,41,45,41,81,41,93,43,37,43,43,43,83,43,91,45,39,45,41,45,85,45,89,47,40,47,87,49,39,49,87,51,38,51,88,53,37,53,89,55,37,55,47,55,49,55,51,55,53,55,55,55,71,55,73,55,75,55,77,55,89,56,79,57,37,57,45,57,57,57,69,57,81,57,89,59,37,59,45,59,57,59,69,59,83,59,89,61,37,61,44,61,57,61,69,61,83,61,89,63,37,63,57,63,69,63,83,63,89,64,43,65,37,65,53,65,55,65,70,65,73,65,83,65,89,66,45,66,51,66,75,67,37,67,47,67,49,67,77,67,83,67,89,68,79,69,37,69,81,69,89,71,36,71,38,71,63,71,65,71,89,71,91,73,35,73,39,73,87,73,93,74,64,75,33,75,40,75,86,75,95,77,31,77,41,77,63,77,65,77,85,77,97,78,29,78,99,79,27,79,42,79,83,79,101,80,25,80,104,81,17,81,19,81,21,81,23,81,44,81,82,81,107,81,109,81,111,82,15,83,13,83,46,83,81,83,83,83,113,83,115,85,11,85,43,85,47,85,80,85,85,85,117,87,9,87,41,87,48,87,58,87,70,87,80,87,87,87,119,89,8,89,39,89,49,89,57,89,59,89,69,89,71,89,79,89,89,89,121,90,15,91,7,91,13,91,17,91,37,91,51,91,53,91,55,91,61,91,63,91,65,91,67,91,73,91,75,91,77,91,91,91,111,91,113,91,115,91,121,93,7,93,11,93,19,93,35,93,91,93,109,93,117,93,121,95,7,95,9,95,21,95,35,95,92,95,107,95,119,95,121,97,23,97,35,97,93,97,105,99,25,99,35,99,93,99,103,101,25,101,34,101,94,101,103,103,25,103,33,103,95,103,103,104,23,105,21,105,31,105,97,105,105,105,107,107,19,107,29,107,99,107,109,108,27,108,101,109,19,109,21,109,23,109,25,109,103,109,105,109,107,109,109};

// Functions
void qshift(byte input) // using the USI for SPI
{
USIDR = input; // put a byte into the register
USISR = _BV(USIOIF); // clear flag
while ( (USISR & _BV(USIOIF)) == 0 ) // send away
{
USICR = (1<<USIWM0)|(1<<USICS1)|(1<<USICLK)|(1<<USITC);
}
}
void latch(bool state) // toggle CS pin on digipot
{
if(state == 1) PORTA |= (1 << 3); // raise the latch
else PORTA &=~ (1 << 3); // lower the latch
}</p>
void logoscrn() // draw the Hack A Day logo
{
for (int i = 0; i < 674; i += 2)
{
// 0,0 on an image is upper left, on scope its lower left
// subtract pixel Y value from 255 to flip right side up
latch(0); // lower the latch
qshift(cmdTwo); // send the write channel two command
qshift(255 - (64 + pgm_read_byte_near(hadlogo + i))); // send Y data
latch(1); // raise the latch
// image is offset by 64 as it is only has a 128x128 canvas
latch(0); // lower the latch
qshift(cmdOne); // send the write channel one command
qshift(64 + pgm_read_byte_near(hadlogo + (i + 1))); // send X data
latch(1); // raise the latch
}
}
// Arduino Setup
void setup()
{
// set pins of PORTA, PA7 & PA2 as inputs, the rest are outputs</p>
DDRA = 0x7B;
}
// Arduino Loop
void loop()
{
logoscrn();
}

As you can see, this is a much improved picture quality.

The other 2 demos use this basic system with a button wired up between pin 6 and ground to switch demos. Demo 2 uses a counter and a scale variable to zoom from the upper left corner to full size large font with 3 lines of text and room for a few more. Demo 3 is the start of a sloppy pong game with a (stupid and jumpy) cpu opponent, no scorekeeping and a looping ball. Just hook up a potentiometer with one end on ground the other on +5 and the middle to pin to pin 11 of the Attiny84.

Software.zip you will need a Programmer, Arduino or Arduino Core, and Arduino Tiny

Unfortunately for now I have to move on from this idea, but please fear that I shall return soon enough!

[Andrew Rossignol] was curious one day and decided that he wanted to display graphics on an oscilloscope after playing around with the X and Y inputs.

[Andrew] started out with a resistor ladder on the DAC of his AVR Butterfly. He was able to to draw a line on the oscilloscope’s screen but bandwidth limitations forced him to reconsider his approach. A friend wrote a Python script to generate C code so the ports of the Butterfly can be toggled. After getting the Butterfly to generate a voltage for every non-white pixel, [Andrew] was impressed with the results so the code was modified determine the brightness of each pixel. The setup managed 10 shades of gray and careful selection of what graphics to post on the build log assured the project a little bit of blog cred.

There are a few ways to display a picture on an oscilloscope, like plugging the Hsync and Vsync into the inputs of a scope. Except for a few music visualizations, we haven’t seen a scope display generated from a microcontroller. Great work [Andrew], but we’d like to mention there’s a grayscale Hack a Day logo from way back when.

Check out a video of [Andrew]‘s oscilloscope after the break.

Our initial view of the Spy Video TRAKR “App BUILDR” site had us believing this would be an internet-based code editor and compiler, similar to the mbed microcontroller development tools. Delving deeper into the available resources, we’re not entirely sure that’s an accurate assessment — TRAKR may well permit or even require offline development after all. Regardless of the final plan, in the interim we have sniffed out the early documentation, libraries and standalone C compiler and have beaten it into submission for your entertainment, in order to produce our first TRAKR hack!

TRAKR software development at the moment, to phrase it just as politely as we can, has a Wild West flavor to it. The finished tools and reference materials aren’t expected until October. Early documentation is rough — entire sections still missing — so it’s frequently necessary to rummage through their example code to learn how things operate. And the compiler is exceedingly rough right now…it requires a minor patch just to get started, and works only within Cygwin, a UNIX-like command shell for Windows systems. So tonight we’re gonna program like it’s 1999! To continue, we’ll have to assume you’re at least vaguely familiar with command-line development tools, as explaining the entire process from scratch is more than we can fit here.

It probably goes without saying, but for posterity: these are beta tools and the entire process will almost certainly change as the TRAKR HAKR site nears release, rendering these directions obsolete. Until then, for those wanting to get an early start, here’s how we began building our own TRAKR hacks…

Getting the compiler

The C compiler and documentation are presently located on the Apps Help page of the TRAKR web site. Just follow the directions there to download the App Primer (containing the compiler and demo source code), the TRAKR Codebook PDF (an introduction to TRAKR programming), and the Function Reference and code snippets for lighter-weight reference once you’re familiar with the concepts.

The Apps Help page states that the tools work with Linux, but this isn’t entirely true. The App Primer ZIP file contains only the Cygwin (Windows) toolchain, along with the TRAKR libraries and sample code. The C compiler is based on arm-elf-gcc 3.4.6 — Linux users might stand a chance with the pre-built 3.4.3 package from the GNU ARM web site. You’ll still need to download the App Primer for the libraries. With Mac OS X, things get ugly…we’ve yet to locate a viable package for Intel Macs. Building the 3.4.6 toolchain from source (or via MacPorts) has brought only frustration, and the TRAKR makefiles don’t play nice with later (but working) arm-elf-gcc editions. Joy. Eager to move ahead, and not wanting to invest a lot of time on beta tools that are certain to change, some of us are simply using the Windows package in VirtualBox for now.

Getting the compiler to actually work

After unpacking the App Primer ZIP file, copy the TRAKR.1 folder inside to a suitable working location within your Cygwin directory. The _MACOSX folder can be deleted — this is just an artifact of the files having passed through a Mac at one point; there are no OS X build tools here.

Just unpacking the Primer and trying to compile the examples, you’ll encounter a slew of “undefined reference” error messages and a failed build. There’s a problem with the TRAKR library — some test data that’s not properly archived — but it’s a straightforward fix. Go into the Internals directory and edit the Makefile using vi (or another editor of choice if you have one installed). Line 22 looks like this:

OBJECTS = $(S_OBJECTS) $(O_OBJECTS)

It should be changed to this:

OBJECTS = $(S_OBJECTS) $(O_OBJECTS) $(O_IMAGES)

Save the changes and exit the editor, then (still in the Internals directory) type:

make trakr.a

Now you can go back to any of the examples and successfully compile by typing “make”. For example:

cd ../EX06_Sound
make

This will create a “.bin” file that can be loaded onto the TRAKR. Attach a USB cable between your computer and the TRAKR vehicle (the power switch can be on or off, it doesn’t matter). In a moment, the TRAKR’s internal storage will show up as a small removable drive. Then just copy the .bin file to the APPs folder on this drive, e.g.:

cp EX\ Sound.bin E:APPs

Disconnect the USB cable, power up the TRAKR and remote, press the remote’s Home button and use either stick to navigate to the “EX Sound” menu item, then press the “Go” button. The app should prompt you to record 10 seconds of audio from the TRAKR’s microphone, then plays this back. Cool stuff!

Writing your own apps

Each TRAKR app is required to have three functions: Start(), Run() and End(). Your Start() function contains one-time initialization code, such as opening the motors to software control; End() is the complimentary function for when your program finishes, restoring control to normal TRAKR operation. Run() contains the meat of your application…this function is expected to return either “true” or “false” to indicate whether it should run again iteratively, or is ready to exit.

The header file svt.h contains constants and prototypes for the functions described in the Codebook and reference documents. This includes high-level functions for producing graphics and sound, turning the infrared LED on or off, reading the controls, driving the motors and accessing the SD card. This is all the Official Documented Stuff thatApp BUILDR will encourage us to use.

But there’s a second header, JAPI.h, revealing much of the underlying functionality on which the TRAKR library is built. And for the time being, this is the only way to access the really interesting stuff like digital I/O, video processing and USB host. This is most definitely not the Official Documented Stuff, and relying on it now means your code will probably require some changes to work with the Official Stuff later.

There’s something conspicuously absent from both libraries: higher-level digital I/O such as serial UART or precise PWM control. We’re not even certain yet whether any the accessible breakout lines correspond to these hardware functions. Maybe it’s something forthcoming, or maybe this will require the chip datasheet, with code talking to the registers directly. Worst case, such I/O will just have to be done with slower bit-banged methods. Which is exactly what we do with…

Our first hack

We really wanted to showcase both the software and hardware hackability of the TRAKR. There isn’t the space for an overly-technical writeup, but neither do we want to send you off with a trivial modification. Hopefully we’ve found a good balance here…mildly esoteric, but most readers with modest prior soldering and programming experience should be able to follow along and create something similar.

Our inspiration came from an earlier Hack a Day article about the txtBomber, a handheld dot-matrix graffiti printer:

The width of the TRAKR is about the same as a sheet of paper. With a row of solenoids and some paint markers, we could make a fantastic mess with this…or even simpler, skip the markers and head to the beach, having the TRAKR “comb” messages in the sand.

Problem is, we didn’t have a stack of solenoids on hand, and we wanted to get right into this rather than wait around for parts to arrive. Rooting among the detritus of our secret underground vault, we found a great substitute from a prior project: a row of 48 addressable LEDs driven by shift registers, the board on which they’re mounted perfectly matching the TRAKR’s 10 inch width! So our aim now was to achieve the same effect in light. The TRAKR moves too slowly for retinal persistence of vision to occur, but we could use long exposure photography to capture the results.

Anyone can buy a TRAKR off the shelf now, but the light bar was something custom-made for a POV project. The good news is that it’s a very common circuit, something we’ve linked to before, and a slightly scaled-back version can be built on a breadboard. Ours has a set of six 75HC595 shift registers with decoupling caps, each driving eight LEDs with associated current-limiting resistors. Very similar to what’s shown in that article, but cascaded out to six chips. You could also do something similar (and way more colorful) using ShiftBrite LEDs.

The LED board is held to the ’bot with masking tape. Spared no expense!

As pointed out in our teardown, the all-important JACK3, containing the GPIO lines, is smack dab in the middle of the TRAKR main board. The unpopulated header USB2, which we’ll use as a power tap, is closer to the outside edge.

In our haste to create a presentable demo, we just soldered wires directly to the TRAKR’s circuit board, but at some point intend to dismantle the thing again and solder on a proper header for inserting wires. For +5VDC and ground, the VDD5V and VGND pads of the idle USB connector are used. The shift registers require three data lines (as we’ll explain in a moment), and we opted to use the first GPIO lines on the board, labeled GPC0, GPC1 and GPC2.

The shift register interface, referred to as a 3-Wire serial connection or sometimes SPI (Serial Peripheral Interconnect), is a synchronous serial interface, meaning that each bit of data is accompanied by the synchronized tick of a clock bit on another line. A third line, called the latch, signals the end of the data transmission — in the case of an 8-bit shift register, this will output on its 8 parallel data lines the last 8 bits that were “clocked in” over the serial connection.

For our light bar hack, we’ll use GPC0 as the clock line, GPC1 as the data line, and GPC2 as the latch. Most microcontrollers feature some kind of native 3-Wire/SPI support, but as mentioned earlier, with the TRAKR library at present we’ll have to trigger all these bits through software control.

Next thing we need is an image to display on the LEDs, one row at a time. Naturally, we’re going to use the Hack a Day logo:

In the source code archive provided later, the image is present as a 1-bit Windows BMP file, simple to work with because the data is uncompressed. The image is turned sideways as it requires less code for the program to decode each horizontal row of the bitmap than it would for processing vertical columns. It’s 48 pixels wide, corresponding to the 48 pixels in the LED bar, and 60 pixels high, including some blank lines at either end so repeated logos don’t run one into the next.

Our example program is hardcoded for this one demo image, which is embedded in the executable. A more sophisticated program might allow the user to load an image from the SD card, and would properly parse the BMP header to query the actual image dimensions. Again, we’re just looking to keep the code simple and not stretching out to hundreds of lines.

// POV demo for Spy Video TRAKR w/shift register LED bar.

#include "svt.h"  // Official API
#include "JAPI.h" // Secret sauce

#define ROWS  60 // Image height in pixels
#define COLS  6  // Image width in bytes (pixels = 8x this)
#define PAD   (3 - ((COLS - 1) & 3))
extern unsigned char _binary_logo_bmp_start[]; // In logo.o

#define CLOCK (1 << 0)  // GPC0
#define DATA  (1 << 1)  // GPC1
#define LATCH (1 << 2)  // GPC2

void Start()
{
  JAPI_SetIoOutputMode(CLOCK | DATA | LATCH);
}

bool Run()
{
  unsigned char *ptr, byte;
  int r, c, b;

  // 62 byte offset to start of image data within BMP:
  // 14 byte BMP header, 40 byte DIB header, 8 byte palette
  ptr = &_binary_logo_bmp_start[62];

  for(r=0; r<ROWS; r++) {     // Each line in image
    for(c=0; c<COLS; c++) {   // Each byte in line
      byte = *ptr++;
      for(b=128; b; b>>=1) {  // Each bit in byte
        if(byte & b) JAPI_SetIoLow(DATA);
        else         JAPI_SetIoHigh(DATA);
        JAPI_SetIoHigh(CLOCK);
        JAPI_SetIoLow(CLOCK);
      }
    }
    JAPI_SetIoHigh(LATCH);
    JAPI_SetIoLow(LATCH);
    Sleep(20);
    ptr += PAD;  // BMP rows start on 4-byte boundary
  }

  return true;
}

void End()
{
}

The graphics-related #defines should be clear by now, we know this program is set up for this one specific image. The CLOCK, DATA and LATCH #defines correspond to the individual bits passed to GPIO-related functions, making subsequent code easier to read.

In the Start() function, the call to JAPI_SetIoOutputMode() initializes all three lines as outputs.

Because of the way the image is formatted, there’s minimal work now to be done in the Run() function. For each horizontal row of the image, six bytes of image data are output one bit at a time, 48 bits total: the DATA line is set either high or low to indicate the corresponding 1-bit pixel value, and then the CLOCK line is quickly toggled high and then low to “clock out” the data bit. At the end of each row, the LATCH line is similarly toggled to tell the shift registers to display the new data. A 20 millisecond delay holds the image for a moment so it’s not all scrunched together, given the TRAKR’s limited speed.

The next line advances the image pointer to the start of the next row, if required. In BMP files, rows are always a multiple of 4 bytes wide. Our bitmap is only 48 pixels (6 bytes) across, so this skips the two extra bytes at the end of each row. The final “return true;” line tells the TRAKR library to repeat our Run() function again indefinitely.

The End() function is empty for this program, but it still needs to be present to keep the linker happy.

A ZIP file containing the above source code, bitmap image and makefile can be downloaded here. Extract this archive within the Trakr.1 folder, alongside (not within) the Internals directory. “cd” to this directory and type “make”. If all goes as planned, this should produce the file POV.bin, which can be loaded on the TRAKR as described earlier.

Even in this early stage, warts and all, we’re quite excited by the prospects for this toy’s hackability. Wild Planet is to be applauded for their open-minded approach in encouraging software and hardware modifications. A lot of comparisons are already being made to the Roomba and Rovio, both of which have spawned enthusiast sites and even books. Time will tell if the Spy Video TRAKR catches on the same way.

So that’s our TRAKR hack…now let’s see yours! When you’ve got something cool to showcase, don’t forget to tip us off!

Programmer/designer [Steven Wittens] has posted a fantastic write-up on the black art of producing compact demo code, dissecting his own entry in the 1K JavaScript Demo Contest. The goal is to produce the best JavaScript demo that can be expressed in 1024 characters or less and works reliably across all standards-compliant web browsers.

[Wittens] details several techniques for creating a lot of visual flash in very few bytes, including the use of procedural graphics rather than fixed datasets, exploiting prime numbers to avoid obvious repetitions in movement, and strategically fudging formulas to save space while adding visual interest. These methods are just as applicable to other memory-constrained situations, not just JavaScript — some of the contest entries bear a resemblance to the compact microcontroller demos we’ve previously showcased, except running in your browser window.

The contest runs through September 10th, allowing ample time to come up with something even more clever. Whether he wins or not, we think [Steven] deserves special merit on account of having one of the most stylish blogs in recent memory!

[Keith Peters]‘ blog Art From Code is devoted to his beautiful graphics from computer source code, also known as generative art. Although [Peters] is reluctant to reveal his source code, algorithmic graphics can be created with the help of tools like ActionScript, Flash, and Flex. There are some great tutorials that can start you on the path to making your own evocative art.

[via Neatorama]