Home

I picked up an Amiga 500 from the local Freecycle list thanks to my wife's sharp eyes. I've fired it up and it works fine, but I decided to pull it apart to see what makes it tick and it's a great thing to look at for electronics people because the whole thing is through hole and big enough to poke at. I've gone through the chips in the video tear-down and covered a bit of the history. The camera work in the video isn't great, I need some practice so I thought some accompanying static photos that you can look at might help.

I've got an on-going project to build a battery powered device. I want to be able to run the whole thing at 3.3V so I can easily and efficiently run it off a single LiPo cell. I also want to use a simple monochrome, graphical LCD for this project, but I couldn't find one that would run off 3.3V. For various other reasons, the project requires that the LCD is a classic 8bit parallel module as I had run out of hardware serial ports and bit-banged was making the refresh seem really slow. I found a few that would run the control lines off 3.3V but still needed some higher voltage to power the screen or back-light. Eventually I bit the bullet and decided to go with one of these from Farnell because it was the cheapest back-lit 128 by 64 pixel display I could get from them. It is a really good choice as it even includes electronic contrast control, something I was expecting to have to do in external circuitry. However, it isn't a nice 0.1" pitch module, it comes out to a 0.5mm pitch FPC connection.

Since my How Not to Build a RepRap article last year, among the many other projects I've been tinkering with are several upgrades to the RepRap. I've changed the pulleys, to reduce backlash in the X/Y plane, the Z axis couplings and lead screws have been replaced to improve vertical reliability and I've built a new power supply.

Sketch update
There have been some changes to the ChipKit libraries since release, some of these changes caused the Pong sketch to stop working. After a helpful bug report from someone trying to build their own I had a look at the source to see if I could fix it. After a bit of investigation I discovered that in the old code using a digitalWrite() after an analogWrite() would leave the PWM timer running in the background. This isn't power efficient, so it's been fixed, however the new code tests to see if any analogWrite() calls on other pins have occurred and if not shuts off Timer 2. Unfortunately this means writing any of the PWM capable pins in my code shuts off Timer 2 as I don't use analogWrite() but set up PWM manually. The solution I came up with was simply to move the enable lines for the two player scores to pins 11 and 12, from 8 and 9 avoiding using any PWM capable pins. My Life demo is unaffected as I didn't use any pins for output other than the VGA pins. Updated schematics and source are included.

I've been tinkering with some simple PCB layout jobs in KiCAD over the last couple of weeks. (Hopefully they'll be worth posting here if I can get them finished!) One of these boards is probably going to be cut out on a PCB mill, so it's not going to have a solder mask or silk screen. I wanted to still have the Open Source Hardware logo, there's a big selection available at http://oshwlogo.com/ including downloadable modules for KiCAD but they're all silk screen logos, so I went about creating a copper only logo.

I've been featured on EEWeb. The site was featured last year as a "site of the day" and just before Christmas I finally got around to filling in the questionnaire I was sent. The articles are quite interesting and they've interviewed far more famous and influential people than me on there. Check it out, you might learn something!

You may have noticed in the schematics I post for various projects that I use KiCAD for all my designs. It's a free and open source package with no limitations on part count, pin count or board size. The software is cross platform, supporting Linux, Mac and Windows, and on Linux you'll probably find it in your distribution's repositories. Unlike the other big open source electronics design software gEDA it is fairly intuitive and not that different from other commerical packages I've used (OrCAD or Altium Designer). Unlike cost free versions of proprietary software like Eagle there are no reasonable limits on the board size, part count or pin count that you can create with this software and while it lacks some advanced features such as more complex curved pad shapes etc. it is very stable now and is well up to commercial work.

The Bigtrak Junior is a re-make of a classic toy apparently. I'd never seen one before, I remember school having a couple of floor turtles but I don't think I ever got to play with them (probably because I'd been messing around too much and not doing my work!). Basically the toy is a little programmable toy car that takes simple commands from a keypad with forward, back, turn left, turn right, pause etc. This is all very well but with only one memory location for storing your program between use and no editor only a "clear and start again" it's not much fun trying to get it to do things. Wouldn't it be better if it could be programmed from a web browser and you could actually use some sort of save/load program option to store your ingenious route design? The solution I've come up with could be argued to be over-engineered some what and quite expensive but I like to look at it as "expandable".

The BeagleBone comes with a basic webserver written in Javascript in the bonescript.js file. This is run by node.js which is a browser-less javascript engine. This took a bit of reading about to get my head around because the idea of javascript being used to write server side scripts was a bit odd, but the whole server seemed implausible. Unfortunately when I tried to make this do what I wanted to do for the BigTrak project, node.js wouldn't work and seems to be in some sort of version conflict but has to be maintained at this version for the Cloud9 IDE software. Instead I decided to write my own web page server in Python.

The BigTrak project had to be mobile, and that meant having a WiFi card attached. This looked simple on the face of it, a USB host socket on the board and a modern 32bit Linux kernel, however it became more complicated partly due to the lack of sources for the embedded system and partly because of my ambitions.