Friday, 7 June 2013

The Making of Ant Attack!


Someone sent me this clip and wow, what memories came flooding back.

Ant Attack on the ZX Spectrum was the first computer game that not only totally hooked me, but made me think "I wanna be able to do that". At one point, circa 1984, I could even beat the "hall of fame" high scores published in Personal Computer Games (PCG) magazine, though I was much too shy to write in about it.

One of the dubious joys of the Spectrum was getting to actually hear programs loading. Games could take upwards of 20 minutes to load from cassette tape - which meant you made damn sure you made the effort to enjoy them - and as they loaded you could hear the whistles, chirps and drones of the bits and bytes of game code.

Every game had its signature loading sound and I can still immediately recall the last few clicky seconds of Ant Attacks loading before it launched into the beepy tune that accompanied the blocky title screen.

Ant Attack was my first hacking experience. I worked out how to break into the tape loader and get access to the BASIC program that controlled the machine code routines, then I started messing with it to move things about about, such as the characters you're supposed to rescue (the positions were all coded in DATA statements in the BASIC code)

I moved on to searching through the programs memory image, looking for the data for the "city" that was the game area, then printing it out in long strips on my Alphacom 32 toilet roll printer and sellotaping them together into a map which I proudly blu-tacked to my bedroom wall.

Some 10 years later I created my own version of the game for the PC, written in C and inspired by a superb Manic Miner port. I found a cassette tape image file for Ant Attack somewhere on the early internet and tracked down and pulled out the bitmaps for the game graphics and the city map. I got the movement and display routines all working but unfortunately didn't get the game play finished off :-(

Anyway it was a joy for me to see this interview with Sandy White, the creator of Ant Attack. i had no idea what he even looked like before seeing this, and I only remember his name from the big "(C) SW" laid out in bricks on the city map in the game, which I remember noticing when I printed out the map.

I was pleased to see Sandy White HAND ASSEMBLED all the machine code for the game.. now this really does bring back memories as I used to do this myself, on a much simpler scale, armed only with the list of Z80 assembly language instructions that were printed alongside the character set at the back of the ZX Spectrum manual. Top stuff! Hey I even used to hand assemble Z80 machine code without a reference list, just by remembering all those opcodes from looking them up so many times. I really should have got out more.

Monday, 25 March 2013

ARPIE - Arduino based MIDI arpeggiator kit


Since I made my first Arduino-powered MIDI arpeggiator a couple of years back I have been meaning (and promising) to get a kit together so others can build their own. Today I listed my first "fundraiser" on Tindie. Hopefully that will raise enough cash get the PCBs made up for 50 of these little beasties!



These ARPIE kits are made up of 2 PCBs which stack up with 25mm standoffs and connect together using a 2x10 way long pin header strip, so there are no ugly wires. The top board is the control surface, packed with 29 tactile switches and 20 LEDs which together provide all the user-interface you get (or need)


I wanted to preserve the look of my original arpeggiator build, which was in a bright yellow case with black Dymo embossed tape labels. I went for a "Dymo" feel to the PCB silkscreen in this latest build. I made them up in a drawing package and imported them into EAGLE as .bmp files. Although my initial prototype PCBs are standard PCB green, I hope to go for bright yellow soldermask (boards) and black silkscreen (text) in the production run.


On the back of the control surface PCB are two 74HC595D surface mount shift registers. When I release the kit I will solder these myself, leaving just the easier through-hole stuff to be added.

The shift registers are used to scan the switches and drive the LEDs so that only 5 digital I/Os (3 ouputs and 2 inputs) are needed to drive the sixteen blue LEDs and poll the sixteen 6x3mm "Data Entry" tactile switches and the twelve 6x6mm "Menu" tactile switches. The low side of the LEDs is controlled by a 2N3904 transistor. By switching an LED on then off "early" in its refresh cycle we can get multiple brightness levels.. a kind of "poor man's PWM". The scan cycle is controlled by a timer interrupt.


