Clock Modification

The unfinished clock without the arms

For Christmas 2012 I got a battery powered alarm clock. It felt pretty sturdy but only plays a beep when the alarm goes off and it does not have a backlight. There was plenty of room inside the case so I decided to add a microcontroller to play the unofficial national anthem of Kyrgyzstan Кыргыз Жери (Kyrgyz Jeri) instead of just the beep. Although I have been working on it on and off for the past few months I have not gotten the bugs worked out.

The mechanism inside the clock runs from one AA battery and has a small buzzer that looks like a piezo. The positive side of the battery is connected directly to the buzzer by a wire. The other side of the buzzer is connected to a chip under an epoxy blob that switches the buzzer on and off. The 1.5v of the AA battery is not enough to run the MSP430 I am using so I wired in two AAA batteries. The clock case has just enough room for the extra batteries and a small piece of protoboard for the microcontroller. I opened the mechanism to solder in some wires so that the microcontroller can monitor the line switching the buzzer and drive the buzzer directly instead. One of the small gears inside quickly melted from the heat given off by the soldering iron a few inches away. Luckily, all of the local clocks use a similar mechanism and I replaced the whole thing for about $1. The wires from the mechanism are connected to a switch so that the buzzer can either be run by the microcontroller or by the original clock in case the extra batteries die. Another feature the clock is missing is a light, so I wired in an RGB LED I bought a few years ago. It has a light so that it can be used as a backlight but it also flashes colors in time with the music when the alarm goes off.

At first I tried soldering components directly to a DIP socket but this was surprisingly difficult, so I added everything to a small piece of left of protoboard. The AAA batteries are too big to fit in the clock case side by side so I couldn't use a battery holder. Instead I soldered wires directly to the batteries. This will make them hard to change but hopefully the MSP430 will use very little power waiting for the alarm to go off. Once I got everything soldered, the microcontroller would play the music it should but it would not stop playing even when it was disconnected from the line switching the signal. This is a problem I still have not figured out but I'm sure it has something to do with fluctuating signals in the circuit.

There were a number of other strange problems as well. The P1IES register used to enable edge selects for interrupts on the MSP430 sometimes gives the wrong value when you read from it. It would be useful to read it in an interrupt to know which phase of the cycle the interrupt was last configured to fire for. There was also a problem working with 32-bit values. It seems that doing math with constants and assigning the result to an unsigned long does not automatically promote the constants involved to 32-bit values as well. When I got the wrong value, I tried it out on a PC and got the expected value, which was a little perplexing. It seems that constants default to the bit size of the processor, which seems silly from a portability point of view. To have the constants treated as longs, the L prefix has to be added. Another strange thing that happened was that the buzzer always made a high-pitched whining even when not being driven. The batteries for the microcontroller also drained alarmingly fast. It turns out that both of those problems are related to the buzzer being electromechanical instead of a piezo. These buzzers do not charge and stop current from flowing like a piezo. It seems they only have about 40 ohms of resistance and this is why the batteries drained so quickly.

There are still a lot of bugs to be worked out but I hope to make progress soon and finish this little project quickly.

6502 Virtual Trainer: Update

Lately I have been working on several different projects and I have made a lot of progress on the 6502 Virtual Trainer. The first step was connecting the PC interface to an MSP430 over UART. This was easy because I have done it in other projects. Microchip let me sample some MCP23S17 IO expanders and I was really excited to be able to try them out to read and write the pins of the 6502. Unfortunately, they were a little finicky to get going because the datasheet incorrectly lists the reset pin as an output instead of an input.  They do save a lot of space, though, because five shift registers would be needed to replace them. After that was solved, I was able to single-step the processor as I intended but only at about 90 cycles per second. For comparison's sake, with the processor doing nothing else, that is a little too slow to type comfortably. At the beginning I knew this would be slow but that is much slower than I expected. The bottleneck seems to be the USB<->serial layer since the program sends lots of small packets of data instead of small numbers of large packets. To speed this up, I send 10 bytes of op codes every packet. Then the MSP430 can use the data sent if it needs to read a byte that is near. It will have to request more data if a jump takes place or data is read from another location in memory but in general this improvement led to a speed up of about 150 cycles per second. This was still not as fast as I had hoped for so I decided to keep a copy of all of the memory on an SPI SRAM chip. For this I used a 23LC1024, also from Microchip, which holds 128k. Using an SPI SRAM might seem to make less sense than just hooking up a typical parallel SRAM but by letting the microcontroller control the memory I can hold extra information about the data such as which bytes have not been initialized and which should be ROM. This will let me break when reads and writes that would be illegal are performed. Even during testing this turned out to be useful as it is easy for a beginner to assembly to write something like LDX $FF instead of LDX #$FF. As a compromise the MSP430 runs the 6502 as fast as possible then pauses and updates the PC every 200ms or when 64 bytes of memory have been modified, whichever comes first. Another way to speed things up was to increase the COM port speed from the 230,400 bps max of the MSComm control I'm using with Visual Basic 6 to 1,000,000 bps. At 1,200,000 bps the MSP430 could not keep up running the 6502 and reading data. With these changes I can run the 6502 at about 12,000 cycles per second. This is still pretty slow but fast enough to play with for learning purposes. To test things I made a few programs including one that draws a faded red pattern like below: