Play Zork on your TV with an Arduino.

Who doesn’t love Zork?. Who doesn’t love Arduinos? Why not grab a few cheap components and build an Arduino gadget capable of playing all the classic Infocom games on your TV from the comfort of your couch.

A few years ago I ported a Z-Machine player to a little arduino-like device. Ever since I have been meaning to get around to a project that would work on a TV with a real keyboard and once again rekindle fond memories of long nights playing Zork on my Atari 800.

You will need:

  • Arduino UNO, Pro, Pro Mini or equivalent.
  • SD card or micro SD card + breakout board (from Adafruit, eBay etc).
  • RCA A/V Cable (eBay).
  • 470ohm, 1k and 100k resistors.
  • Breadboard, wires etc.
  • WebTV or MsnTV IR Keyboard or PS2 a nasty old PS2 keyboard (eBay).
  • IR receiver TSOP38238,TSOP4838 or equivalent (Adafruit, Mouser etc).

Building it

The schematic is very simple:

        +----------------+           +-----------------+
        |                |           |                 |
        |             13 |-----------| SCK    micro\SD |
        |             12 |-----------| MISO   card     |
        |             11 |-----------| MOSI   module   |
        |             10 |-----------| CS              |
        |                |      5v <-|                 |
        |                |     GND <-|                 |
        |    arduino     |           +-----------------+
        |    uno/pro     |
        |                |       5v <--+-+   IR Receiver
        |                |      GND <--|  )  TSOP4838 etc.
        |              8 |-------------+-+
        |                |
        |              6 |----[ 100k ]--------> AUDIO
        |                |
        |              9 |----[  1k  ]----+---> VIDEO
        |                |                |
        |              1 |----[ 470  ]----+
        |                |
        |              3 |----------------> *PS2 CLOCK
        |              2 |----------------> *PS2 DATA
        |                |

Layout on an Arduino Uno…

…and on a Mini Pro.

Just about any SD card or microsd card breakout will do. Some of the very cheap ones (<$1) don’t have 5v to 3v3 level converters and may fry your SD card so caveat emptor. As always, Adafruit has nice ones.

WebTV keyboards come in various guises: WebTV, MsnTV, Displayer, UltimateTV etc. They all should work just fine. A few places have the nice Philips variant new for $11.95 w/ free shipping (search for ‘SWK-8630’). This one comes with a nice PS2 IR receiver; more on it later.

IR receivers come in a number of different forms. You are looking for a 38khz version with a known pinout: Some have the center pin as GND, some as V+. Make sure you know what kind you have. When in doubt, Adafruit.

I like using iPhone/iPod video cables for TV projects. Because they no longer work (their MFI chips long since revoked) they are inexpensive, are labeled internally and have a strain relief grommet.

If you have an IR keyboard then good for you. If not, connect your nasty old PS2 clock and data lines to pins 3 and 2 then order an IR keyboard.

On the disk

The microsdfiles folder contains a zd.mem pagefile along with several sample games:

tutorial.z3 Introduction to interactive fiction and a little bit of Zork I

Samples of Planetfall, Infidel, and The Witness.

Samples of Zork I, Leather Goddesses of Phobos, and Trinity

A nice big chunk of Zork I that was given away with the British Commodore users’ magazine “Zzap! 64” no. 67. in 1990.

Copy these files to a freshly formatted sd or microsd card. You can find lots of other Zorkduino compatible games at the Interactive Fiction Archive. Insert the card and run the zorkduino.ino sketch from the zorkduino folder. When it is all up and running, it should look like this (depending on how many games you found):


How it works

Squeezing Zork into the limited footprint of an Arduino proved to be a bit of a challenge. The code uses a port of Mark Howell and John Holder’s JZIP, a Z-machine interpreter. The Z-machine was created in 1979 to play large (100k!) adventure games on small (8K!) personal computers. Long before Java the implementors at Infocom built a virtual machine capable of paging, loading and saving complete runtime state that ran on a wide variety of CPUs. Clever stuff.