Although there is no actual Arduino board used - this is an Arduino project - with Atmega328 and 16MHz crystal on board. As with most Arduino projects, all the clever stuff happens in the firmware. We send MIDI simply using the Serial port (31250 baud rate). The MIDI spec tells us to optically isolate the serial input to avoid possible grounding issues between equipment so a 6N139 opto-isolator IC sits on the MIDI input.

A feature of the ARPIE is to be able to "slave" to a MIDI SYNCH source which is different to the MIDI input where the notes are being received. For example we might have a keyboard on MIDI IN but want to get our SYNCH from a drum machine.

MIDI SYNCH is achieved through special "tick" messages which arrive at a MIDI input in real time (24 ticks for every beat) so we need a second serial interface to receive these. Since this is rather crucial for timing synchronisation, rather than "soft serial" I decided to add a second microcontroller (PIC12F1822) to manage synch. The PIC listens for the incoming MIDI synch messages and "interrupts" the Atmega328 by pulsing its INT pin each time a tick message comes in. The PIC has its own 6N139 isolator. Apart from the battery and voltage regulator stuff, that is pretty much it for the hardware.


I am quite pleased with the usability of this box - despite the minimality of the user interface it is mostly intuitive once you get used to it (OK so there are some exceptions, like the need to set the tempo in binary coded decimal :o). For most operations you press a menu button, which changes the meaning of the LEDs and data entry buttons for that function. After a period of inactivity it always goes back to "pattern" mode.

Apart from making the Arduino sketch open-source to enable hacking of the firmware, I wanted to make the hardware friendly for customisation (for example to put the device in a proper case or give it a more spacious control surface). To this end the pin header which connects the two boards can easily be replaced with a 20 way IDC socket so you can run a ribbon cable to an customised control surface. Two unused I/O lines are routed through the header for custom use. Case mounted DIN sockets can  be wired in place of the PCB mount DIN sockets supplied. Both micro-controllers have broken out programming headers (FTDI style for the AVR)

Find the Arduino sketch source code, and the hardware design files at
https://github.com/hotchk155/arpie

I am currently running ARPIE as a fundraiser on tindie.com
https://tindie.com/shops/hotchk155/arpie-midi-arpeggiator-kit-1/
Back ARPIE and get your own kit for $59

Friday, 23 November 2012

Building an Arcade Button Monome-likey




I've had quite a lot of fun with the Novation Launchpad, building interactive MIDI sequencers and control surfaces. For a while I've had the idea in mind of making an Arduinome (an Arduino powered DIY Monome MIDI controller)

When I was working with Will Nash on the Noisy Table, I really got to like the micro-switched arcade buttons that we fitted to the table to control the sounds. And so it was I hatched a plan to make a Monome style grid controller using arcade buttons. I soon found it had been done before, but it looked so cool it just encouraged me more.

I bought the switches quite a long time before I really decided exactly how I was going to use them. They have translucent white plungers with an LED holder in the microswitch clip at the base. The supplied LEDs were white and resistored up for 12V (I guess as a drop in replacement for filament bulbs in arcade machines). I decided to replace them with RGB LEDs, but I needed to make sure I had  a decent scheme for doing this, since I needed to wire up 80 of these switches and didn't want to end up making the same mistake 80 times!

12V LED modules and sockets

Microswitch heaven!

What I ended up with was breaking a matrix board into little squares, so I could thread the leds of the 5mm RGB LED through the holes and slide the board into the socket in place of the white LEDs modules. This worked nicely to connect the common anode and one of the cathodes to the LED socket. I was then faced with somehow getting a connection through to the other two cathodes while not interfering with the operation of the switch.


I have a big roll of Kynar wrapping wire that comes in very handy for this kind of thing. Kynar wire is a single core wire with a very thin insulation layer, so it easily gets  through the tiniest of holes and gaps. I could solder two wires to the remaining LED cathodes and thread them down through the socket and out between socket and switch. Since the thin single core wire can be brittle I used little blobs of superglue to anchor the ends after soldering (Its amazing how much more useful superglue becomes if you get a spray can of activator, which sets the glue off instantly - even in  blobs)


