Makevention 2015

Makevention went really well! I was able to show everything I have been working on, although I didn't have time to finish everything. I made a poster board explaining some concepts related to calculators like RPN, BCD, and CORDIC on the left side with information about my RPN Scientific Calculator on the right. I also had a print out of how my external RAM preprocessor works. A few of the people who came by my table were programmers and understood the solution.

On the table itself I had different calculators and projects laid out in roughly chronological order. The first was an MK-61 RPN calculator I added to my collection over 10 years ago. Of course I didn't make it but I wanted to show an example of an RPN calculator and what inspired me to first make calculators. When I first got the calculator out to test it, it didn't show anything on the screen and I was afraid it was broken. I took it completely apart and looked for burst capacitors. I also brushed off the battery contacts since they didn't look very clean. When I turned it on, it still didn't show anything but when I pressed a number it showed up! It seems the calculator just doesn't display anything when first turned on, instead of the zero I was expecting. Somehow I had forgotten that in the 10 years its been since I last used it.

The Casio Algebra FX 2.0 was included to show the RPN stack program I wrote for it in 2002 or so. That program was designed to make the calculator function more like the HP-48GX I had at the time which I admired so much. First, I had to buy a calculator to replace the Algebra FX 2.0+ I sold in college. Loading the program onto the calculator took quite a while to figure out! In 2002 I used a serial cable, which I think was an SB-87, to load programs without any trouble. Nowadays I don't have a serial port, so I bought an FA-124 USB cable. It turns out that this cable doesn't work on Windows 7. I also couldn't get it to work correctly under Windows XP running in an emulator. Next I tried a lot of different third-party software and finally got the program to load using FlashCOM 1.4v and an FTDI cable. For the link port I bought a 2.5mm plug that I could easily wire to the FTDI cable. After that, the program I loaded kept crashing and I thought the transfer was corrupt. After more fiddling I got Turbo C up and running in an emulator and compiled the program source myself, which produced a fairly stable program that was good enough for exhibiting, although it did crash a couple times during Makevention. Someday I would like to fix the program up and make it more stable.

The next thing I showed was a launchpad hooked up to a breadboard with a button and blinking LED to show how easy it is to get started with electronics. The next step was my binary LED calculator. I soldered a coin battery holder on to the board. After that I showed the RPN Scientific Calculator and explained that it was not too difficult to move to this stage after I managed to finish the binary LED calculator. The Programmable RPN Scientific Calculator was next. I printed temporary a colored keypad on poster paper which I taped to it, but it did not work very well. Unexpectedly, the calculator showed random keypresses when I put my hand near it. All the keys were in the same column on the keyboard, which makes me thing there is a bad connection in that row of the key matrix.

Next I showed the Improved 6502 Virtual Trainer up and running on my laptop, along with the first 6502 Virtual Trainer. I also showed what I had accomplished with the 6502 graphing calculator. So far, I have most of the hardware for it installed but I am having problems keeping the buffer chips for driving the LCD at the appropriate voltage level. Maybe the pins joining the sections of the calculator together aren't making a good connection. In any case, I showed the calculator taken apart into its sections. I also showed the Logic Tool I have been using to debug the graphing calculator and the EEPROM programmer I built. The last thing I showed was the TI-86 I bought to hook up to an ESP8266. My plan was to relay text from the calculator over WiFi to a computer running Matlab or similar software to allow the calculator to solve more complex equations. I still haven't gotten the ESP8266 voltage levels to work right, but I want to finish this project when I have time.

All in all it was a great day and I really enjoyed showing the public all the things I have been working
on.

Summer Hackathon: Conclusion

The Summer Hackathon I started on in May came to an end in August when I displayed a lot of what I had been working on at Makevention. I finished some projects and abandoned some others. Here is the outcome of the projects I set out to work on.

EEPROM Computer	Progress:	Abandoned
As I mentioned in the last update, a 4-bit version of this kind of computer has already been made by someone else. In the future I may make a 32-bit version, but for the time being I am done working on this.

8-bit Homebrew Computer	Progress:	20%
For this project, I designed a lot of the opcodes and most of how I want the computer to work. The chips I want to use don't seem to be simulated anywhere, so I will have to breadboard everything to test it out. So far I have one chip working just to test how it works.

Brainfuck Microcontroller	Progress:	55%
Apart from a few counters and status LEDs on a breadboard, I started soldering some boards with double row headers to hold everything.

Juggalo Robot	Progress:	70%
During the summer I didn't make much real progress on this project. I spent most of my time working on projects for Makevention instead.

ESP8266	Progress:	50%
I got an ESP8266 up and running. At first I had problems with the power supply but the chip seems to run alright with those problems solved. It also lists and connects to networks. Next, I need to connect to a server and transfer data, which will be used for a calculator project.

Wireless Breadboard	Progress:	Failed
This project was a failure. First of all I made a mistake with the spacing of the headers and it wouldn't fit the breadboard I was using. When I was working with it later I broke the entire header in half. The project wouldn't work anyway because the breadboard drops so much voltage. Unless I can find a breadboard that is much better, I don't intend to work on this project.

ATF1508 CPLD	Progress:	Done
After a lot of trouble and replacing a bricked chip, I eventually found a way to reliably program this chip. I also soldered a board to use for testing. This should be everything I need for the project I will use it in.

BASIC Interpreter	Progress:	30%
I also didn't make any progress on this project either. It would have been used with the Wireless Breadboard project if I had finished it. I will keep it for a later project I might need BASIC for.

