Interlock is a non-profit organization that provides space for its members and the local community to develop and share their interests in science, technology, art, and culture.

EPROMs And a failed project… for now.

One of the things that comes with working on a lot of projects is failure.  Not everything works.  I’ve had my share of projects that for one reason or another, just didn’t work out.  Tonight, I worked on one of these.

For a long time now, I’ve had some ideas that center around EPROMs.  I’ve been using EPROMS since I started getting into arcade machine collecting.  EPROMs are programmable devices where you can store bytes of memory in a fairly stable method.  They look like any other microchip, except that they have a transparent window on the top (usually quartz, even though it looks like glass).  If you look in the window, you can see the chip die in there, which I usually think looks like a tiny tennis court.

The above image shows a few different size.  The one on the right is a 2716, 16 kilobit (2 kilobyte) device.  The one in the middle is a 27C256, 256 kilobit (32 kilobyte) device.

To use an EPROM, you place it in an eraser, which is usually a ultraviolet light (often a fluorescent, non-filtered black light tube) with a timer, for about 10-12 minutes or so.  This sets all of the bits in the device to 1′s.  (0xff hex).

Then you take the chip, and plug it into a programmer.  A computer tells the programmer what zeroes to write and where, and you end up with a chip that has a program or some data stored in it, so that it can be read out later.  Often, the window is then covered up so that they are not accidentally erased over time from ambient UV light. One data sheet I read said that 1 week in direct sunlight, or 3 years in normal office lighting will erase a device.  The programmer above is my Needham’s EMP-10.  It has a 30 pin simm-looking slot on the side with 3 snap-in cards that configure the programmer pins so that it can handle a variety of different target device EPROMs.

This process has fascinated me since I started burning ROMs for use in arcade machines.  This is where this project comes in. I’ve had a few thoughts about things to explore here…

First of all, it should be possible to determine which bytes are in which physical locations on the device by casting a shadow or projecting an image onto the die from the eraser.  It should be possible to determine this by projecting different patterns on the die with the UV erasing light.  Obviously, it has to be well focused; this has to be quite precise.  A project for another day…

Secondly, I thought a fun project might be to read the pattern produced by erasing the device.  I would program all zeroes to the EPROM.  The chip would be plugged into an Arduino, to read the data out of it.  The Arduino would also control a UV LED or two which would illuminate the window on the EPROM, erasing it.  It would then alternate between illuminating the window and reading the content out of it.  The data pulled out would then be displayed as an image with pixels white if the content is a ’1′, and black if it is a ’0′.  This should show all white at the start, and all black at the end, with some amount of dithering in the middle somehow.

I have a bunch of chips pulled from various electronic gadgets over the years, and the most prevalent of them was this 2732.  It has a nice small package, small data size (4 kilobytes), so downloading the content from it should be fairly quick… and I have a whole lot of them, so if a few get destroyed in the process, it’s no big deal.

At first I considered hooking this EPROM up directly to the Arduino, but I need 24 lines to control it.  16 for address to the chip, 8 for data from the chip.  Not to mention a line to drive the LED.  I could go with an Arduino Mega, or Due, but I do not own either.  I only really needed 12 of those 16 address lines, which would bring it to 20 IO needed, which is still more than was available.

I do have a spare Mayhew Labs Mux Shield, (mine is a previous version) so I decided to just run with that.  Unfortunately this is where the story goes south.  I went from idea to making the board in one day. I really should have spent more time thinking about it, and less time being impulsive and just creating the thing.  I was too excited, incorrectly thinking that I had what I needed for the project.

I should note that I often enjoy when a project fails.  It really helps me learn what I did wrong, why it didn’t work, and then it’s like a puzzle to figure out how to make it work.  Sometimes, things just get frustrating and I will shelve a project indefinitely, but often I figure things out.

I wired up a socket, cobbled together from smaller DIP sockets, onto a piece of strip board.  I also threw a few indicator LEDs onto the board for various runtime display. After an evening of work, I came up with the board as seen here:

It was wired on the circuit side of the board (I do not recommend this) because then I could easily plug it in to the Mux Shield using the pin connectors I had.  The three red LEDs are wired to a few unused port pins on the mux, and the frosted LED on the right is an amber LED which I scuffed the top of to make it glow more than illuminate.  I have yet to power this up, because it was at this point, when I was done building it that I realized the problem.

The Mux Shield is an excellent device. I use it for my Jasper Box to read inputs.  For inputs, it’s awesome.  It’ll do 48 IO, even analog input.  For output, that’s where it gets a bit non-intuitive.

