Austin Mueller and I started a company earlier this summer, called Tabus Nine Computing. The focus of the company right now is writing Android apps, and we’ve been working through the summer to release our first one. It’s called Modulus, and it’s a math puzzle game.

The idea of the game is that in every puzzle, you’re given a starting number, and there’s a target number. The goal is to get your number to equal the target number, and this is done using the six buttons. Each button performs a different math operations on your number. The amount that the Add button adds to your number, or how much the Divide button divides it by, is called the value of the button. The six buttons are Add, Subtract, Multiply, Divide, Modulus, and Exponent.

There are three difficulty modes: Easy, Medium, and Hard. In the Easy difficulty mode, the values of the buttons are displayed on the buttons. However, in Medium, they aren’t. So the values of the buttons are something you’ll have to figure out as you solve the puzzle. In the Hard difficulty mode, the buttons aren’t labeled at all. The positions of all the buttons are randomized, so you have to figure out which operation each button performs. To make sure you don’t have to keep all of the values and operations in your head, in the Medium and Hard difficulty modes, you can hold a button down to label it with the value or operation you think it is.

There are three game modes: Puzzle, Challenge, and Free Play. For each difficulty mode in the Puzzle and Challenge modes, there are twenty games, so 120 games total. In Puzzle mode, you just have to solve each puzzle. There are no limits on the number of moves you can make. In Challenge mode, there is a limit set on the number of moves you can make to solve each puzzle. Free Play mode generates random Medium difficulty puzzles, so you can keep playing indefinitely.

All in all, it’s a fun game. You need to think, and it stretches your mental math skills. We haven’t seen much else out there like it, so it’s a new experience, not just a new look put on an old game.

Ben Oztalay

As a quick overview of my senior project, it was to design a stack-based processor (the OZ-4) and compare its performance and architecture to that of a register-based processor (the OZ-3) that I designed about a year and a half ago. I decided to do this project because I was rather unfamiliar with stack-based architectures, and I wanted to explore them and see just how well they perform. To make these processors a reality, I implemented both of them, as well as a small system around them, to test their performance. Since I was also exploring stack-based processors, I programmed the OZ-4 to generate Mandelbrot fractals, as it did in this picture:

Since I last posted here in March, I’ve finished my senior project and presented it at my high school on one of the senior project nights, as you can see in the video above. At the end of March, I had almost finished the VHDL code for the stack-based OZ-4. It was only about a week after that that I had finished the OZ-4 without running into too much trouble, and then I started programming it to generate Mandelbrot fractals.

This was rather difficult. I had to get used to moving things around the stack and keeping them in the right places while also performing the calculations and setting up the stack for the next iteration. For the actual calculation of each iteration on a certain pixel, I changed the order in which some things are calculated so that they can be on the stack in such a way that when the iteration is all said and done, the stack is ready for the next one. At the end of it all, I had a 76-instruction loop that was the core of the Mandelbrot calculations. It rand the actual calculation, checked the various exit conditions, and moved the stack around appropriately. As I was making this program, I discovered that there was a fair amount of wasted cycles when programming a stack-based processor, and those cycles were dedicated to manipulating the stack. Those operations don’t actually do much to advance the program in the right direction, since they aren’t actually doing calculations.

I finished the Mandelbrot generator after letting the project sit around for about a month while I finished up the school year. It generates the image you see in the video in about twenty seconds, which is a bit slow compared to other Mandelbrot generators. However, I think that I could have clocked the processor faster than 25 MHz and taken that number down. At that rate, it was calculating about 15,000 pixels per second. In the end, I wasn’t really out to make the speediest Mandelbrot generator, I was just learning about how to program stack-based processors.

Now, since my project is officially a comparison of stack- and register-based processors, I compared the OZ-3 and OZ-4. The OZ-3 is a register-based, pipelined processor that I designed a couple years ago, then implemented over the year after I finished designing it. To make a fair comparison, the two processors had very similar I/O capabilities, so they could be plugged into the same system as the other. They ran at the same frequency, 25 MHz, and they had access to the same amount of memory, and had the same ALU for performing the complex fixed-point multiplication that they would need to generate Mandelbrot fractals. Here’s the system that they were in:

Unfortunately, I didn’t have time to get the OZ-3 to generate Mandelbrot fractals or use the mouse, but I compared the two processors in other ways. I broke down the results into the table below. The four programs they ran were simply counting to 100, finding all of the prime numbers from 0 to 100, calculating the first 50 numbers in the Fibonacci sequence, and calculating a math expression.

(((5 + 3)6) + 24) – ((33 – 6)2) / (7 + (2*4)) = ?

For reference, that’s the math expression I had the processors calculate. As you can see, the OZ-3, the register-based processor, performed better than the OZ-4 overall. I was surprised about this. At the start of this project, I had just assumed that stack-based processors are faster than register-based processors. This was not the case here. The assumptions came from the fact that it seemed like stacks are used a lot in modern computing, and that HP calculators, with their stacks, can usually do math faster than other calculators. Nothing solid to base my hypothesis on, and it was proven false here.

I found a few reasons for this result. First, the stack-based OZ-4 wasted quite a bit of time just moving the stack around so that it could work on the right numbers, and this is one of the main faults of stack-based processors. Register-based architectures allow access to all of the data in the register at any time, and are thus more flexible, whereas the stack denies access to all but a few pieces of information at any one time. Next, the instruction set of the OZ-4 was somewhat limiting. It wasn’t very flexible, and basic functions like branches and jumps took two to three cycles each, as opposed to one or two. I did this to keep in line with the zero-operand instruction sets of many other stack-based processors, but that certainly didn’t create an advantage.

To look at a specific example, the reason the OZ-3 ran twice as fast in counting to 100 is that the OZ-3 could run this instruction in one cycle: “addi r1, r1, 1″, which adds 1 to register 1. The OZ-4, though, had to use one instruction to push 1 onto the stack, then another to add it to the counter. Another one to look at is evaluating the math expression. I thought the OZ-4 would cream the OZ-3 in this test, but they were exactly equal. The stack-based architecture can easily and intuitively evaluate that expression from the inside out, keeping sub-results on the stack until they need to be combined into the full result. But, because of the flexibility of register-based architectures, I was actually able to program the OZ-3 to use its registers as a sort of  pseudo-stack, and it could keep the same performance as the OZ-4.

However, just looking at their performance doesn’t provide a full comparison. The OZ-4 may be slower in software, but its hardware is significantly smaller and simpler than the OZ-3, and this would, in theory, let it run at a higher frequency than the OZ-3. I didn’t test this specifically, but it is one advantage the OZ-4 has. This also made it easier to design the OZ-4. The second big advantage the OZ-4 has over the OZ-3 is program size. The OZ-3′s instructions are a full 32 bits long because they need an opcode and three fields to specify the source and destination registers. In other addressing modes, the space is taken up by immediate values. The OZ-4′s instructions, though, are only twelve bits long, and could even be six bits long 99% of the time. The first six bits are the opcode, and the last six bits are for specifying which immediate value is to be used in the event of a PUSH instruction. The instructions are shorter because the operands are implicitly on the stack, and don’t need to be encoded into the instruction.

Finally, here are the block diagrams for both processors:

The OZ-4′s:

The OZ-3′s:

Ben Oztalay

I took this project on as a present for my girlfriend, who, during the colder months, is more or less addicted to coffee/hot chocolate/tea. Her mug broke, and I was just going to get a new one for her birthday, but I wanted to add a little functionality to it. The new mug now senses and displays the relative temperature of its contents on a 10-LED blue bar display and has a rechargeable battery, which is charged through a 5.0V DC jack. Turned out pretty well, although it reacts a tad slow to temperature changes, as you can see in the video.

Click here to read the rest

I took another crack at making my own circuit boards, and with much better results. The first thing I did was change the design to be better suited for toner transfer. The traces before were 0.010″ wide, so I bumped them up to 0.016″. Doing that makes the breaking of traces less likely when transferring the toner. I also put more copper around the pads for the five jumpers,  so the copper I accidentally remove during drilling doesn’t make too much of a difference.