The trouble is the Arduino only has 2k of ram. The Z-machine interpreter uses 2k for its stack alone, leaving no room for dynamic memory, disk buffers, video frame buffers, avr stack and other program state. The solution is to virtualize all stack and memory accesses from the interpreter down to a 160 byte cache and a 512 byte disk buffer. Thats where the zd.mem file comes in – a megabyte or so of virtual stack, memory and save-game slots.

Virtualizing everything slows things down a bit but serendipitously makes the Arduino perform at roughly the same speed as my old Atari 800. Video needs 912 bytes for the frame buffer, leaving ~464 bytes for the avr stack and all application and interpreter state.


The video is generated with a simple state machine on the Timer1 ISR. HSYNC interrupts occur at 15.73kHz and trigger state changes for video, audio and keyboard state machines.

Active video is 308×192 pixels, 38×24 8×8 charaters. Getting this resolution requires use of the UART in SPI mode running at top (8Mhz) speed to shift out pixels from either a character font (the Atari 800 default font) or a graphics font (an extravagant waste of 2k logo). Because the video is being emitted from the TX pin it is fun to open the serial monitor to watch what ntsc video looks like as text: almost at bit Matrixy.


No homage to 70’s and 80’s computing would be complete without keyboard beeps and disk thweeps. Keystrokes generate a 1000hz feedback beep, sd card writes make a 3600hz mechanical click. These sounds are generated in the video isr by toggling pin 6 after a certain number of HSYNCs.


WebTV IR is an unusual UART-like asych serial protocol. It runs at ~660 baud with 3.25 start bits, a 10 bit class code, 8 bit key code, parity and stop bit. Class codes are things like keyup, keydown etc. and key codes map physical keyboard layout. The video ISR counts HSYNCs between transitions on the IR data line and passes state change events to the keyboard code.

The PS2 code is pretty conventional. A good explanation is here.

Extra Credit

If you get the Philips $11.95 keyboard variant you get a PS2 IR receiver as well. The receiver can be…

  • used as-is as a PS2 keyboard connected to pins 2 and 3.
  • gutted and turned into a nice case.

I prefer the latter. The case has a nice slot in the back with a sliding door that is perfect for a microSD card. It has a nice IR window at the front and a TSOP31238 (5V center pin) IR receiver that can be harvested from the PCB. Get a cheap Pro/Mini + microsd breakout, add that iPod video cable and it looks like this:

Drop me a line at rossumur@gmail.com if you have any trouble.



p.s. The maze in minizork is not the same layout as in Zork I. I have it if you need it.

8 bit device kindles eBook fire: An e-reader for the microtouch.

With all the fuss over Kindle Fire I thought it might be fun to see if the humble 8-Bit microtouch hardware would do a servicable job as an e-reader. With a bit of fiddling it turns out to be a quite capable if not entirely practical eBook.


There are hundreds of thousands of books available in the epub format. The format is essentially a collection html/css/jpeg files and xml metadata such as author/title/table of contents bundled into a zip file (If you want to look inside an epub file simply change ‘.epub’ extension to ‘.zip’ and double click). I thought it might be possible to build a reader for the microtouch that would directly read a standard epub but the code and memory requirements for things like jpeg/png/gif decoders, xml parsers and decompression overwhelmed the available 2.5k RAM/32k Flash. The alternative was to transcode into a format that retained all the structure of the epub in a form easily digestible by a small, 8-bit device.




The transcoding tool (epubgrider) reads standard epub format files and creates ‘.epb‘ files readable by the microtouch code. The transcoder has a rudimentary layout engine that formats and paginates the html content, mapping font sizes and styles to those appropriate for viewing on a 320×240 screen. It records and stores hyperlinks within the html and resizes and transcodes images from jpg/png/gif etc to a raw 16bit RGB format. The transcoder then packages text/images/links/fonts etc with a spatial index in a ‘.epb‘ file. The spatial index allows fast scrolling through books with thousands of pages – 8500 for the largest book I found. Fonts are stored along with book so in theory books can have any typeface they like – epubgrinder can generate anti-aliased bitmap fonts from outlines. ‘.epb‘ books can be bundled into ‘.bks‘ bookshelves. Both formats are based on ‘blob’ files, a simple hierarchical data format that is suitable for 8-bit micros with microSD cards.

