Whenever I am shopping for components I have a bad habit of adding a few extra toys to the shopping list if I come across something that looks interesting or is particularly cheap. None of these are particularly expensive but the majority of them get stored away because I don't have an immediate use for them. My spare parts drawer has rapidly grown into a spare parts cupboard.
One of these extra purchases turned up recently - a Stellaris Launchpad which is a nice little single board system based around an ARM Cortex M4F running at 80MHz, 256K of flash and 32K of RAM. It has a good a collection of ADC inputs and I2C, SPI and UART communications channels. In the spectrum of systems it fits somewhere between an Arduino and a Raspberry Pi although probably closer to the Arduino end. All in all it's a very nice piece of kit but I'm not going to get a chance to play with it for a while until I finish of some of the projects I already have in progress so into the spare parts cupboard it goes.
One of the benefits of collecting all these things is that you randomly come across something that will be useful in your current projects - a few days ago I rediscovered a small (about 1.8") 128x128 LCD display module I originally got from 4D Systems quite a few years ago. This module is very easy to interface with from a micro-controller - it just uses a simple protocol over a two pin RS232 interface to control the display.
I've been trying to come up with a project that can show off the Babyduino system - going from prototyping and experimentation to a breadboard layout to a final system on veroboard and PCB. I also wanted it to be an interesting and useful project, this part looked like it would help with that.
Unfortunately the part I have is very old (I think I originally got it back in 2006) and no longer manufactured. The guys at 4D Systems couldn't provide me with specifics on the protocol used by this module but suggested it would be a subset of the command set in their current products. I wrote a small Python script to test it out (being a simple serial connection means it's easy to control from a desktop or laptop through an FTDI cable). I managed to get image display (at full 16 bit color) and some basic rectangular fill operations working but many of the other commands simply didn't work (or were expecting parameters I hadn't provided).
Using all the capabilities of the display would be a little bit beyond an ATMega based system - it only has 1K of RAM for storage so most of the images would need to be stored in flash. A full 128x128 image at 16 bit would take up 32K which exceeds the capacity of most ATMega chips, an 8x8 pixel sprite would take up 128 bytes which quickly chews up space in the flash. This doesn't even take into account the time it takes to transfer the data over a serial connection to the LCD - at a rate of 115220 baud it takes quite a while to transfer a full screen image (even a small - 8x8 or 16x16 sprite - takes quite a while).
In a nice example of synchronicity I came across references to the Chip-8 system while looking through old magazine articles. This was a tiny register based virtual machine developed in the 70's purely for the purpose of developing games. It's virtual hardware included a monochrome display that was 64x32 pixels (the pixels were longer than they were wide).
I modified my Python script to simulate this by simply drawing rectangles on the screen to simulate individual pixels and got some good results (even when I dropped the baud rate from 115200 baud down to 38400). I'm satisfied I can drive this from an ATMega chip running at 8MHz so I dug through my spare parts and found I had everything else I needed so I think I have a decent sample project to work on. Of course it has been done before but this version has a few more restrictions so the software side should be interesting.
So there you have it - accumulating parts does pay off in the end, even if they sit idle for quite a long time.