The chips used on it are unbuffered.  That is to say that there’s no way to specifically sample or store data out or in on it.  You pick a line, and then immediately read or write from it.  Think of it as a valve, not a view.  This is to say that at any one point in time, you’re only setting or reading one bit.  When reading the EPROM, I want to specify a single address (16 bits of digital output) then read in the data from the chip (8 bits of digital input).  I can only do one bit at a time, so it is impossible to set the 16 bits simultaneously.

In order for this to work, I need to add a latch of some kind to the circuit to store the 16 bit address, so that I can then read in the 8 bits of data for that address in the EPROM.

Here’s a sketch for the next version of this project.  As you can see, instead of using the Mux Shield, I’m now using a pair of 74HC595 serial-in, parallel-out shift registers chained together.  The idea here is that I would shift in the address I want to read through both of the ’595s, then latch in the data on the 74HC165 parallel-in, serial-out shift register. This is actually taking it one step too far, since the ’165 is unnecessary.  The thing on the left is the UV LED and its resistor.

So here’s a simplifed version where the data lines of the EPROM are hooked directly into the Arduino.  It also shows three indicator LEDs on the top, which will be used to show the state of the device at runtime.

I need to order some parts to build this, and once I get them, I will be posting further results on the project.

“Failure is always an option.” - Adam Savage

from BleuLlama on November 7th, 20120 Comments

Amiga 1000 Repair

Amiga 1000 computer (1985) with an Amiga 3000 “pregnant” mouse.

One of the fun things about owning retro computers is that you get to repair them yourself. (Perhaps this isn’t a fun thing for some of you, but I really enjoy it.)

About 6 years ago, my Amiga 1000 started showing some strange behaviors but only in the green levels of the video.  If you dragged the green slider, instead of it stepping up gradually from dark to bright, it would get brighter, darker, brighter, darker, much brighter, a little darker than that, and so on.

About 5 years ago, I had opened it up and replaced two ’244 latches in the video output section.  I kinda did this blindly by looking at the schematic…

…and replacing the two latches, assuming that one of them had gone bad.  After doing the repair, the problem persisted and I just gave up on it for a while.

A few days ago, a comment on the above video re-sparked interest in this project and I decided to bring the Amiga over to Interlock and really get to the bottom of the problem. I hooked it up to a scope and followed the paths according to the schematics.

Amiga 1000 apart, hooked up to a scope and a LCD monitor.

The video circuit is on the left edge of the board, just under the power cable.