So, to start the process, I printed the design onto some magazine paper. I’ve read that some other papers work well, but magazine paper is pretty much free (this is a page out of a Jameco catalog they sent me), and it works pretty well.

Next up, I cut the blank circuit board and cleaned it up with some 600 grain sandpaper.

While ironing the design onto the board, I found that it’s rather easy to over-iron the plastic toner from the ink. The first time around, I cooked the plastic, so it was bubbly and ran everywhere. It only takes about 45 seconds on mediumish temperature to get the toner to transfer well. To make sure that the paper didn’t slide around while I ironed, I left a lot of excess paper around the design to tape to the table over the circuit board.

After ironing and soaking the paper to get it to peel off, I found that I actually got a great transfer on these boards. You’ll see that some of the ink that was on the page originally also transferred, which turned out to only be significant for one board. However, this happened in an area that didn’t affect the circuit, so I just scraped the copper off with a razor blade after etching the boards.

To etch the boards, I opted to not use the more common ferric chloride etchant in favor of something that’s a little easier to get a hold of and dispose of. It’s a 2:1 mixture of hydrogen peroxide from the drug store and muriatic acid, also known as hydrochloric acid. To get the boards to etch in a reasonable amount of time, the solution needs to be agitated. It only took about 10 minutes for these boards to finish. The picture on the left is when they were closer to done, with most of the copper gone. I started them face down in order to give all of the copper on the bottom side of the board enough time to dissolve, as well.

Before removing the toner, I drilled out the holes for the through-hole components on this board. I drilled before exposing the copper because the black toner is more visible against the bare circuit board, which makes drilling easier. I used my Dremel drill press with a 1/32″ bit for the smaller holes, and a 1/16″ bit for the larger ones.

Finally, all I had to do was take the toner off with some nail polish remover to expose the traces.

Soldering the capacitors was easy enough, as they’re just through-hole components. The MAX1555, a surface-mount component, was a little more difficult, but I had a little bit of experience with them. First, I got some solder on the top two pads. Then I positioned the IC over the pads, held it down, and melted the solder beneath the pads to secure the component in place. The last three pins were just a matter of heating while getting some solder melting.

Soldering the jumpers on was interesting, because the holes were too big. Getting the board and the jumpers to be at a right angle took a little bit of luck and experimentation, but the boards were done!

The last step was to number and date them. I tested these boards out on a breadboard with a Li-Poly battery from SparkFun, and it worked! Unfortunately, I can’t go into details with it because it’s for a project that’s a present. I’ll be making a post about that present after it’s been given.

Oh, and, uh, I learned all about the importance of using a good soldering iron and solder. I tried populating the board in the last post, without much luck. The iron I was using was too cold, and the solder was abysmal; it didn’t flow at all. This was the sad result of using my secondary tools.

Ben Oztalay

I made my first circuit board yesterday, and it was a lot of fun. I used the toner-transfer method, with an etching solution made out of hydrochloric acid and hydrogen peroxide. I more or less followed this guide, although I read at least a dozen on different methods. Unfortunately, I forgot to bring my camera to the workshop, so I only have a picture of the finished product, not the process.

The board itself is a breakout board I designed for the MAX1555, which is a very handy chip that handles the charging of single-cell Li-Poly batteries. It’s a small SMT component that goes in the upper right, and next to it are holes for 100nF capacitors to filter the power supplies. The bottom row of holes are connected to the MAX1555′s pins, and are spaced to take 0.1″ headers, making it breadboard-friendly.

Making my own circuit boards will be nice, because getting them fabricated is expensive, and it takes about a month to get them back. This board took me an hour to make, and probably cost half as much. While it’s lower quality, it serves my purposes just fine.