I am driving my LEDs with LPD6803 chips, which I have a big batch of from an eBay bargain. These are chainable 3-channel, constant current, self-running PWM controllers with a 2 wire serial interface. They allow 5 bits per channel of PWM resolution (Maybe the 8-bit PWM WS2801 would have been better, but I think these LPD6803's are good enough, and they are what I had)

Every single LED needs its own controller chip... thats 80 chips... how to fit them all in? I considered putting an LED driver board on every button but quickly decided that wasn't going actually to make life any easier. In the end I decided to put 8 driver ICs on a PCB and have one PCB per grid column (so 10 boards). There would be a lot of wire in there, but it seemed the most straightforward way to build it.

I've recently started getting small batches of PCBs made up by a supplier in China (ITEAD), and these driver PCBs are only the second batch I have ordered. Just getting the thing wired up to see if it worked (or if I had badly messed up my PCB design) took a long time and the suspense was killing me -  but finally I was able to connect up an Arduino to send some data to it... and it worked!!


As well as the 8 x LPD6803 chips the PCB contains a 74HC165 parallel input shift register for reading the switches. I wasn't going to count my chickens until I'd also tested the input part. Wooo, that worked too! (Eventually the input and output driver chips for all the boards will be chained together so the last test will be whether that all works)


The console for the grid is laser-cut 5mm acrylic. I had considered making a box completely out of acrylic, but wondered how sturdy it would be. Eventually I settled on building the box into a flight case and thought cases designed to house 19" rack-mount mixers would be perfect. The one I got is a Reloop case from eBay, where if cost about £75. Not the cheapest way of getting a housing, but it should be good for a few knocks.




So... looks like I have a lot of wiring to do! I am still not certain how I will drive it when its finished, but most likely I will use an Arduino.










video







Saturday, 29 September 2012

Making a POV globe





I've wanted to make a “globe POV” for a while after seeing a totally amazing hi-res one on YouTube a while back. The mechanical side of it (motor drive and power supply) always put me off a bit – while I think I can design a PCB and feel pretty confident it's going to work, motors, gears and bearings are still a matter of kludge and guesswork for me.

I decided to make a 24 LED proof of concept project using the largest size board my free version of EAGLE would let me work to. I originally intended to use 0805 SMT LEDs mounted on their sides but when I realised what a bitch they are to solder like that I decided to go with good 'ole 3mm thru holes of which I have – ahem – about 3,000 blue ones (don't ask).

The electronics was pretty straightforward – since I have made a few similar things before (basically this was an Arduino project with a custom designed PCB) The 24 LEDs are driven by 3 x 74HC595D shift registers through 100 ohm 0805 resistors. I used an Atmega328 in QPF32 package with a miniature (Nano styley) resonator.

I usually use an FTDI USB-TTL serial lead for in circuit programming, so I simply added pads for the the six ICSP connections I needed for burning the bootloader and temporarily soldered wires to them. In the past I have routed in a proper 2x3 ICSP header but I don't think I'll bother any more - after all, burning the bootloader is a one-off procedure and routing in the header is a pain.



The board is single sided FR4. After etching and drilling it I tinplated the tracks (I do this with all my boards now as it makes soldering easier, looks cooler, doesn't take long, and isn't so expensive). After adding the wire jumpers to the back I worked in stages to add the components and test things.

I think its always a good idea to test at each stage in case you need to junk the board due to a design problem. First I soldered in the Atmega and the resonator and burned the bootloader. When that worked I added the serial programming header, diagnostic LED and resistor and made sure I could get sketches to run on the Atmega. Only then did I add all the other components when was confident the brain was alive. I soldered all the components with an iron, with the exception of the resonator where I put solder and flux on the pads and used a hot air tool make the joints.

The rest of it I made up as I went along, convinced it might go wrong at any moment. I shaped the board to a disk with a stanley knife, steel rule, pliers (for snapping) and sandpaper (for smoothing). Then I added in the slots, top and bottom, to accept a 2mm drive shaft using my new diamond edge cutting disk on my Proxxon table saw (in retrospect this blade is fricking awesome and I should have used it to cut out the circular PCB... you live and learn).

Aligning the 2mm drive shafts top and bottom was pure guesswork. I both soldered them and used copious quanitites of cyanoacrylate superglue (with activator spray) to hold them in place, with the help of a couple of plastic hub wheels from a model kit supplier.