LCD Programming	Progress:	50%
I got an LCD working for the 6502 Graphing Calculator project, as well as a VFD (technically not an LCD) for the Improved RPN Calculator. I did not get the LCD on the STM32F429 Discovery board working because I didn't need it for the Improved 6502 Trainer. I also haven't gotten the monochrome 5.5 inch LCD that requires -27v working yet. It will probably be easier to get a color LCD of that size instead.

Improved 6502 Trainer	Progress:	Done
I finished just about everything I wanted to for this project. It is much faster than the first 6502 Trainer. I will use it to develop for the 6502 Graphing Calculator.

Improved RPN Calculator	Progress:	95%
I finished almost everything for this project except a permanent keypad. I also renamed the project "Programmable RPN Calculator." The keystroke programming can repeat keystrokes, but it can't do any testing or branching. I will add those features eventually, but not in this version of the hardware. I shrank the size of numbers from 255 bytes down to 140. This lets me store all the temporary registers used during calculations on the chip, which makes calculations about five times faster. When I make a keypad I will be finished.

RPN Scientific Calculator on Hackaday

In August my RPN Scientific Calculator was featured on Hackaday in Hacklet 70 - Calculator Projects. It was really great to see my project on Hackaday! There was also a small scientific calculator running a 6502 emulator, a KIM-1 replica with a calculator form factor, and a project called CalcHack that adds functionality to TI graphing calculators. CalcHack is an awesome idea and one thing it adds is a 2.4GHz radio. One of my ideas for Makevention was adding an ESP8266 to the inside of a TI-86, but this solution is much better! Hackaday also created a page for calculator projects where I added my RPN Scientific Calculator, Improved RPN Scientific Calculator, and 6502 Graphing Calculator.

Progress Update

The past few months I have not had enough time to update this blog because I had so much to do in school this semester. My laptop also stopped working properly and I haven't had time to fix it, so I have not done anything with my projects. The only thing I have done related to programming is a few problems on Project Euler, which I recommend to anyone who enjoys programming. In August, a lot of things happened leading up to Makevention. Now that I have some time during the holidays, I am going to try to catch up on some posts. Hopefully I will have more time this semester to work on projects.

New Project: Logic Tool

Since my plan to make a wireless breadboard did not work out, I decided to use the MCP23S17 shift registers I bought for it to make something similar. It is similar to a logic analyzer but shows information in real time rather than recording a short period of time at high resolution. It has female headers for 64 pins but so far I have only soldered 32 of them in. As time gets closer to Makevention, I'm trying to save time however I can to get my last few projects working.

With 64 pins I will have enough to monitor all of the lines of my 6502 project. Unlike a logic analyzer, I can

also switch any of the pins to be outputs. Now I am doing this with a simple GUI I made that shows or controls the lines with virtual LEDs. This saves me from hanging loads of LEDs on all the lines of my project. Later I would like to add other forms of input and output that I can drag and drop to the dark gray area in the middle of the form. This could include buttons, sliders or hex readouts like I had for my 6502 Virtual Project. At the moment, only the LEDs work and I am using them to drive the address and data lines of the 6502 socket for my graphing calculator project. This lets me check the control signals of the CPLD fairly quickly.

In the end I think this project will work out better than the plan I had for the Wireless Breadboard. When I tried the breadboard I was going to use with another project, it showed a big voltage drop across the rails. I did not know this could happen and it would have been unfortunate to build the whole project and then find out the board was not very good.

New Project: 6502 Graphing Calculator

One of the last things I want to make progress on before Makevention in a few weeks is a graphing calculator I have been planning for quite a while. It will use a 65C02 and is the main reason I started on my 6502 Virtual Trainer last year. Most models of Texas Instrument's graphing calculators use a Z80, which was a competitor to the 6502 in the past. Those models have a 6 or 15MHz clock. The Z80 needs roughly three times more cycles than a 6502 to accomplish the same task, so running this calculator at 5MHz should be as fast as one of those calculators at 15MHz. At the maximum speed of 14MHz, it should be nearly three times as fast. Interestingly, Hewlett Packard did produce several non-graphing calculators like the HP-35S, which used a 8502 chip based on the 6502. Later models of TI calculators used the Motorola 68000 and the latest use ARM processors. These will certainly outperform anything I could make with a 6502. My hope is to make something in power between the Z80 and 68000 series with a few added features.

So far I have finished most of the decoding logic in the ATF1508 CPLD I have been working on. It has 57

IO pins and I have managed to use them all without finishing all the functionality I need. My plan is to use a 512KB SRAM chip with the first 2KB of address space always mapped to the first 2KB of the SRAM. The next two 30KB chunks of address space will point to two windows in the SRAM controlled by the CPLD. This will let me copy large chunks of data between two parts of the SRAM without changing the window between copies. Hopefully 30KB is enough for any single program the calculator will need to run. The last 2KB will be the EEPROM. This is hopefully enough space for a small bootloader that will copy firmware from an SD card and into the SRAM banks. The peripherals like the keyboard and LCD are mapped into the last few bytes of the first 2KB of SRAM.

For the LCD I found a fairly cheap 3.2 inch 320x240 color LCD on eBay. It is the perfect size for a calculator like this. It was also easy to get working with an MSP430 and some shift registers. The only downside is that I did not get an SPI version and I do not have enough CPLD pins to drive the 16 bit data port. The good news is that the LCD seems to expect 3v signals, so I will need some shift registers for level shifting anyway, which frees up a lot of pins. I don't think I will be able to finish very much more of this project for Makevention but I would like to get it drawing to the LCD from a program stored on an EEPROM by then. If I do have extra time, I will work on getting it to read a keypad.