The net result is a little handheld device with virtually any number of books containing any number of pages. When launched the app shows a scrolling list of available books. Touching a book opens it in the reader, touching the right edge scrolls by page, touching the black bar at the bottom returns to the book list and saves your place in the book. The reader supports illustrations, hyperlinks within books for navigation and footnotes.


As always code is posted at https://github.com/rossumur/microtouch. The epubgrinder tool is based on the QT framework, contains a microtouch simulator and runs on Windows, Mac and Linux. There are a number of interesting .epb books and .bks bookshelves in the microSD folder and in the books.zip file in the tools directory.


If you don’t want to build your own microtouch, the lovely folks at adafruit will sell you a prebuilt one. 


until next time,



A Little Atari 810 Disk Drive

A tiny working model of a retro computing icon offers a blend of nostalgia and sillyness.


My first computer was an Atari 400. My first disk drive was the magnificent Atari 810. Overwhelmed by a recent wave of nostalgia from playing Zork for the first time in 30 years I have built a working model of an Atari 810 that uses 8Gig microSD cards instead of 5 1/4 inch floppies to emulate up to 8 drives. Maintaining the relative dimensions of drive to media, the model is somewhat smaller than the original.

Some numbers

The original 810 managed 90k per disk and had a volume of about 30,000 cm3. Assuming a 8Gig card the new version can store about 90,000 disks and at 5 cm3 only takes up 0.000167 times as much space. So it is a lot bigger and a lot smaller. Progress eh?

How it works

The Atari 810 (and subsequent 1050) drives are “smart” serial peripherals. The Atari OS communicates drives, printers, modems and devices using the SIO (“Serial Input/Output”) protocol. SIO devices connected to the Atari with a chunky 13 pin connector.


The Atari addresses 5 bytes commands to peripherals by lowering pin 7 (Command) and transmitting 19200 baud asynch serial on pin 5 (Data Out). If the peripheral recognises the command (‘1′,’R’,1,0 for a read from disk 1, for example) it acknowleges the command and responds with data on pin 3 (Data In) at a pokey 19200 baud by default. Pin 10 can supply 50ma of 5v.



The hardware is pretty simple: a LPC1114 microcontroller, a microSD slot, a 3v3 regulator, a led and some caps. I used the 1114 because they are cheap and I had them lying around after building the Wikipedia reader: just about any 3v3 micro with SPI and a UART would also work fine. 


The enclosure is a 3D print from Shapeways. This is the first time I have used them and I have to say I was delighted bt the experience. My inexperience in 3D modeling is evident but Shapeways sent me a lovely collection of little enclosures in various materials. I tried to make it as small as possible and still accomodate the microSD card. Testors enamel completed the look (make sure you mix in some olive with the light tan and cream).



The microcontroller code emulates up to 8 Atari drives. At power on it checks for a microSD card, mounts a Fat16 or Fat32 file system and scans the card for .ATR and .XFD disk image files commonly used with Atari emulators. It also looks for XEX files which are Atari executables, another emulator mainstay. The code then “inserts”  the BOOT.RUR image into drive 1 and waits for the Atari to start sending commands during bootup.

BOOT.RUR is a UI app written in C and compiled with cc65. Because the drive has no input or display we use this app running on the Atari to select disk images or applications. Cursor keys select the image or xex application, moving off the left or the right edge of the screen will page the list. Keys ‘1’ …’8′ will insert the selected item into drives ‘1’..’8′. The space bar will eject the disk, the return key will boot the selected image or xex. If an xex is selected, the firmware will synthesize a kboot disk image to load and execute it.

It is electrically possible to write an Atari app that can reflash the firmware but so far this is left as an exercise to the reader. The board pinout happens to be the same as a FTDI serial cable so inital firmware downloads can happen through FlashMagic.

As noted earlier, 19200 baud is pretty pokey by modern standards. Other drive and dos vendors came up with various tricks to make the serial run at 38400 or 57600 or beyond. This board supports a common 57600 baud mode so if you tire of the nostalgic thweep-thweep-thweep you can speed things up a bit by using MyPicodos or similar.

There are lots of good commercial and open source emulators and serial cables that are much more complete (and a little more practical) than this one. I am amazed at the continuing innovation on this platform: check out Yoomp and Crownland and compare them to titles released in the 80s.

