Resurrecting an Amiga 500

 A buddy of mine is emigrating and while going through all of his stuff came across his old Amiga 500 and Commodore 64 which he very graciously has donated to me! SCORE!

I love old computing hardware, already owning an Amiga A1200, Atari, ZX80 and various other bits and pieces so these two machines were a welcome addition to the fold.

The first thing to do was obviously to boot the machines up, so I started with the A500 and was greeted with the 10-short 1-long Blink Code of Death. A little Goolge-fu revealed that this indicates various severe issues, one pointing at a leaked battery and another at a chip RAM issue.

So I did the next logical thing and opened the miggy up. What I found was that (thankfully!) the main board was clean as new but an expansion card had a battery that had leaked (the miggy boots without this card, so another win):

It seems this might be an ActionReplay of some variety. Having a closer look at the problem revelead this:

Traces looking a bit dodgy and battery acid has leaked along the traces into the chip (RAM) socket.... oh dear... so I guess its time to clean it all up, but first a closer look at the damage:

Time to whip out the iron and get to work. After a fair bit of struggle (the battery contacts were well corroded and needed to be cleaned before I could de-solder them), the board now looks like this:

Looking not too bad in fact! The traces are intact, its just the lacquer on top that has gone. A really good clean with some isopropyl alcohol and a pretty thorough test with the multimeter indicates that all is OK. Unfortunately the other battery contact point was not so good:

Bit of missing trace there, but easily repairable. So off to eBay to get another battery and to the local electronic supplier to get another socket (why is it that you always have every other chip socket but the one you need!!!).

The battery is in transit and should arrive in a week or two (the joy of living at the bottom of Africa) and the socket I'll pick up this weekend. Hopefully the actual RAM chip is okay and once I've sorted out these two issues the card will work again.

I'll update with info as it goes. Now I have to find a suitable video-out option for the A500 as B&W composite is just not doing it for me, the best looking option is a bit expensive though...

Implementing Artcfox's TLC5940 code on an Arduino, Part 3

Well its been a while... Real Life(tm) has been rather busy!
The code for this post has been gathering bit-rot on my drive so I thought it time to just put it up with a a short post (basically just a code dump) which I will follow up at a later point.

In the previous article we got the Arduino setup with appropriate clock fuse settings so that Matt's code would work. Based on this I took the sample code from CH9 and modified it to implement a small RGB pattern using some of the CH9 features, specifically the gamma correction.

CH9 is based around mulitplexing the output. I haven't used this as I don't have the transistors availabe to test it, so basically the output is still a direct drive of the attached LEDs with one colour per output pin on the TLC5940. However there is no reason that multiplexing shouldn't work. If you want to try it out, refer to Matt's original document and wire appropriately. If you apply the techniques discribed previously to the original CH9 code you should be good to go. You can use the attached code as a reference.

Hardware setup should be the same as per the first article. To see the correct visual output, wire each leg of an RGB LED to output pins 0,1,2 (R,G,B) then 3,4,5 etc. for a total of 4 LEDs. Then compile and upload the sketch and you should be good to go. The code will colour fade between each rainbow colour.

The code is available here. Go get it!

Next time I get a chance to get to the local electronics supplier I'll buy some of the appropriate transistors and wire up for the multiplexing capabilities of Matt's library and post up some wiring info and more code.

For questions etc, follow me:

or mail me at: sweetlilmre (at) gmail (dot) com

-(e)

Implementing Artcfox's TLC5940 code on an Arduino, Part 2

In my last post I detailed the basic hardware and software setup for getting Matt's TLC5940 chapter 3 code working on an Arduino. The the code doesn't do too much, but with the hardware and software working we can start to explore later chapters (where the interesting stuff happens).

At this point there is one more hardware obstacle to overcome. Matt makes use of an interesting feature of the Atmega328p called CKOUT. This is a chip level setting that can (according to the 328p datasheet) "output the system clock on the CLKO pin". Matt uses this to drive the TLC5940's GSCLK pin, a very clever way of handling the timing between the two chips.

Unfortunately the Arduino is not configured to support this by default and in order to switch on this feature, special configuration values in the 328p's flash known as "fuses" need to be be set. To do that, you need a chip level programmer.