New Project: Programmable RPN Calculator

One of the projects I started on for my Summer Hackathon is a new version of my RPN calculator. This version uses an LPC1114 instead of the two MSP430s the last version used. Hopefully this version will be much smaller and faster. Even though I'm not yet at a good stopping place I wanted to make a post about it so that the last post is not overly long.

Porting the code from the MSP430 was not too difficult. The only real trouble was moving some of the memory registers from the external RAM to the internal RAM of the LPC1114. This really increases calculation speed since it eliminates the bottleneck of accessing external memory. On the MSP430 version I used a preprocessor function to identify and replace any array access to the external RAM with functions calls. This worked well since all of the registers were stored externally but caused a few headaches on the new version since internally stored registers need to be handled differently. One idea I had was to use 32 bit pointers, which wouldn't cause the performance hit they do on a 16-bit system, to somehow encode not only the memory address, but also the memory bank and whether an address is stored externally or internally. It also seems like it would make more sense to allocate memory buffers on a stack as they are needed, rather than hardcoding them in memory. This got me thinking about how other systems handle this problem and I decided to add a way to do that to my 6502 project with a CPLD.

Along the way I also noticed a few areas where I could improve my code. For some reason I got in the habit of reusing generic counter variables like x or i in an effort to save memory. This just makes everything harder to read and does not save any memory since GCC optimizes how variables are used anyway. BCD numbers should also be stored with the smallest places first since that way extending the number by a decimal place only involves incrementing the length field rather than moving every byte of the number one space. In retrospect 255 decimal places is probably way too much for such a simple calculator. This didn't make much difference when I had lots of external RAM but is inconvenient now that I am trying to fit as many registers as I can into the LPC1114's memory.

To read and write the external RAM I'm using the chip's SPI peripheral. It turned out to be somewhat difficult to configure since several of the steps to get it to work have to be done in a certain order. Debugging this was a lot easier with a logic analyzer. After I had it working and got the memory registers straightened out, I was a little surprised to see that calculating sine was slower than on the MSP430. This was a shock since it was so much faster in my microcontroller comparison. I tried raising the SPI peripheral speed to 24MHz, even though the max speed of the RAM is 20MHz, but it was still slower. My next step is to try and measure the clock speed of the SPI with the logic analyzer to make sure it really is going that fast. After I got sine to work, I uncommented other parts of the program in parts to see how much would fit in the flash. Compiling with GCC's -O3 option for speed optimization quickly overflowed the flash but all of it fit in less than 20KB with -Os. One of my gripes with GCC is that it doesn't tell you by how much the firmware is too large, so you have no clue how much you would need to shave off for it to fit.

Initializing and toggling the pins of the LPC1114 is a bit more complicated than on the MSP430 since different pins have different configuration bits and the pins themselves are not mapped into memory in order. I had a look at the HAL library and it seems to use quite a bit of code for what I want to accomplish so I wrote a simple class for handling pins. Luckily I can use C++ since I am just compiling with GCC, unlike with OpenSTM32 where I was stuck with plain C. One neat thing someone showed me was how to use operator overloading so that something like "Pin=1;" does the same as "Pin.high();"

Since I have so much space left over in the flash, I started adding a keystroke programming function. This was one of the neat things I have always liked about earlier calculators. I am nearly done with the editor on the screen for it, which I'm working on with the PC version of the program since it is much faster to test. The next time I do a project like this I will put the PC and embedded version in the same file and enable them with include statements instead of copying the changed sections of the PC version. So far I am only adding the ability to repeat keys and not loop or branch since I want to finish this and at least one other project in time for Makevention in August. When I have more time I hope to add that functionality.

2015 Hackaday Prize

Hackaday recently started a competition for projects that feature parts made by Atmel, Freescale, Microchip, or Texas Instruments. 50 prizes are being awarded for each group, so I entered my RPN Scientific Calculator into the TI competition. The winners were announced today and my project was one of the 50. My prize was a Bluefruit LE Sniffer, which I was able to order from the Hackaday store for free. I'm not sure what I will use it for yet since I don't have a smart phone. My project page for the calculator is here.

Improved 6502 Virtual Trainer

Over the last few days I have made a lot of progress on this project. The main hurdle was getting a USB Virtual Com Port example running with the toolchain. The code from the first 6502 Virtual Trainer, which used an MSP430, was pretty easy to port to the STM32. After I got single-stepping to work, as I mentioned in my last post, I worked on the mode that stores the entire address space on the chip. It was a little surprising at first that it only ran at about 23,000hz. This is not much faster than the 14,000hz I was running at with the MSP430 version. My initial suspicion was that the transfers between the chip and PC to keep their respective copies of the address space synced were taking too much time. Timing the transfers showed that the chip usually spent over 90% of its time executing code, however. The biggest speed up came by manipulating the GPIO registers directly, rather than relying on the cumbersome HAL functions. Another thing I tried was changing the baud rate, although I couldn't find where it was initialized in the code. Eventually I found out that the Virtual Com Port doesn't rely on any sort of baud rate setting. A few other small improvements got the speed up to 350,000hz or so. When I found out how to turn on GCC optimizations in the System Workbench IDE, the speed got up to over 770,000hz. That's 0.77MHz! It's not quite the 1MHz I had hoped for but it is over 50 times faster than the first version.