The drive shafts go through miniature model bearings in my crudely fashioned frame (made from MDF I salvaged from an old CD rack, cut with a plain old Bosch jigsaw) and at the bottom there is a simple reduction gear from a DC motor to drive it. There is a crude joinery job holding it all together - I am not proud of it,

What I am more pleased with was the electrical transfer method I used. In a previous project I
“borrowed” (saw it on a Youtube video) the idea of using an axially mounted, graphite-lubricated, 3.5mm jack plug/socket connection to take power to the rotating LED board while also acting as a bearing. This time I used some chunky graphite brushes (intended for drill equipment I think) and drilled a 2.5mm hole in each and passed the 2mm drive shafts through them, then crudely superglued the end of the brush springs to my frame. And it worked! In fact it works rather well and I think I will be using this approach again.

As I expected, some balancing was needed. I superglued a couple of nuts to the back of the board to counterbalance the LEDs on the opposite edge. Its not perfect but it was a big improvement.

I saved soldering the Hall Sensor until the board was mounted in the frame, so I could make sure I cut the legs to the right length. A small Neodymium magnet triggers the sensor.

In hindsight it might have been better to somehow mount the magnet on the front of the frame (opposite the vertical part of the frame, so 180 degrees around the axis from where it is now). The reason is that when the sensor passes the magnet, a new drawing cycle starts. So this is the point where the previous draw cycle might be ended early or overrun (depending on rounding errors due to the timer resolution and variations in spin speed). With the position of the magnet in my design these display “glitches” happen right at the front of the globe and are quite easy to see – it would be better to hide them around the back by moving the trigger point through 180 degrees, or by placing the Hall sensor on the same edge as the LEDs rather than opposite them.

There is a voltage regulator on the board and I power the motor and board from a common supply of about 10 volts. Something that surprised me was that when plugged the USB lead in to the programming header on the board, the motor received power and span up. I didn't think the current could cross the regulator in the opposite direction so it was a bit of a nasty suprise (and presumably it does the regulator no good either). A 1N4001 rectifier diode on the +10V supply going to the board brush solved the problem. I was very glad I found this issue before the motor was attached to the frame or I could have smashed the board.

When it was all fitted together I tested it out with a simple set of vertical and horizontal lines, rendering as a wireframe globe, and it looked great. Next I wanted to display a pixellated map of the world... to get this done I found a suitable Mercator projection image on Google images and resized down to the target 24 x 64 pixels in PaintShop Pro (still my drawing tool of choice for its easy work with small bitmaps). Quite a bit of manual tweaking was then needed to get a decent recognisable monochrome image.






The next step was to calculate the bitmap values to insert in the code. I needed data as 3 bytes for each vertical scan column through the image (64 x 3 bytes of data) and I needed the low bit positioned at the vertical top of each byte.

I usually use a spreadsheet to do this kind of thing (OpenOffice). I wondered how I might import the mono bitmap image data directly into the spreadsheet, but as I was in a hurry and the image was small I just retyped it manually. To help keep track I divided the image into 8x8 squares and highlighted them chessboard fashion in yellow. This meant I could work one square at a time and it only took 15 minutes or so to enter the data into the spreadsheet and use formulas to calculate the bitmap values I needed.


I copy/pasted the values from the spreadsheet into the Arduino sketch, programmed the globe and fired it up – and it worked first time! The Pacific looked a bit empty though, so I went back and added Hawaii.

I put a 32kbit I2C EEPROM on the board so that I can store a decent set of image data to make animations possible. I haven't done anything with it yet.

Here is a brief description of how the code works. Almost all the POV projects I've made work in this way...
The sketch sets up the Atmega328's internal timers 1 and 2 to run at the same rate (1/64 of full clock speed). This means they are counting at a very high rate (I think it works out as 62500 counts a second).

The sketch uses “interrupts” – an interrupt is a way for a specific hardware event (like a pin changing value or an internal timer reaching a certain threshold) to cause a specific piece of program code (called a “service routine”) to be run immediately. This means the program does not need to keep “polling” things like inputs and timers, which would not be very accurate at these timescales. Interrupts are really the only way to get the consistent timing accuracy we need.

