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.

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.

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