3D model, PCB, schematics, NXP and Atari code on github shortly.

Until next time,



Zork for the Microtouch.

When I was a boy I burned (and listened to) much midnight oil playing Zork and many other Infocom text adventures hunched over my Atari 800. I have never forgotten profound delights of the exploring the darker regions of the Great Underground Empire: clever puzzles, lurking grues and snarking 90k disk drives.

It is hard to believe it has been 30 years since I first played Zork. To mark the occasion I have ported a Z-machine interpreter to the Microtouch


Playing Zork 1 on a microtouch in the dark. I am likely to be eaten by a grue.

The Z-machine was created in 1979 to play large (100k!) adventure games on small (8K!) personal computers. Long before the Java the implementors at Infocom built a virtual machine capable of paging, loading and saving complete runtime state that ran on a wide variety of CPUs. Pretty sophisticated stuff for microcomputers 30 years ago.

Infocom published the most enduring works of interactive fiction; if you have not played one of these beginning to end you are really missing one of the great joys of computer gaming. Since building the microtouch version I have replayed the three Zorks, Trinity and Hitchhikers Guide and can’t understand why anyone would waste their time with the crap on facebook when these gems are out there.

The brilliant sprite ran Zork on an AVR the hard way; by implementing a CP/M emulator and running the Zork CP/M binary. His approach used an external 128k of DRAM, a luxury not available on the microtouch. Also UI (touchscreens, pixels etc) has progressed a bit since the days of CP/M so I took a slightly different approach: the code is based on a cut down version of frotz, the gold standard for z-machine interpreters. I was forced to remove support for the V6 “graphic” games to fit in the 32k flash limit of the microtouch. No great loss here, the text-only adventures were Infocom’s finest.

Because the microtouch only has 2.5k of memory, all Z-machine memory is virtual, including its stack. 3 layers of caching of different granularities were required to get reasonable performance. A page file on the microSD card (“p.pge”) acts as its backing store. By default the app loads “game.z5” game but will play most non v6 games: just change their name and copy to the microSD.

The bad news is that the code is too big to fit on microtouch with the bootloader. At 32k it needs to be programmed with an ISP. I will need to abandon frotz and reimplement with more AVR friendly code to shrink it to the size of a “normal” microtouch app. The hexfile, pagefile and a game are posted here. Copy “game.z5” and “p.pge” to microSD card, burn hex file with an ISP and enjoy. Remember the app supports save, restore and scrollback. Once you get to the barrow, you can find lots of other games here.

Until next time,



Tardy update:

Finally posted source for Microtouch zork/frotz at https://github.com/rossumur/microtouch .

A 28k version with an icky fonts and a 31k with a nice font can be built with ‘make zork’ and ‘make zorkcleartype’. Enjoy.


microtouch from adafruit

Good news for those who always wanted a microtouch but didn’t have the time to build one: they are now available from the nice folks at adafruit. If you get one be sure to use the “rossum” coupon code at checkout for a 10% discount.



This version is powered by the delightful atmega32u4. It features a 320×240 pixel touchscreen, an accelerometer, full speed usb, a microsd card reader and a support for a lithium ion battery.

It has an application framework of sorts and it is possible to run a variety of applications with varying degrees of utility. Possibilites are bounded only by your imagination (and the 8 bit cpu + 2.5k of RAM). Tools support includes a PC simulator and a live sampling profiler. Code at https://github.com/rossumur/microtouch.

Building an App

Create HelloApp.cpp in apps/demos:

#include "Platform.h"

    class HelloState
        int OnEvent(Event* e)
            switch (e->Type)
                case Event::OpenApp:
            return 0;


Build, Flash and test. You should get a little app that says ‘hello’ and never quits.

Ok. What is going on here? Microtouch as an application framework of sorts that allows multiple applications to be built into the firmware. An application is ‘installed’ with the INSTALL_APP macro: the first parameter is the name that will appear in the shell, the second defines a c++ object that maintains the applications state.

The framework (Shell.cpp) sends events to the app thorugh the OnEvent method; in this example the app draws “hello” on the OpenApp event which will always be the first event an app will see. The most common events come from the touch screen: TouchDown, TouchMove and TouchUp.