In the future, to make it easier on myself, I think I’m going to change the design rules for boards that I make. The traces on this board are 8 mil, and I think that bumping it up to somewhere closer to 15 mil would reduce the chance of broken traces. I also need more copper around the through-hold pads, because centering the drill with such a small margin of error is difficult to do by hand.

Ben Oztalay

So, I came across this simple, yet cool project and decided to make a couple of these guys as a smaller present for my girlfriend’s birthday. It was a bit challenging to get all of the soldering to work out, and I’m sure almost all of the joints were made cold. I modified the design a little to use the capacitor as a leg, since in the original ones, the ground wire is a leg and the capacitor is on the board. I took out the ground wire, since one of the capacitor’s leads goes to ground, which became the new ground wire. So now they’re more free-standing, and able to dance.

Read more…

As my Christmas present to my girlfriend, Cat, as well as an introduction to microcontrollers, I made a cube that glows different colors as it’s tilted different ways. I works by having a PIC12F615 take readings from a 3-axis accelerometer, then turning those readings into colors for each component of a few RGB LEDs, which are controlled with pulse width modulation.

Read more…

Read more…

After contacting Digilent, I learned that returns for manufacturing defects have to be within 30 days of purchase. Considering I got the board about a year and a half ago, I’d have to either get a new board, or try to repair this one. I got the part number from them and ordered plenty of spares, as I had never soldered an SMT component by hand before. I just spent about half an hour figuring out how. I learned first that getting the transistor to stay in place is quite a challenge, and that a slightly magnetic X-ACTO knife makes for getting it in the right place to start with difficult. Desoldering the burnt transistor also made for a grand ‘ol time.

To solder the transistor, I cleaned off the pads and the area around it, which was a bit of a mess because of the other transistor. Then I got some solder on all of the pads, which caused them all to bump up and constantly shift the position of the transistor. After it had been pinned down in place by end of a wire, I tried to secure just one contact. Not trusting that I hadn’t overheated the transistor after ten minutes of trying to solder, shifting, placing, and soldering again, I kept throwing out transistors and getting new ones. By the fifth transistor, I was confident that I didn’t damage the component. The other two pads were easy to solder down because the other was holding the transistor in place.

Here’s my handywork:

The moment of truth: I plugged the board in, the power light came on, and a configuration worked. Woo! I avoided having to buy a whole new board, and got a little experience with SMT soldering.

Ben Oztalay

A couple summers ago, I designed a 32-bit processor at the gate level in a digital logic simulator called Logisim. It’s a reduced instruction set computer, implementing 32 instructions that are decoded and executed in a 5-stage pipeline. Those stages would be: Instruction Fetch (IF), Instruction Decode (ID), Execute (EX), Memory and I/O (MEMIO), and Writeback (WB).

The ALU supports most common operations, such as shifts, rotates, addition, subtraction, and logic functions, and operates only with two’s-complement numbers. Technically, it deals with all numbers, it just interprets them as two’s-complement. To save on cycles, each stage of the processor can forward the results of an instruction back to the instruction decoder, so that the current instruction doesn’t have to wait for the previous instruction’s result to get to the writeback stage before it can be used. There are 32 32-bit registers organized as a register file, with register 0 wired to zero. The register file is inside the Instruction Decode stage of the pipeline so that the stage can easily read and write registers, as well as handle forwarding easily by using forwarded values instead of values that are in the registers.

I designed the instruction set architecture and created the instructions, producing my own opcodes and addressing modes. My main focus was reducing the amount of gate logic necessary to decode instructions, so the instructions and their opcodes are organized in a funny way to reach that goal. Also, all of the instructions are fetched in one cycle, so there are no instructions that would involve grabbing an immediate value or other data in the address following the instruction. I leaned toward simplicity most of the time because I was designing the processor at the gate level, so some functionality is limited, but I think I still retained a fair amount of flexibility in the design. For example, I lost some flexibility because I chose to separate the data and instruction storage, but that kept fetching instructions and making memory transactions simpler.

Input and output capabilities are 16 input pins, 16 output pins, a 32-bit input port, and a 32-bit output port. Extra components, like a multiplexer and a few registers, have to be used to expand the port I/O.