My original plan was to leave the IDE unchanged so that it would be compatible with both the old
MSP430 board and the new STM32 version, but I had to change a few things. For one, I was only transferring two bytes of data to count how many clock cycles had been executed since the last update, so I had to add a third one since the new board runs so much faster. The old version synced with the IDE when at least 64 bytes of data needed to be transferred. This is the most I could store in the MSP430's internal RAM. The new limit is 200, which wastes less time syncing when lots of data is transferred. A few thousand bytes would probably be even better, but the IDE wasn't able to keep up. This could probably be fixed but 200 is fine for now.

Another thing that changed was losing support for breaking on uninitialized reads. This was a very handy feature on the first version because it could catch many different kinds of errors. That version used a 65C816 in 6502 mode and separating read cycles from internal operation cycles (when the processor is not reading despite the RWB pin being high) was easy monitoring the VPA and VDA pins. There is no easy way to do this on the 65C02 I am using now without storing information on the microcontroller about the status of the bus for every cycle of every opcode in every addressing mode. Hopefully I can live without this feature now that I have a little more experience with 6502 assembly. To test the new version I used the same small RPN graphing calculator program I wrote for the first version. It works great but drawing to the screen, even with the GDI library, is still a bit of a bottleneck.

Now that I am finished with this project I can start on programming the calculator I hope to build for the Makevention in August.

Summer Hackathon: Update

During the past few weeks I have had a lot of time to work on the projects I planned for my Summer Hackathon. So far I haven't made as much progress as I hoped, mostly because two of them took a lot more time to get going than I expected. Here is my what I have done so far on the ones I have worked on.

EEPROM Computer
Basing a computer architecture on precomputed lookup tables seemed like a an interesting idea when I started working on an assembler program for a 4-bit EEPROM-based computer. On IRC I explained what I was intending and the creator of the CADET computer showed me what he had accomplished. It is more or less the same thing I wanted to build, so I decided to stop work on this project for the time being. After discussing the idea with a friend at our hackerspace, I decided that it would only be worth continuing this project if I expanded it to a 16 or 32-bit architecture.

Brainfuck Microcontroller
For this project I have only hooked up four 74ALS193 counters since the last update. These will be the address counters for the program memory. My plan is to build the computer in small parts on a breadboard and transfer them to protoboard when I finish each piece. Rather than lay everything out on a a large board, I started soldering 8x12cm boards that will stack with double row headers. This way I will have plenty of pins to transfer signals between boards. I also plan to put LEDs on the topmost board to show signals like the address, jump buffer, op code, data pointer, and control signals.

ESP8266
A guy at our hackerspace was having trouble getting his ESP8266 going, so I set mine up to figure
out how to do it. Luckily for me, mine worked fairly well on the first try. The 03 variant I bought last year looked especially good since it is a little smaller than the others I looked at, and has several GPIOs, which I will need for one of the projects I have planned. One inconvenient thing is the 2mm pitch of the pins, which is slightly smaller than the 2.54mm, or 0.1'', pitch of a breadboard, but I soldered a small adapter. The firmware behavior is a little different than what some of the tutorials say to expect, but I was able to get a list of wireless networks at my house and connect to the WiFi at our hackerspace.
The LED of my friend's ESP8266 only lit dimly on my breadboard, as the voltage dropped down as low as 2.3v when run through the 3.3v LM1117 regulator I was running my repurposed 5v supply through. We haven't been able to figure out why this happens yet. For my chip the voltage also sank to about 3v, but it was still enough to keep the chip working. The supply itself seems to be good, as it delivers 5.18v, so I think the problem is with the regulator. When I tested the supply without the regulator on a breadboard with the 74ALS193 counters for the Brainfuck microcontroller, one side of the breadboard was down to 4.8v while the supply was still at 5.18v. Moving the jumper wires on the power rails around brought everything back to 5.18v

Wireless Breadboard
This project was especially exciting to me because it can be used to debug several of the other projects. To begin with I cut one of my 8x12cm protoboards in half and soldered single-row female headers to them, so a breadboard with male headers soldered on could be plugged into it. Unfortunately, I miscalculated the width of the breadboard and soldered the female headers on too wide apart. My local shop has been out of headers lately, so I tried to desolder the headers and broke a row of them in half in the process. So far I would consider this project a failure.

ATF1508 CPLD
This is an essential part of the 6502-based calculator I am hoping to build soon. Unfortunately, it has been my main source of headaches over the past few weeks. First of all, I tried to program the chip with an MSP430 generating JTAG signals from an svf file but this failed. After some searching, I found out that the JTAG standard is not really "standard" at all, and chips from different manufacturers handle the standard differently. Next, I tried generating a pcf file from the svf file, because it contains the actual states of every pin on every clock cycle. Although this worked and I could program the chip, the programming steps were ridiculously complicated. After using Atmel's WinCUPL program (which itself is rather unpleasant to use) to generate a JEDEC file, I convert it to an svf file with the Atmel ISP program. The problem with this is that the program offers a couple of nonsense error messages and just crashes if the FTDI cable I use to communicate with the MSP430 is still plugged in when I start the program or click the button to generate the svf file. Next, I have to switch to a virtual machine to generate the pcf file, since Atmel's SVF2PCF utility is 16-bit only.
After generating this, I have to replug my FTDI cable into USB and start a program I wrote myself to stream the PCF bytes to the MSP430. In an effort to streamline the process, I tried using Altera's SVF2PCF utility to generate the pcf file, since it is 32-bit, but unbelievably it leaves out all delay statements necessary for programming. When I tried transferring this file, the CPLD stopped responding and is now essentially bricked. For some incomprehensible reason the pins necessary for programming can be reassigned to other purposes, rendering the chip unprogrammable. At $14 apiece, this was an expensive error to make.
When my troubles with this chip started, I ordered a Byteblaster JTAG programmer, as the Atmel datasheets list this as a possibility for programming the chip. When it arrived, I quickly found out that the USB Byteblaster I had ordered has nothing at all to do with the Byteblaster cable that Atmel ISP can use. The open source driver I tried for the programmer caused my Windows 7 computer to crash with the blue sreen. Next, I ordered a USB to parallel converter cable, since the schematic for the Byteblaster is just a 74HC244 chip connected to the parallel port. So far I have not tried programming with this chip and may go back to programming with the pcf files generated by Atmel's 16-bit SVF2PCF utility.