Because there is only 2k of RAM in this device we really don’t have the luxury of things like memory managers. The applications state is all the heap it will ever know; its maximum size is defined by MAX_APP_BUFFER in Platform.h and is set to 768 bytes by default. If the app state is larger thanMAX_APP_BUFFER then the application won’t be visible in the ShellApp.

Lets try a slightly more complicated version:

class HelloState
        void Draw(int x, int y, int color)

        int OnEvent(Event* e)
            switch (e->Type)
                case Event::OpenApp:

                case Event::TouchDown:
                    if (e->Touch->y > 320)
                        return -1;      // Quit

                case Event::TouchMove:
            return 0;


Now we can scrawl lots of randomly colored hellos over the screen and we can even quit by touching the bottom of the screen. The Graphics.h api is fairly self explanatory: it uses 5:6:5 RGB color and supports circles, rectangles and blitting as well as text.

Stdout is connected to the USB serial port so feel free to use printf for debugging.

Sample Applications

There are a number of example applications that exercise various parts of system. They don’t all fit in the device at the same time. The APPLICATIONS path in the Makefile defines which apps get built into the firmware.


The shell is the Microtouch equivalent of the Finder or Explorer. It displays a list of installed apps and files found on the microSD card, and is responsible for lauching apps and delegating file opening to the View app. It also has code for a simple serial console:

  • ls – list files on microSD if present
  • p1/p0 – turn profiling on/off
  • lcd – dump lcd registers
  • appname – launch appname if installed


The simplest app. It turns the Microtouch off unless it is plugged into USB. The Microtouch will turn itself off after 5 minutes of inactivity so you don’t absolutely need this one, but I find it somehow comforting.


Calibrates touchscreen and stores calibration data in EEPROM. You probably will only need to run this app once if at all. Click in the red circles with a stylus until the application is satisfied with the consistency of the clicks. If you have a shattered touchscreen this app may give up after half a dozen attempts.


Displays files with inertial scrolling, currently IM2 files created with the MicrotouchTool are supported.


Exercises major hardware components including touchscreen, accelerometer, microSD and backlight.


Accelerometer demo draws XYZ values and bounces a ball depending on the orientation of the device.


Displays files with inertial scrolling, currently IM2 files created with the MicrotouchTool are supported.


The classic 3D Microtouch engine with accelerometer support. Tilt the device to move the object, touch the screen to select diffent platonic solids.


Omage to the greatest game ever written, demonstrates a technique for flicker free sprites at >60Fps.


A simple raycasting demo. Touchscreen controls speed and direction of movement. Despite the humble 8 bittyness of the CPU it manages 25fps. Play with it until you find the red wall.


Try and make all the dots the same color by touching to flip a pattern of 5. I find it bloody hard, I have only managed to complete it once. Could someone please publish a deterministic solution?


Graphics demo generates a nice infinite mesh. Looks like it is complex 3D engine with lighting, shading and geometry. It isn’t.


Click. Click. Boom.


Fingerpainting with touchscreen. Press harder for a bigger brush, select one of three brushes:

  • Cycle Chroma
  • Cycle Luminance
  • Color from accelerometer XYZ


Microtouch Tool


A simple tool to create IM2 slideshow files from jpg,png or other image files. Add as many images as you like, right click to change background, image fit or remove and image. Drag to reorder. when you are satisfied save the image to a microSD card and open from the Microtouch Shell.

Microtouch Profiler


This tool is a GUI for the built-in sampling profiler. To use:

  1. Connect Microtouch to USB
  2. Make sure the Shell is running on the Microtouch
  3. Launch MicrotouchProfiler.exe
  4. File/Open the .lss listing file that was generated when the .hex file was built
  5. Launch the target Microtouch app

The left panel displays a list of modules sorted by activity. The right panel shows the .lss file which is a mixture of source and assembly plus red bars hiliting hotspots in the code. Click on a module to move to its start in the lss file.

The built-in profiler works by sampling the PC from a timer ISR and printing it over the USB serial. If you like hexidecimal numbers you can turn the profiler on and off by typing ‘p1’ and ‘p0’ in the console.

Microtouch Simulator


A Win32 based simulator for developing Microtouch applications without the actual hardware. Simulation is pixel accurate and includes a console window that emulates usb serial stdio. The accelerometer is emulated by a series sine waves of varing period, touch pressure is selected with keys ‘1’ thru ‘9’ CPU performance is not accurately emulated.


Three OLEDs

There are a number of cheap and adorable OLED displays appearing on ebay and elsewhere. But their parallel interfaces, enigmatic driver ics and funny voltage requirements make them tricky to use. These breakout boards make it easy to connect an oled to an Arduino or any other device with a SPI interface.



All of these screens have lots of pins. Most breakout boards dutifully provide all those pins to the outside world which leads to lots of wiring up and few unused GPIO ports. Fortunately these screens can be configured to use a SPI interface saving lots of pins.

SPI has a bad rap of being slow when it comes to displays. With a bit of fiddling it is possible to get 500k pixels per second from a Arduino Duemilanove which is more than enough perf for these small screens: >30fps on 128×128.

The job of converting from 5v GPIO to 3v3 is handled by a octal buffer (74AHC244 or equivalent). They are cheap, small and a lot easier to assemble that a bunch of resistors. If you are using 3v3 IO then leave the octal buffer unstuffed and use the 3v3 holes.


OLEDs require a 12v-16v supply. Although 2 out of the 3 screens actually have ‘built in’ DC-DC converters they still need external components to generate the required voltages. These components are often fussy or inefficient and I usually just roll my own. Here I have used a FAN5331 boost converter. It isn’t expensive and because it switches at 1.6Mhz you can use a small 10uh inductor which is handy of you are cramming parts onto a small board.

The Screens

The first screen is a monochrome (actually blue) 1 bit per pixel 128×32 display based on a SSD1303 controller. These are usually $5-$8 on ebay although I have seen them in china for < $2. Because this screen is only 1bpp we can afford an actual 512 byte frame buffer on the Arduino code. Of course you don’t need to use a frame buffer if you don’t want to.

The second screen is 96×64 and has 65k colors. It is based on the SSD1332 and comes in 0.8mm and 0.7mm pin pitch versions. They are $6-$7 on ebay, < $2 in china and show up as caller id screens in lots of phones and in some small mp3 players. If you see a small color OLED with a 31 pin connector it is usually a SSD1332. This controller has hardware accelerated fills and line drawing (<1ms to fill a screen) which could save you some perf and power if you do that sort of thing.

The third screen is my absolute favorite. It is a 128×128 pixel 262k color Samsung PM12FC001B that uses a LD50T6160 controller. These show up as spares every now and then on taobao. They are found in lots of OLED digital picture frames and several Samsung YP MP3 players. The demo shows a little Wolfenstein thing running on a Arduino.

A note about the video. OLEDs don’t look very nice on video due to their use of PWM. I assure you these look much nicer in person; crisp high contrast images on all three.

Code, schematics and pcbs posted at https://sourceforge.net/projects/smartlcd/files/ (threeOleds.zip). The OLEDs and smartLCDs will converge into something a little more coherent in the near future.

Until next time,


A Smarter Display

Connecting display to Arduino can be expensive, complicated and unsatisfying. The smartlcd attempts to make it cheaper, simpler and more fun.
There are lots of interesting displays hiding in cell phones, cameras, mp3 players and various other devices. In this post we will be looking at two of my non-Nokia favorites: The iPod Nano 2G display and the so called “cheapest TFT in the world”. Then we will be making a gadget that hopefully does something useful with them.

To repurpose a display we need to determine its interface mode (serial/parallel), pinout and driver ic. If the display has a nice part number printed on the side then you might get lucky and have the interwebs answer all your questions. Much more often than not you have to do it the hard way.

Count the number of pins on the connector. If there are 8-16 pins it is almost certainly a 8 or 9 bit spi interface. Find the LED supply pins (almost always the thickest traces on the flex) and give them the respect their elevated voltages deserve. Attach a logic analyzer to a live system determine the spi clk (wiggles most), the spi mosi (wiggles second most), the spi select and the reset (wiggles once). See this example.

If you have 20 or more pins you have an 8 bit parallel interface. If you have 24 or more chances are it is 16 bit parallel. Many displays have the ability to run in both serial and parallel modes that can be selected with one or more external pins. If you are short of GPIOs this is a good option.

