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.

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.

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

Progress Report (Sort Of)

So I have not updated my blog in a while. Grad school is keeping me pretty busy. Most of what I do with electronics now is related to the local hackspace I joined. I was able to use some tools there to shorten the bolts for the case of my RPN Scientific Calculator and I also have access to a laser cutter and 3D printer that I eventually want to use to make keys for it. One of the members there and I decided to start on a project together. We have not made enough progress yet to post about but we did finish a schematic of what we plan to do. For this we have both EPROMs and EEPROMs. The EPROMs have a small window and can be erased with UV light, though the lamp we have does not seem to be working. They would also need a higher voltage source to write them and I want to make a voltage multiplier when time allows. If I can get that working, it might also help me with another project that needs -27 volts for LCD contrast.

Another neat thing I have experimented with at the hackerspace is the Spark Core. One of our members was able to get a hold of several of these for us. These tiny little boards let you connect a microcontroller to Wi-Fi pretty painlessly. This would work really well for a project idea I have that I have not started on yet. One thing I don't like is the Arduino-like environment used to program them with but I think I could get used to it since I would probably use my own microcontroller for everything but Wi-Fi. Another idea would be to simply use the CC3000 chip the board uses without the Spark Core board, though that may be too complicated to be worth it. It seems that the newer Spark Photon uses a different chip which could be easier to use by itself, though Spark Photons are not scheduled to ship until March.

One thing I have been working on on my own is a sombrero with LEDs. It was supposed to be part of a Halloween costume, but I did not finish it in time. Each color (red, green, and blue) is soldered as a 4x4 matrix that has its own shift register. It might have been possible to solder all 48 LEDS (16 each of red, green, and blue) as a 6x8 matrix and use one less shift register, but this way lets me keep each LED on three times longer. NeoPixels would have worked well for this project but just one of them costs almost as much as all of the LEDs. The board for controlling everything is finished. Now all the LEDs just need to be sewed to the sombrero and the firmware written to control their flashing. In order to save time I only soldered buttons to the board for controlling the patterns of the LEDs, but I do have some nice potentiometers I bought that I now have time to use instead. Reading their value with an MSP430 worked great on the first try and I displayed it on my one wire debug display.