Improved 6502 Virtual Trainer
In my post about GCC for the STM32F429 I explained how difficult it had been to get a GCC toolchain running. While I did get the toolchain to work in the end, I was unable to make any of the USB-to-serial examples work. This is very attractive for this project because I could use the chip as a Virtual Com Port and wouldn't need an FT232 chip or USB-to-serial cable. Many examples used the STM32CubeMx program from ST to generate the base code. None of the generated projects, however, can be opened with Eclipse, This is especially disappointing considering that the page for the utility lists GCC as a supported toolchain (although it is not actually in the list of toolchains in the project generator!) and provides an Eclipse plugin form of the utility. As I stated before, developing for STM32 with free tools has been a real pain! I tried the OpenSTM32 IDE, which is based on Eclipse and the libopencm3 library. This was able to compile a USB project generated by STM32CubeMx, but not without a good bit of fiddling with the files generated.
Next I soldered a small board for the 6502 that fits on the STM32 board. The pins of each port are not grouped together on the chip or on the headers on the board, but 8 of the 16 pins of port A are grouped together so I connected the 6502 data bus to them. Pins PA1 and PA2 only rose to 0.6v when driven high, which seems to be due to them being connected to some of the peripherals on the board. I connected PB1 and PB2 in those pins' place, so reading or writing the data bus means combining data from two different ports, but it does work. So far I have the chip working in single-cycle mode with the same software I made for the first trainer. My plan is to leave this software unchanged so it will work with either board.

Makevention
Our hackerspace is sponsoring a convention for makers in August and I would like to show some of my calculator projects there, so for the next two months I plan to focus mostly on the Improved 6502 Trainer and ATF1508 CPLD. These will both be necessary for the next calculator I want to build.

Summer Hackathon

Over the past year, I have not had as much time as I would have liked to devote to my electronics projects because I have been so busy with school. Hopefully I will be able to catch up this summer. My goal is to finish some projects I have already started on and start on some others I have been planning for a long time.

Here is a list of what I will be working on. Even though I probably won't have time to finish them all, these are my goals for the summer.

EEPROM Computer	Progress:	40%
As part of another project, I got interested in using an EEPROM lookup table to do four bit additions and ended up with this test setup. A 32KB EEPROM can hold 64 tables, which is enough to implement all the op codes for a full CPU. Hopefully this will greatly reduce the amount of logic involved. All that should be needed are some counters, buffers, and a multiplexer. So far I have finished most of a simulation in Atanua and started on a symbolic assembler. After I finish the assembler and have the simulation running, I will move everything to perfboard and program the op codes and source code into real EEPROMs.

8-bit Homebrew Computer	Progress:	0%
This project is something I have been thinking about for a long time. I won't say exactly how I plan to do it yet but looking on the internet I haven't found anything similar. It won't be possible to simulate this project in Atanua, so I plan to build it directly on a breadboard. The same assembler from the EEPROM Computer should be able to be changed to work for this also. I'm not sure yet whether it will be worth it to make a PC simulator for this project.

Brainfuck Micrcontroller	Progress:	50%
After I finished the simulation for this project, I did not do much more work on it. The simulated version is four bits and will have to be expanded to eight in the final hardware. The software for the project is very simple, as all it does is convert Brainfuck commands into simple op codes.

Juggalo Robot	Progress:	70%
My brother and I started work on converting a remote control car into a robot. It will have a baby doll on top with moving arms and a rotating head. He decided to paint the doll's face and make the robot juggalo themed. He got motor drivers working with an Arduino for servos in the arms and a stepper for the head. My work so far has been to reroute motor control signals on the car from the motors to a microcontroller. That way another microcontroller in the remote control can send motor control signals over the radio, which the microcontroller in the car will intercept and interpret. Then it can activate the motors, servos, or stepper according to the signal sent by the remote. The hardware is mostly finished. All that's left is the software, which should be pretty simple.

ESP8266	Progress:	0%
Last year we had a fun night doing projects with some SparkCores at our hackerspace and I decided to get a hold of an ESP8266. At $4 it was much cheaper than a SparkCore, even if it is not as easy to program. Unfortunately, I have not had time to even hook it up and try anything with it. One of my plans is to install it in a calculator for an idea I have been thinking about for a long time. One of the challenges will be getting it to connect correctly to WiFi at my university or local cafes. Another idea is to use it to program MSP430s or EEPROMs from my Chromebook, since it can't program them directly over USB.