iPod Nano 2G
The iPod Nano 2G has a lovely little 22 pin transflective 176×132 screen. It has a 0.3mm pitch connector as seen in the iFixit tear-down. Nearly all 0.3mm ffc connectors have an odd number of pins. Apple thought different and used a DDK FF12 that is very hard to come by. After buying lots of replacement LCDs ($5 ebay + many $1 auction wins) and lots of dead/dying nano2Gs it was time bust out the fine transformer winding wire and a logic analyzer.

The data bus is easy to find: look for 8 consecutive bits that change all at the same time. The WR, CS and CD signals are then fairly easy to spot based on decreasing activity. As it turns out there are at least two different driver ics in these screens: A narrow one that looks a lot like a ILI9163 (8 bit wide commands, sets up blits with 0x2C) and wide one that looks a lot like an ILI9320 (16 bit commands, sets up blits with 0x22).

Although these controllers are similar to documented controllers they still have major differences and I needed to record an initialization sequence from a live boot in order to get them to work.

Connector pinout Nano 2G
        1        LED+ 6V
        2        LED-
        3        Frame Marker
        4        GND
        5        D7
        6        D6
        7        D5
        8        D4
        9        D3
        10        D2
        11        D1
        12        D0
        13        RD        Read
        14        WR        Write
        15        CD        Command/Data
        16        CS        Chip Select
        17        Reset
        18        GND
        19        VIO        3V3
        20        VDD        3V0
        21        ID0 
        22        ID1
Preview of an upcoming project using iPod Nano 2G screens:
The TFT 20
If one dismembers enough mp3 players one starts to notice patterns of part usage. One display caught my eye: it was very common in cheap 128×160 mp3 players, was a crisp and high contrast TFT, and had a hot bar solder connector that looked like it could be soldered by humans.

After dismembering a very nice Insignia digital photo keyframe and applying the logic analyzer the traces look very familiar. It was a ILI9163. Other devices turned up a ILI9161 and a Samsung S6D0144. All variants seem to have a very similar physical outline; another defacto standard like the touchscreen used in microtouch.They are widely available in China for $2 making them the cheapest TFT going.

So how can we make this lovely little screen useful to say an Arduino enthusiast? It needs 3v3 io on 14 pins connected to a 1mm pitch hot bar solder connector, a 6v boost converter to supply the leds, drivers, apis etc to make it useful. Not the simplest thing to do on a breadboard.
Thats where smartlcd comes in.

The smartlcd adds intelligence to a TFT 20 display. An inexpensive Arm Cortex M0 or M3 microcontroller is used to provide graphics and media processing as well as providing a high speed serial interface the 3v3 display. With additional components the smartlcd can offer a spi-flash or microSD file system and usb. One single pcb scales from bare bones serial through to a stand alone lipo battery powered device.
A minimal configuration with just the backlight boost converter and serial interface:

smartlcd uses a serial link to connect to Arduino and other devices The serial link runs a slip framed, software flow controlled RPC at 1MBit. 5v to 3v3 level conversion is not necessary; the smartlcd inputs are 5v tolerant and can plug directly into the Arduino RX and TX pins. Because it is connected to the serial interface, the smartlcd can reprogram the Arduino and under the right circumstances the Arduino can be reprogram the smartlcd. The smartlcd can also be configured to be reprogrammed via USB and you don’t have to know anything about arm or own a arm development kit to build one.

The client does not have to be a Arduino; the smartlcd can connect to virtually any serial device or USB. However smartlcd makes it very easy to display text, graph values and draw graphics quickly on Arduino:
// Console demo
        int a[2];
        a[0] = analogRead(A0);
        a[1] = analogRead(A1);
        if (_mode == 0)
                Console.Write("X:%d Y:%dn",a[0],a[1]);

        // Circle demo
        int x = random(128);
        int y = random(160);
        int r = random(70);
        int c = random(0xFFFFL);

Fully loaded versions of smartlcd can decode JPEG, PNG and will be able to decode some forms of video. Source code, schematics and Eagle files: https://sourceforge.net/projects/smartlcd/.

Until next time