A block diagram of the inside of the processor shows how it’s organized:

One of the biggest challenges was to fit the OZ-3 in a system that included the peripherals on the development board I used, which was Digilent’s Nexys-2 board, which has a Xilinx Spartan-3E with 500,000 equivalent gates. The system, in the end, used the on-board RAM and Flash memory, to store data and instructions, respectively. The buttons, switches, and PS/2 port are open for input, while all of the PMOD connectors and the 7-segment display are used for output. The PMOD connectors are used mainly for the 2×16 character LCD screen, but a fair amount of other devices can be attached.

Using the memory resources (the RAM and Flash) was probably the most difficult roadblock to overcome when I was writing the VHDL. The main issue was that the RAM and Flash share address and data buses, so only one can be used at a time. However, instructions need to be fetched every cycle, and memory transactions would have to happen at the same time. Modifying the processor to accommodate this could get messy, so instead I created a memory controller that would alternate control of the buses between the RAM and the Flash. This cut how fast the processor could run in half, but those were just limitations of the system I was working in. The memory controller runs twice as fast as the processor to flip and flop between the memories in time.

The second issue was that the RAM and Flash are only sixteen bits wide. As it so happens, the OZ-3 has 32-bit instructions. I modified the fetch stage to run twice as fast as the rest of the processor to get in both halves of the instruction in time, but that actually meant that I would have to cut how fast the rest of the processor ran in half, as the Flash was already being run as fast as it can. I also had to change the way memory transactions are handled by adding instructions that write the upper or lower half of a 32-bit value into memory, and instructions that read an address in memory into the upper or lower half of a register.

Once complete, the system looked like this:

In terms of the software I developed for it, the most complex program I wrote was one that keeps a 1024-character buffer in memory of text that the user inputs through a keyboard. The LCD screen then displays two 16-character lines of the buffer. Using the number pad, the user can scroll up and down through the buffer, and left and right within a line. It’s fairly simple, but it took quite a while to write in assembly.

To develop software such as this, I wrote an assembler in C++. This was also my first experience in parsing something as complex as code that has labels, white space, and comments. Labels are just a way to mark a place in the program that can later be referred to, as a way of jumping back to a certain instruction. The assembler ignores all white space, so I was able to indent the code to make it more readable. Here’s a sample piece of code:

lbl MAIN_LOOP
      #Reset the display update only flag
      addi r10, r0, 0

      cpi r7, 1
      brne CURSOR_LINE_2
      noop
      noop
      noop    

      #Set the cursor address if it's on line 1
      opin0 9
      opin1 8
      addi r8, r2, 127
      oprt r8
      opin0 8
      jp SKIP_LINE_2
      noop
      noop
      noop

      #Set the cursor address if it's on line 2
      lbl CURSOR_LINE_2
           opin0 9
           opin1 8
           addi r8, r2, 191
           oprt r8
           opin0 8

So, this is a good example of indenting, labels, and comments. There aren’t any in-line comments because they don’t appeal to me usually, but they would be valid if I were to use them. To create a loop, all that would need to be added to, say, the indented code under the “CURSOR_LINE_2″ label is “jp CURSOR_LINE_2″ and three no-op instructions. The reason the no-ops are needed is that when a branch or jump instruction is fetched, the condition that determines which branch is taken isn’t carried out until the instruction reaches the execute stage, which is three stages in. So, if there weren’t no-ops there, the instructions immediately following the branch instruction would be fed into the pipeline. If the branch instruction did end up being taken, the instructions following the branch instruction should be skipped. But if they’re already being executed, they could cause problems.

Well, that’s all for now, unless I think of something else I’d like to add to this post. This has been an awesome project that introduced me to logic and CPU design, hardware design, FPGAs, and VHDL. It taught me to read datasheets very carefully and thoroughly to save time and stress when attempting to interface with memory. It was really cool for me to design my own CPU, place it in a system to make a simple computer, write code for it in an assembly language that I created, then make it all happen in real life.

Ben Oztalay