Wireless Breadboard	Progress:	0%
This is a project I put a lot of thought into before I found out that it has already been done. My plan is to use IO expanders to control every row of a breadboard with a microcontroller. For rows that should be connected wirelessly, the microcontroller will read and relay signals to the appropriate row. This will be comparatively slow because the microcontroller will be bitbanging both the input and output of the IO expanders. Another project I saw used an FPGA, which would be much faster, but using IO expanders will hopefully be an acceptable solution, even if it is much slower. All the connections between rows will be set on the PC, which is hopefully more convenient than plugging in wires. The main advantage will be monitoring the rows and displaying data in an easy to read way on the PC. This should really speed up debugging. Also, output signals can be controlled from the PC, so programming EEPROMs or other chips should be easy.

ATF1508 CPLD	Progress:	5%
For my next 6502 project I want to use a CPLD for the address decoding. The ATF1508 is one of the few ones left in production that runs at 5 volts. It can be programmed over JTAG, so I started soldering a programmer that will use an MPS430. The chip comes in PLCC. so soldering the adapter will be a little inconvenient. My plan is to add LEDs and dip switches so I can test my designs after programming.

BASIC Interpreter	Progress:	30%
A couple of projects I would like to do eventually will need to run a BASIC interpreter. One of them is the wireless breadboard mentioned above. It would be better for new functionality, like device programming, to be done with some kind of script. That way, new scripts can be transfered to the chip at run time, instead of having to reflash the chip every time.

LCD Programming	Progress:	0%
Some of the upcoming projects will need an output of some kind. A four inch LCD should work well for the ones that a 20x4 character LCD isn't enough for. Hopefully I can get one kind of LCD going that will work for several of the projects. Another option is a 5.5 inch LCD I got a few years ago. It is much larger but requires -27 volts for contrast. This is not easy to generate, but if I can get it going, I will hopefully be able to buy several more pretty cheaply. It would work well with homebrew projects if I can get it working without a microcontroller. The STM32F429 board I have been working with also has an LCD that I would like to get going.

Improved 6502 Trainer	Progress:	20%
The 6502 Virtual Trainer was nearly finished when I stopped working on it months ago. It works really well, except that the max speed is just under 0.02 MHz. Now that I have my STM32 board running, I hope to port the code for the project from the MSP430. It ran the BCD multiply routine from the microcontroller comparison about 15 times faster, although that's probably not a good indicator of how much faster it would be for this project. There are a few changes to how UART works that might speed things up also. Another speedup will come from driving the GPIOs directly, instead of through IO expanders. Hopefully all of this together will give me the 50x speedup I need to hit 1MHz. At first I intend to make a board that will plug into the STM32 board directly and possibly use a UART cable for communication. When I figure out how to design PCBs I will make a standalone board with an STM32F429 and an FT232.

Improved RPN Calculator	Progress:	40%
For one of my friends I would like to remake my original RPN Scientific Calculator. This time I will use an LPC1114, which will allow me to copy numbers to the chip's memory before calculating. This should greatly increase calculation time because the external memory won't have to be accessed during any calculations. This will also make the firmware smaller. It should easily fit into the 32 KB the chip has, so two microcontrollers won't be necessary. Also, I would like to use a 23LC1024 SPI SRAM this time instead of parallel RAM. Altogether, the circuit should be very small.

GCC for STM32F429

About a year ago I bought a Discover kit from ST. This one has an STM32F429, which is an ARM M4 running at 168MHz with 256KB of RAM and 2MB of Flash. This seemed like the beefiest microcontroller I would need for a long time. It also has a 2.4" LCD and an external 64 Mbit SDRAM. At only $24 it seemed like a really good deal.

Last year when I had some free time, I tried to get a blinky program running for the board without much luck. The example I found had a makefile but I could not get make to work with it. For one, it could not find the rm utility to delete files. Since then I have found out that utilities like these can be installed on Windows also.

Next, I tried getting GCC working with Eclipse. For all other microcontrollers I use Code::Blocks, but the tutorials I found used Eclipse. One tutorial had no less than 25 steps to get it working, which is absolutely ridiculous if all you want to do is blink an LED. Good for the author of the blog for being so extensive but I wish ST offered an easy way to get GCC working just to get started. Another option many websites pointed to was Sourcery CodeBench. There is a free version for five different processors but the ARM version is no longer free. Next, I tried OpenSTM32. This is the Eclipse IDE prepackaged with GCC and everything needed to compile. It installed fine but when I tried to update it, the installation failed. Using the old version, I tried to generate a new project using the Standard Peripheral firmware, which for some reason is not included in OpenSTM32. The download for that also failed. Next up was Keil. It seems to work well but I do not like being limited to only 32KB of firmware. App note 230 from Keil shows how to get it working with the STM32F4 Discovery board, which is similar to the board I have. The app note shows how to use the Pack Installer in version 5.10 of the MDK software to download a blinky program or another blinky program based on an RTOS with threads. Unfortunately, the blinky program the entire app note is based on is completely missing from the packages in version 5.14 of MDK. There doesn't seem to be any way to install a simple example without the added complications of an RTOS, which is certainly overkill for blinking LEDs.

What I settled on in the end was a set of GNU ARM Eclipse Plug-ins. There is only one thing to install in Eclipse and the plug-ins generate everything from a wizard. The included blinky program is set to work with the STM32F4 Discovery board, but it compiled and ran fine after I changed the LED pin defines. To upload I used ST-LINK, which is also quirky in that it does not actually use the file you select in the Program window. Instead it uses the last file that was "loaded," so if you select a file then recompile, it will not actually use the new version. This is annoying and took a while to figure out. After I was sure I had things working right, I set Eclipse to upload with ST-LINK automatically after each compile.