The programmer I use is an USBtiny2 clone that I got off eBay for about 10 USD (search for "usbtiny" or "usbtinyasp" and you should get many results). Alternatively you can use a second Arduino to accomplish the same thing as per this link. Lastly, if you want to support a really fantastic company and get a great programmer with a nice case, please consider this one from Adafruit.
From this point on I will be assuming that you are using the USBtiny programmer, are on a Windows machine and are intending to program the fuses of an Arduino UNO.

At this point I am assuming that you have managed to install the drivers for your programmer. If you are using the USBtiny and are on Windows7 64-bit, this link may be helpful. If not, visit this excellent tutorial at Adafruit and get the drivers installed.


Once you have the hardware, you need to get hold of AVRDUDE. This is the software that will talk to your programmer and allow you to set the fuse bits. As of this article the latest AVRDUDE version is 5.1.1 and can be found here. If you are using an alternative programmer, please check compatibility with AVRDUDE at this page (look for the "-c programmer-id" reference).

Grab the windows archive (avrdude-5.11-Patch7610-win32.zip) and extract to a convenient location. I used "C:\temp\avrdude". Now you will need to connect your programmer to your Arduino.

Arduino ICSP port

Using the supplied 6 pin cable connect the programmer to the ICSP port on your Arduino, making sure you have:

• disconnected your Arduino from USB and any other circuitry.
• correctly identified the polarity and orientation of the programming cable and pin 1 on the ICSP port of the Arduino.

Once you have the cable correctly connected, connect the programmer to usb and the Arduino should power on.

Assuming everything is good to go: open a command prompt, change to the directory you extracted the AVRDUDE software into earlier ("c:\temp\avrdude" for me) and type:

avrdude -p m328p -c usbtiny 

See the advanced notes for additional information.

This command should print out something pretty much like this:

AVRDUDE basic output

If you get this result, add a "-v" to the command:

avrdude -p m328p -c usbtiny -v

which should spew out a whole load of text ending in something that looks like this:

Standard Arduino UNO fuse settings

What we want to do is to change the value of the lfuse from 0xFF to 0xBF to enable CKOUT.

To verify this, open this awesome AVR fuse calculator in another tab / window and check the lfuse checkbox that reads "Clock output on PORTB0; [CKOUT=0]". You should see the calculated value for lfuse change from 0xFF to 0xBF (and back when you uncheck the option).

Before we proceed any further, a word of caution:

Incorrect fuse settings can brick your Arduino!!!

If your fuse settings are not the same as the screenshot above you probably shouldn't proceed unless you are sure you know what you are doing.

Some clarification: You need to know that you have a good fuse read at this point. Your values may be different to mine but as long as they are good values you'll be okay.

Thanks to +Al McElmon who reported his hfuse value as D6 not DE. In the fuse calculator you can see that this is because EESAVE has been enabled. This could possibly be a setting on later Arduino Models?

Finally, if everything checks out and you are 100% sure of this, we are one command away from completion:

avrdude -p m328p -c usbtiny -U lfuse:w:0xBF:m -u

This command will write the value 0xBF to the lfuse and set CKOUT.
For a breakdown the "-U" command above, the command:

• selects the lfuse memory for the operation
• writes (use r for read and v for verify)
• the value 0xBF
• in immediate mode (i.e. write the value specified directly)

"-u" turns off safe mode which should enable the actual write.

And there we have it. Your Arduino should now be in a state where we can move onto the more advanced chapters of Matt's book.

Next time we are going to do exactly that, I hope you've enjoyed this post.
Until then, happy hacking!
-(e)

p.s. If you get stuck, I can attempt to help you out, circle me on G+ and send me a message via Messenger, or post a comment and I'll see what I can do.


Advanced Notes:

Perhaps you have a different model of Arduino? (e.g. ATMega168 e.t.c.):

The "-p m328p" switch for AVRDUDE specifies what chip your Arduino has. The "m328p" value is valid for the Arduino UNO and several other models, but will have to be changed for alternative models.

In this case, when using the fuse calculator please input your values for lfuse, hfuse and efuse into the fuse calculator, ensure that you have the correct AVR chip selected and note the change in the lfuse value when CKOUT is selected. The point here is that we wish to change ONLY this value. You can also confirm default board fuse settings in the "boards.txt" file located in the "hardware\arduino" directory of the Arduino IDE installation.