I traced the lines from input on Q2 (where all of the four resistors in the D-to-A resistor ladder are joined, and back through to the latch, and then continuing back to the Denise video generation coprocessor.

The “Green” section of the video generation circuit in the Amiga 1000 with notes

from BleuLlama on October 17th, 20120 Comments

Building the BL-328 Computer: Part 1: Introduction and CPU

I recently decided to work on a physically small project. I decided to take the sort of ethics of the classic computer systems from the 1970s, which by design were considered what we now woud call “homebrew” and apply them to modern computing. I tried to keep things as stock and off-the-shelf as possible, so that this was easily reproducible by others.

To me, building a standard x86 PC from boards is not really in the same neighborhood of what I wanted to do here.  I want to do something with the feel of the Apple I for example.  Buying components, making wiring harnesses, writing firmware to control it, and having the primary user interface for it be a BASIC environment, much like the home computers of the 1970s and 1980s.

The name “BL-328″ is taken in the same way that the TRS-80 got its name (Tandy/Radio Shack Z80 based computer.) For this, I went with “BL” signifying “BleuLlama”, the nickname I use for IRC, and “328″ signifying the ATMega 328 AVR microcontroller in the form of an Arduino.

I should note that Ben Heckendorn recently did a similar project, which you can watch his project on The Ben Heck Show.

To follow along with this first step, all you will need for the first step is an Arduino board, available from Adafruit, Sparkfun, Radio Shack, homemade, etc.   The one I’m using is one I bought a few years ago from Sparkfun, the Arduino Pro.

This one has the pin header on the right side there which connects to an FTDI cable to a host computer.  I will also be using this connector to power the entire system through the use of the FTDI-USB cable, AA Battery holder, or rechargable battery pack.

To start off, I took “TinyBasic” which had been ported for use on the Arduino by Michael Field, and I have since expanded upon(github project link).  I have added SD card support with loading and saving, data pin IO, as well as graphic functions specific to this project, but I’m getting ahead of myself.

Downloading that project’s TinyBasicPlus.ino to the Arduino will give you a Basic interface with few hundred bytes of program space free.  You can use the “Serial Monitor” which is bundled with the Arduino IDE to interact with it.

The Arduino has 13 digital IO pins, some of which can be used for pseudo-analog output through the use of PWM,  as well as 6 analog Input pins, which can also be used for Digital IO.  A simple program to print out 10 results from Analog input 3, and turn on digital output 5 is as follows: (Note, that this assumes a new feature of TinyBasicPlus, “autoconfigure” is enabled)

10 REM example program

20 DWRITE 5, HIGH

30 FOR A = 0 TO 10

40 b = AREAD 3

50 PRINT B

60 NEXT A

You can write programs that will read port pins, write to port pins, and then load and save to an SD card, if you have FileIO enabled.  The SD interface I went with from this was the SeeedStudio SD Card Shield which was reasonably priced at Radio Shack.  It is hard-configured for its “select” to be on pin 10, which is shown in the TinyBasicPlus.ino file.  You will need to comment out the #undef for fileio and SD card support, and remove the comment for the related #define.  In its current state, it uses the SD library included with the Arduino package, this uses 9k bytes of program space, which is a lot.  I need to find a smaller SD library.

Now that this is enabled, the above program could be saved out to the SD card like so:

SAVE example1.bas

And then re-loaded later like so:

LOAD example1.bas

Recently, a feature was added to TinyBasicPlus that lets programs be autoloaded when you power on.  This is especially useful if you want to write your program (or programs) in BASIC on the device itself, rather than through the Arduino IDE in C.  This is accomplished by enabling the AUTORUN feature in TinyBasicPlus.ino, and by saving your startup program as “autorun.bas”.

You can go a step further and have the end of your program “CHAIN” to another program.  That is to say, you could have it load and run another program. eg:

the file “autorun.bas”:

10 PRINT "Hello"

20 CHAIN "two.bas"

the file “two.bas”:

10 PRINT "World!"

20 CHAIN "autorun.bas"

This will start up, run the “autorun.bas”, which will then load the “two.bas” program, which will chain to the “autorun.bas” program, forever.

Enough with the software though.  I’ll now get into a bit of the hardware, namely the power system.

As mentioned before, there are a few ways we can power the system.  Currently, since the only interaction you have with it is through the serial port/FTDI interface, you’ll have it powered through that, but once we bring this thing into a standalone configuration, we’ll want battery power.

The first power pack is a 4AA battery pack with a switch that I picked up from Adafruit. This has the power lines wired to a 6-pin interface like the FTDI interface has.  This lets me use standard AA batteries (rechargable or not) to power the device.

Next up is a USB-based rechargable battery I picked up at the local supermarket for $20.  It’s a rechargable (Lithium Ion, perhaps?) battery with Mini USB input for charging, then standard USB for output.  I could use the FTDI cable off of this, but instead, I decided to make a tiny adapter so that I can plug it directly in through the same 6 pin interface:

I have no idea how long either of these will power the system for.  I’m guessing a substantial number of hours.  I’ve also since made a cable that connects between the battery pack and that header, rather than that little widget pictured above, which is essentially a USB cord whose power lines are wired directly to the FTDI connector.

Using the above, you can hook up an LED to digital pin 5, and do a version of the “Blink” program included with Arduino:

the file “autorun.bas”:

10 REM Basic Blinker

20 DWRITE 5, HIGH

30 DELAY 500

40 DWRITE 5, LOW

50 DELAY 500

60 GOTO 30

Then, disconnect the FTDI cable, hook up the battery, and it should blink the LED forever.

That’s it for this time.  Soon, we’ll convert an old Commodore 64 keyboard into an input device for the computer, add LCD modules for output, and other goodies so that we’ll be able to go standalone and not need a host computer at all!

from BleuLlama on October 16th, 20120 Comments

A Computer Controllable Pixel

A few years ago, I put in an order at Sparkfun, which included 8 1-Watt Luxeon LEDs.  My original thought was that I would rebuild an lightshow device that I had built many years ago, but instead of it driving 110V spot lights through solid state relays, it would instead be more self-contained, and use high power LEDs instead.  This project never happened, since I never figured out how to power the LEDs properly.

I’ve recently been getting into doing more little projects, especially since I want to have something to do on Tuesday nights at Interlock.  I saw the box of these things on the shelf, and decided to try driving them directly from an Arduino.   I know that I could have used one of the BlinkM modules, or the strand of RGB Pixels or whatever for this, but I had these, and I wanted to see what I could do / how bright I could make them without frying the Arduino.

The project I decided to work on with them is to make a single high-brightness RGB pixel, and drive it from a Processing sketch on my computer.  Eventually, the thought might be to sample a TV’s color, 30fps for a few hours, then just store those brightness/color levels.  Then, play them back on the pixel to light a room.  From outside of the room, it should look like a television is on, showing some kind of TV show.  The way I went with testing this was to take a movie trailer, and crunch it down to a few pixels, and then average the colors in it while it plays back, live via Processing, then send the RGB values over USB-Serial to be displayed on the pixel.

I started out by soldering up a Red, Green, and Blue LED to a small piece of perf board.  I tied them together for a common ground on one side, and through a 220 ohm resistor on the other side, and all of this out to the Arduino.  I use PWM pins on the Arduino to adjust their brightness, since that’s simple to do.

The Processing sketch sends down 0..255 for red, green, and blue intensities, then those values are plugged directly into the PWM pins via AnalogWrite() calls, which displays a reasonable facsimile of the color requested.

The project worked out pretty darn well.  Without current drivers for the LEDs, I can’t make them too bright, but in an hour of sitting down at Interlock, I had this working.  I wrote up two processing sketches.  One with a RGB color wheel – click to send that color to the LEDs, and another playing the video as described above.  (Arduino and Processing sketches available upon request. )

from BleuLlama on September 26th, 20120 Comments

3D Printing a Twisty Puzzle

I’ve been getting into twisty puzzles recently.  Mainly Rubik’s cubes, as well as cubes and puzzles by other companies and designers like WitEden, Mefferts, TomZ, and so on.  While looking around, I noticed a few designers are printing one-offs via Shapeways, and other designers are offering their puzzles through Thingiverse.  I’ve been wanting to make a 1x2x3 puzzle for a while, probably making one my own from spare parts, but I happened to see a couple of 1x2x3 designs available on Thingiverse…

Very shortly after Brian, Alex, and Bill got Interlock’s 3D printer going, I nudged my way in, and got them to print out a twisty puzzle for me. The puzzle I had printed was this screwless 1x2x3 model.

I decided to go for this one becuase I wanted to have it printed out and ready to go as qucickly as possible.  In retrospect, I should have gone for TomZ’s 1x2x3 design, for reasons I’ll get to later.  Anyway… on to the printing!

The printer did a great job of producing the pieces, although it would seem that perhaps the filament was being fed into the printer too quickly, as tolerances were overshot, and much sanding needed to be performed just to get it to fit together…

This design included a “barbell” shaped piece that snapped between the two halves of the core, eliminating the need for screws and springs to hold it together and give it tension. Because of the lack of support material, the printer had a difficult time properly printing out this barbell, as you can see in the following picture.  There was nothing to hold it in place, so it got dragged around a bit as the print head moved around.

The next step I took was to sand down the parts to get them to fit. The first thing I tried was sanding the ‘feet’ that protrude from the wing pieces. I was getting decent results, but then realized that a better solution was to sand the semicircular holes in the cores a bit more, opening them up, making the feet spin in the core more easily.

Between various nights of heading to Interlock to work on this, and without the needed barbell piece, I held it together with a rubber band.

Next, Joe came to my rescue.  He extracted the barbell piece out of the STL file, sliced it in half, then printed those two halves for me.  This time using the stylish metallic gray filament, rather than the stylish orange filament.

A little bit of super glue, and a little bit of sanding, and they were ready to install inside of the twisty puzzle’s core.  Within minutes, it was assembled properly for the first time! The barbell/snap assembly is a bit loose, and I think that some of the feet were sanded down a little too much, as there is a lot of play in the fit of the parts.

I was planning on perhaps dyeing it, or just sanding more and stickering it with the expected color scheme (red, orange, green, blue, white, yellow) but Nick had asked me a little about rotational symmetry of the puzzle, and a few minutes later, he had stickered it with blue painter’s tape. It was an ingenious solution, as no two pieces are stickered with the same pattern. (Note that you can also see the floppy tolerances on the top left piece of the next photo.)

After playing with it for a while, the barbell is definitely the weak point of the whole thing.  I had sanded it a little to get it to turn more smoothly, but now it’s way too loose.  The wing pieces are a bit floppy due to sanding.   I think that these two things can easily be changed for the next print, by first using TomZ’s design which can use a screw to hold it together, and also being more cautious while sanding to keep everything within decent tolerances.

from BleuLlama on May 16th, 20120 Comments