We use two interrupts, one is called when the hall sensor fires and the value on pin 2 (Interrupt 0 pin) changes. The service routine for this interrupt captures the value of timer 1 and resets the timer. This value is the number of timer ticks in one complete rotation of the board.

Now we divide this up to get the number of timer ticks in a single “sector” (vertical scan column width). Although there are 64 columns in the image, I actually insert an artificial blank column between every pair of image columns to cleanly seperate the “pixels” rather than letting them run together into streaks (it just looks nicer) so I treat the image like it has 128 columns.

So the timer count is divided by 128 and the result is put into the timer 2 “period register”. Now when timer 2 reaches the value of the period register it is automatically reset and another interrupt fires. The service routine for this interrupt will therefore get regularly called 128 times on each revolution – perfect! Now we just need to load values from the image data into the LEDs. We need to keep a count of how far round the revolution we are and we can add an incrementing offset to make the image appear to spin. It is also here that we turn off all the LEDs on every other call to add the gaps between the pixels.

The LEDs are loaded by simple shift register stuff (Check the Arduino tutorials if you don't know what a shift register is) . Speed is of the essence, so the three shift registers are loaded in parallel using 3 data lines and common clock lines. I avoid using digitalWrite() to drive the output pins on anything like this and go direct to the port registers since it's an order of magnitude faster!

*** Source code, EAGLE files and image data available at
https://github.com/hotchk155/PovGlobe


Wednesday, 6 June 2012

Stomp box clone (Big Muff)

At the BuildBrighton hackspace we have a workshop planned for DIY stompbox builders. We'll probably be concentrating on a Fuzzface clone since thats nice and simple. Just to make sure we knew what we're doing we put together a couple of Fuzz face circuits last week, and they worked!

Inspired by this, and being a lover of the Line5 "Fuzz Pi" (Emulation of the Electro Harmonix Big Muff Pi) model for bass and guitar, I decided to try to make a Bigmuff clone of my own - complete with a proper case et al. I worked from (and fully credit) the following online schematics

I also added a bypass and  a three-state indicator LED showing "standby" (guitar connected, effect bypassed) as a dim glow and "on" as a bright glow (just with 2 different series resistances). This needs a 3PDT switch.

I was pretty pleased with the result... a nice edgey fuzz with enough bottom to work well on a bass (my main instrument)
















Friday, 6 April 2012

WeenyPOV on Scalextric car

Mikepea at BuildBrighton is building a Scalextric setup with a difference! One of the many features we're thinking about is a POV display on the roof of a car which will plot out a graphic image as the car moved round the track. The first test was to see if the concept would work (basically are the cars fast enough to get a decent POV effect?). To try this out I made a quick little POV circuit on a 1" square of flexible copper clad. There is a PIC16F688 directly driving 10 green LEDs and there is no trigger or synch on it (it just runs continuously)




For the first try we opened up a car and took our power from the +5V and GND pads of the programming header on the Digital Scalextric controller board inside the car. This seemed to power the POV board fine but the car itself would not work. Unfortunately it still didn't work when the POV was removed... oh crap! not sure exactly what happened there, but Mike was very good about it and offered another car...

Worried about frying another car, we took a different approach this time and added our own voltage regulator and smoothing caps, taking power directly from the diodes that rectify the AC being picked up from the track. We only had a big 7805 regulator to work with, but actually it looks pretty cool stuck to the hood with a couple of caps. Very 1970's hot rod.




More importantly it worked.. that is until one time the car rolled and the POV circuit on the roof seems to have got a zap directly from the 12VAC on the track and the PIC died, leaving all 10 LEDs jammed on. Insulation is obviously something to consider for the next time!

So was the concept proved? it seemed to work pretty well - especially on long exposure photos. I had it displaying some particularly peurile text, but it would probably work better with small graphical images...





Thursday, 23 February 2012

Playing with MIDI ping pong table

Will and I trying out the sensing and early version of MIDI handling on one half of the table.



Video by Will Nash. Will's site is at
http://www.willnash.co.uk