To test the new setup, I ran the BCD multiply test from the microcontroller comparison. Since I'm on vacation and don't have all my other stuff, I timed it with a stopwatch and got about 24 seconds. This is five times faster than the LPC1114, which is pretty good. Next, I would like to design an improved version of the 6502 Virtual Trainer with this chip.

4x4 Full-Adder EEPROM Lookup Table

My first use for the EEPROM programmer I have been working on is a lookup table. This will be for another project I have not started on yet. Before I plan much more for that, I wanted to make sure my idea would work. This project will need to add and subtract 8 bit numbers and a lookup table is one way to do that. The 8k EEPROMs I'm using have 13 address lines which allow four pairs of bits to be added with a carry bit. When I first started I fed the carry output of each pair into the carry input of the next pair. This wasted outputs and inputs. It probably would have taken a long time for the carries to propagate also. Now, it only needs nine inputs and the remaining four could be used to select functions other than adding. The data in the EEPROM was simple to generate with a small script that calculates all possible input combinations.

RPN Scientific Calculator: Keypad

The last part of my RPN Scientific Calculator is the keypad. Before, I had considered trying to make individual key labels somehow. If I could print them on something like the material credit cards are made out of, I could cut them up and glue them to the keys. In the end, gluing on 42 labels without getting glue inside any of the buttons sounded daunting. Instead, I was able to make one out of stamp rubber on the laser cutter at our hackerspace. It turned out really well and I was able to paint the buttons different colors. At this point, there is nothing left to add, so I consider the project totally finished.

EEPROM Programmer

For a couple of projects I want to work on in the next few months I will need to use EEPROMs. Another member at our hackerspace I have been working with on the BrainFuck microcontroller gave me a few EEPROMs and UV-erasable EPROMs. Like I posted before, I was able to program some of the EEPROMs with an MSP430 on a breadboard and now I have it soldered onto protoboard.

The UART is handled by an FT232R chip that I deadbugged. It gave me a lot of problems when I first soldered 24 gauge Ethernet wire to the pins. At first I tried to tin the pins and this led to several shorts. Because the chip was superglued to the board, there was no way to get at them to fix it. Pure acetone paint remover did not take the superglue off and neither did soaking the board in fingernail polish remover for several hours. The glue got gummy but would not come off, so I left the chip where it was and soldered female headers next to it. Then I soldered another FT232R onto a small piece of protoboard with male headers so I could plug it in to replace the other chip. You can see it on the left side of the picture with the red wirewrap wire. The old chip is partly visible just underneath. The first time I tried I accidentally shorted some of the pins together when I was soldering them, so I bent them vertically to make it easier to get at them. When I bent one down to make more room, it broke off. Unfortunately this was the Vcc pin which I couldn't do without so I had to start over with a third chip. Once I got everything soldered, it worked fine.

The local electronics store did not have any USB B connectors so I had to use a dual USB A connector. The MSP430 is running off the 3.3v provided by the FT232R, so I was afraid of programming it at 3.6v with a LaunchPad since 0.3v above Vcc is the absolute maximum rating in the datasheet. That's why I have the two programming lines running through diodes on the little protoboard above the MSP430. The third "bandaid" piece of protoboard holds two transistors for level shifting. Controlling the EEPROM WE and OE lines with the MSP430 worked fine but it turns out that TTL chips can source voltage from their inputs which would damage the MSP430. The EEPROMs I have now are not TTL but I might run across one at the hackerspace and I wanted to be safe. The ZIF socket on there also came from a hackerspace member who had found some and didn't mind sharing.

The shift registers that control the data and address lines are running at 5v. The data line going to the microcontroller from the 74HC165 shift register is switched by a PN2222A. This limits SPI speed to about 400k/s. When I find a faster transistor, I should be able to read and write much quicker. The software interface is just over a plain serial terminal. In retrospect, it would have been easier to design a custom program on the PC side but it's convenient that it can work with any operating system without special software. To transfer I use XMODEM which caused some headaches at the beginning. It turns out that TeraTerm transfers the first packet twice without being asked, which caused an overflow of my UART buffer and was hard to track down since that's not expected behavior for XMODEM. It burns about 100 bytes per second but with a faster transistor I hope to write fast enough to do page writes, which will speed things up a lot.

Space Sombrero

For Halloween I decided to put some LEDs controlled by an MSP430 on a sombrero. Unfortunately, I did not finish in time to take it to the Halloween party at our hackerspace but I did finish working on it the last week.

The LEDs are soldered in three 4x4 matrixes, one matrix for each color. My plan was to combine red, green, and blue into one point diffused with ping pong balls. In the end I skipped the diffusers. The LEDs are bright enough on their own. They are taken from a string of Christmas tree lights so the total of 48 LEDs cost about a dollar. Something like NeoPixels (WS2812) would have been better for this project but would have been much more expensive.

Each color is run by its own 74HC595 shift register, so only one LED per color can be on at a time. This reduces apparent brightness when several LEDs are driven by PWM but is still brighter than using only one matrix for all the LEDs. With a 1k resistor they are very bright, which I noticed when experimenting with them before. Everything is controlled by a small PCB. Each matrix is connected to a Cat5 ethernet cable which has four twisted pairs, exactly enough to multiplex 16 LEDs. The two knobs control speed and color of the patterns and a button switches between patterns. Altogether the hardware is really simple, though there were some headaches soldering the board. The legs of the potentiometers are very weak so I soldered header pins to the back of them for stability. They are really sturdy now but Vcc was shorting through the body of the potentiometers. Once I fixed that, there still showed only about 4k resistance between ground and Vcc. A tiny fleck of solder on the metal body of the power switch was also causing a short. After fixing that there was still a 33k resistance between ground and Vcc. Desocketing and unsoldering narrowed it down to the L4931 voltage regulator. Several other L4931s I measured had the same resistance. After putting everything back together, it worked fine.