AVRDUDE has many other switches and supports many other programmers. I would suggest that you check out the command line in the documentation.

Implementing Artcfox's TLC5940 code on an Arduino, Part 1

In a previous post I explained how to port Matt Pandina's TLC5940 library to work with an Arduino. While that post would allow you to port the code and flash it to an Arduino I didn't go into detail on getting the code to work in an actual circuit.

+Al McElmon prompted me to get my arse into gear and so:

Over the next couple of posts I'm going to do exactly that by referring to some of the chapters and code from Matt's book and providing code and schematics that should build working examples.

This first post will focus on Chapter 3. Lets kick off with a wiring diagram:



As far as the code goes, I have used the code from Chapter3 in the zip file that can be found on Matt's site
You will need to create:

• An Arduino project file (.ino for the Arduino IDE 1.0+) with the following contents:

extern "C"
{
  #include "main.h"
}


void setup()
{
}

void loop()
{
  themain();
}

• Create the following main.h file:

#ifndef __MAIN_H
#define __MAIN_H

#define PB0 PINB0
#define PB1 PINB1
#define PB2 PINB2
#define PB3 PINB3
#define PB5 PINB5


#define PC0 PINC0
#define PC1 PINC1
#define PC2 PINC3

#define PD1 PIND1
#define PD3 PIND3
#define PD4 PIND4
#define PD5 PIND5
#define PD6 PIND6
#define PD7 PIND7

int themain(void);

#endif

• Copy the main.c from the "/code/ch3" dir in Matt's source archive.
• Edit the main.c file to add #include "main.h" after the first two includes:

#include <stdint.h>
#include <avr/io.h>
#include "main.h"

• And finally rename the function "int main(void)" to "int themain(void)"

And you should be good to go. The CH3 code doesn't do too much apart from turning a few channels on (see the gsData array for details). If you connected a single LED as per the diagram then it should light.
In a future post I will look into some more exciting code, re-programming the fuses on the Arduino to enable the clock output and other bits necessary in order to get Matt's full library working.
Until then, happy hacking!
-(e)

Zipit Z2 JTAG

So I finally managed to brick my Z2...

Trying to get the sleep / reset cycle working in u-boot (look for a subsequent post) I managed to generate some dodgy assembler and the next thing you know...

Luckily I had a nice JTAG adapter lyining around, an Olimex ARM-USB-OCD. The soldering wasn't too tricky, but here is a detailed picture to help out the weary:


The interesting part was getting OpenOCD to play along nicely. To get OpenOCD working you need some configuration scripts that identify your CPU, JTAG adapter etc.

Here is the Z2 specific script (save this as e.g. z2.cfg):

# config for ZipitZ2

jtag newtap pxa270 cpu -irlen 7 -ircapture 0x1 -irmask 0x7f -expected-id 0x49265013 -expected-id 0x79265013

target create pxa270.cpu xscale -endian little -chain-position pxa270.cpu -variant pxa27x

# maps to PXA internal RAM.
pxa270.cpu configure -work-area-phys 0x5c000000 -work-area-size 0x10000 -work-area-backup 0

#flash
flash bank pxa270.flash cfi 0x00000000 0x1000000 2 2 pxa270.cpu

And the ARM-USB-OCD configuration (save this as e.g. arm-usb-ocd.cfg):

#
# Olimex ARM-USB-OCD
#
# http://www.olimex.com/dev/arm-usb-ocd.html
#

interface ft2232
ft2232_device_desc "Olimex OpenOCD JTAG"
ft2232_layout "olimex-jtag"
ft2232_vid_pid 0x15BA 0x0003

jtag_nsrst_delay 0
jtag_ntrst_delay 200
reset_config trst_and_srst separate

What is interesting to note in the script above are the jtag_nsrst_delay and jtag_ntrst_delay values. The ARM-USB-OCD has separate lines for SRST and TSRT and the above values were required to get reset halt to work reliably in OpenOCD.

Reflashing u-boot brought the Z2 back to life and I now have a JTAG debug option. I should have done this years ago!

HTH
-(e)

edit: stupidly I forgot to thank the original JTAG legend GPSFan for his help and pictures and G1PowerMac for his site.