The potentiometers and knobs for them came from my local electronics store. They are logarithmic, although linear would work much better for communicating speed to the microcontroller. Converting the curve mathematically seemed pretty tricky, so I used a look up table of a few measured values instead. After soldering the potentiometers onto the board, I realized that the seven values I measured were not enough, so I plotted them on a graph and extrapolated more points. The values I came up with work pretty well, though when changing colors the distances between points don't feel exactly even. The next time I use potentiometers like this I will try to do a lot more exact measuring before soldering them so the points will be more even.

Here is a short video of a few patterns I programmed in. You can see how the speed and color knobs work. There is a lot of room left in the flash for more patterns but this is enough to consider the project finished.

Brainfuck Microcontroller

For a year or two I have been thinking about making a brainfuck computer out of 7400 series logic. Homebrew computers made out of logic chips are fairly common so my idea was to implement it as a microcontroller, with an input and output port instead of a screen or keyboard. This way I could drive LEDs, displays, shift registers, or anything else a microcontroller can. Before I made any progress on my idea, I stumbled on a neat project that is similar, The BrainFuck Machine. It uses a UART chip for input and output. Running an HD44780 or LED matrix with my project using brainfuck code should be an extra challenge.

Not long ago another member at the hackerspace I go to was talking about 7400 series logic projects and spontaneously asked me if I had ever thought about making a brainfuck computer. We had come up with the same idea independently and decided to work together. He already had quite a lot of chips including RAM and UV-erasable EPROMs to work with. His UV lamp didn't work any more so I got a replacement bulb for just a few dollars from Bulb Town. That didn't work either so I had a look inside the lamp. The ballast appeared to be sealed with some kind of gasket to the body and there doesn't seem to be any way to get inside it without breaking that. A few other chips were plain old EEPROMs that work at 5v. With some shift registers and a transistor for level shifting, it was pretty easy to program and read them with an MSP430 on a breadboard. When I finish transferring that to perfboard, I will make a post on it.

My partner and I drew up a schematic that looked reasonable and he started on a wire-wrapped board for everything. Personally, I prefer to solder boards but it will be a good chance to see how wire-wrapping works. He also knows how to make printed circuit boards with the materials at the hackerspace. Over the winter break I haven't been at home with any hardware, so I started working on a simulated version of the project with the program Atanua. It is a 7400 chip simulator that was recently released for free. A year or so ago I was really interested in using it but gave up after all of the annoying pop-ups asking to pay. In principle I would not mind paying $5-10 for something like that if it had more features that in other programs are standard:

Click to enlarge

• Cut, copy, and paste
• Selection tool
• Properties window for objects
• Rotate for objects
• Connection points for wires
• Buttons with no letters
• More 7400 chips
• SRAM chips
• Detailed screenshots

Despite the above annoyances, the simulation turned out alright in the end. To make things a little easier, I only implemented an 8 bit address space. The only RAM chip that can be simulated is a 74LS89, so the data stack is only 4 bits wide and 16 elements deep. At first I connected all the control signals for the chips to buttons so they could be manually operated. After I got that working, I started using EEPROM data to control the signals. The first version pushed the address of every [ onto a stack and jumped back to that at the corresponding ] if the current data wasn't 0. This only used a few chips and worked well but test code failed. It took me a while to realize that a loop like this that always executes at least once is equivalent to a do...while loop, not the plain while loop it is supposed to work like. The next version used a jump instruction that stores the jump address as the byte after the instruction. Getting the signal sequence right so that the jump address is not treated as an op code but is loaded into a buffer then transferred to the address buffer on the right cycle according to the data stack value was pretty tricky. Sometimes backwards jumps loaded half a cycle early, so I inserted a NOP after every forward jump. This wastes space and cycles but is acceptable for this small conceptual test. The jump sequencer could also take less cycles and some of the glue logic could be reduced, which I plan to do when we start on the full version.

In addition to the eight standard commands, it also supports # which many implementations use as a debug command to halt execution. The clock is run through a counter and XORed to produce two alternating clock signals. New EEPROM data appears on even cycles and is latched in as control signals on odd cycles so that the EEPROM output has time to settle before being latched. This probably doesn't matter in the simulation but seems like a necessary step on real hardware. Otherwise, I'm not sure how data appears on the bus and is latched in the same cycle. The control signals themselves use all 8 of the bits for convenience's sake, although they could be condensed. The data readout uses 74LS47 BCD converter chips connected to every three bits which gives an octal display.

To test the setup I wrote this short program which clears the first 6 bytes of the stack then sets the first four to 1, 2, 4, and 8 using multiplication. Then it outputs each byte in turn to the output buffer for a Larson scanner effect. The program comes to 249 bytes when run through the very simple assembler program I wrote, which is just shy of the 256 bytes available with an 8 bit address space.

[-]> [-]> [-]> [-]> [-]> [-] <<<<< + [    [       >++       >+       <<-    ]    >>    [<<+>>-]    < ] < [    .<.<.<    .>.>.> ]

Zero first six bytes Return pointer to 0 Start counter at 1 Add two for every one of counter Make a copy of counter Subtract one from counter Loop until counter==0 Point to copy of counter Copy counter back to its place New counter is next address Loop until counter overflows to 0 Set pointer to last value Output 8, 4, 2 Output 1, 2, 4 Loop forever