Big Mess o’ Wires

I’ve decided to build a minimal Uzebox. The Uzebox is a software-generated video game system based on an open source hardware design. It uses an ATMega644 microcontroller with 4K RAM to synthesize a composite video signal and sound on the fly, line by line. The official Uzebox design uses an Analog Devices AD725 RGB-to-composite chip, along with an SD card interface, and MIDI and joystick ports. I really wanted something super-minimal, though, so I dropped everything from the system except the ‘644 itself, the power supply, a piezo speaker, and some resistors and capacitors. I think it’s about as bare bones as you can get. Here’s what I came up with:

To replace the AD725 color chip, I constructed a grayscale binary weighted DAC from nine resistors. The eight color bits and the sync signal from the ‘644 are combined. I did some math to solve for the correct resistor values to produce 1 volt when all the colors bits are 1’s, and 0.3 volts when all the color bits are 0’s, assuming the sync signal is 1 in both cases. I must be getting dumber in my old age, because it took me a long time to churn through the math, and I eventually had to ask my wife to help. This was the result:

This seems right mathematically, but when I tried it connected to the TV, the resulting voltage was too low. When I removed the 75 Ohm resistor, everything looked nearly perfect. I don’t really understand that… should the video cable and TV itself be treated as a 75 Ohm resistor to ground in this calculation? Something about impedance matching that I don’t really grasp.

With the 75 Ohm resistor removed, I burned a Pac-Man game into the ‘644, connected the breadboard to the living room TV, and was rewarded with this:

The image quality is middling, but it’s not too bad for a quick breadboard job. The grayscale is definitely working, although it’s hard to see in this picture. The ghosts show the grayscale levels best.

Unfortunately I couldn’t get the Uzebox to work with the composite video input on my Dell monitor. It didn’t show anything at all, behaving the same as if nothing was even plugged in. I’m assuming this is because my video signal is too noisy, or out of spec somehow, and the monitor is more picky about signal quality than the TV. I looked at the video signal on the oscilloscope, though, and it looks pretty decent to me. Not too much noise, baseline is right at 0.3 volts, HSYNC pulses look fine. The brightest parts of the image do overshoot to about 1.25 volts, but I wouldn’t guess that would be a huge problem. I need to find a solution, though, because hauling the whole thing into the living room for every test isn’t too practical.

Although my interest here is primarily in the hardware, it’s damn impressive that this single ATMega644 with just 4K RAM is able to generate all the video and audio for a very faithful Pac-Man recreation. Remember, there’s no frame buffer. The video signal is generated on the fly, line by line, pixel by pixel, in the midst of all the other necessary game-related computation.

I’ve become interested in software generated video, after reading the book The Black Art of Video Game Console Design by André LaMothe. It’s a unique book, covering everything from atomic theory all the way up to building your own embedded computer system. Unfortunately it’s plagued by a million errors, but I was still fascinated by the idea of direct synthesis of video in software, which is part of the design of the game system discussed in the book.

Most computer systems (including BMOW) have dedicated video display hardware. The CPU writes data to video memory, and at the same time, the display hardware reads data from video memory and synthesizes the actual analog voltages that constitute the video signal for the monitor or TV. In BMOW the display hardware consists of fourteen separate chips, including the video memory itself, character generator, counters for the current row and column, shifter, oscillator, various registers and buffers, and a RAMDAC. It took a long time to design, but it’s pretty powerful.

In contrast, software-generated video creates the final video signal voltages directly from the CPU or microcontroller pins, with no intervening hardware at all except a handful of resistors to form a simple R2R DAC. You’ve got a MCU, some resistors, and that’s all. It generates the video signal in real time, on the fly, and there’s no need for any video memory or frame buffer. Fascinating stuff. The downside is that you need a fast MCU, and your code must be deterministic and per-clock-cycle exactly identical from scanline to scanline. Almost all the processing power is consumed by generating the video, so there’s little left for other logic, and logic code must be interleaved with the video code. I was vaguely aware of this technique before, but never really looked at it deeply because of all these problems with it. At least, that was the case until I saw some of the things the XGameStation from LaMothe’s book can do.

Check out the XGameStation Micro Edition web page. That’s some fairly impressive stuff from a little microcontroller and software-generated video. I decided I wanted to build one of these myself, as a short but interesting detour from work on 3D Graphics Thingy. Most of the XGameStation systems are prebuilt systems, which don’t interest me much, but there’s also the XGameStation Pico Edition that you can put together yourself. Perfect! Except it’s pretty expensive for what you get. I just can’t stomach paying $60 for a kit that contains a $3 microcontroller and a bunch of passive components that I mostly already own anyway. To make matters worse, a $50 SX-Key is also required to program the SX28 microcontroller, bringing the total cost to $110 for a simple little breadboard project.

I did some research, and found that I can get all the parts I need from the $60 Pico Edition kit for under $10 total, except one: the 78.75 MHz clock oscillator. In order to generate color video, you need a high-speed clock that’s an integer multiple of the base NTSC frequency of 3.579545 MHz. Sadly, these just don’t seem to exist anywhere that I’ve found. The only solution appears to be to buy a programmable oscillator, which is what the kit contains, I think. But programmable oscillators with the speed and precision needed are pretty expensive, and only sold in large quantities. Without that oscillator, it’s possible to generate black and white NTSC video only. Of course this still doesn’t change the need for the $50 SX-Key, for which I’ve found no alternative and no used ones for sale. Sigh.

As an alternative, I also looked into making a simple software-generated video system from a PIC24, which is at the heart of another XGameStation design. That’s a little more questionable, since there’s no specific “Pico” design using the PIC24 whose software I could use, but there is a wider selection of tools and software for the PIC series than the SX28. But the same oscillator requirements exist,  and while the PicKit2 programmer is a little cheaper than the SX-Key, it’s still not cheap.

At the moment then I’m stuck, and not sure if I should pursue this idea any further. The microcontroller and other parts can be had for just a couple of bucks, so it’s a bit frustrating that the oscillator and programmer requirements are turning this into a $100+ project.

My last planned bit of BMOW case construction was a front-mounted LCD. This required cutting a hole for the LCD in the faceplate, as well as a gap for the wires to pass through the steel case front. Once again my trusty Dremel tool was put to use. This time I enlisted the help of my daughter to get some action photos, while I cut through the steel. Look at those sparks fly! Yee-ha!!!

I am a manly man, cutting steel! Unfortunately, moments after this photo was taken, the Dremel unexpectedly shut down. At first I thought maybe I’d blown a fuse, but the house outlet still works fine, and there’s no fuse I can find anywhere on the tool. I tried cleaning out the motor brushes, but that’s about all I could think to try. The Dremel manual doesn’t mention anything about what to do when the tool fails to turn on. I guess I killed it. At least I had the cut about 95% finished, and I may be able to finish it off by hand.

Dremel Tool: 2009-2009 R.I.P

A while ago I purchased an old X-terminal and ripped out the guts, with the intention of using the case for BMOW. Upon opening it up, I discovered that the interior was partitioned into two parts by a steel divider welded to the base. The logic board was on one half and the power supply on another. Unfortunately BMOW needs the entire space in order to fit its oversized board.

Enter the Dremel tool. I got a Dremel and assortment of attachments for Christmas, but didn’t have a chance to try it until today. My plan was to simply cut the divider off, requiring about a 12 inch cut. The divider is made of 1/32 inch steel. Would the Dremel cut it? What kind of cutting attachment should I use? Would I slice off a thumb? I really had no idea how to use a Dremel, but a couple of the included attachments looked like cutting wheels, so I gave them a try. It took me about an hour and a half to make the 12 inch cut, and it looks pretty darn ragged, but the operation was a success. Sparks were flying everywhere… it was quite a sight! I ate up two entire cutting wheels, though, so I’m guessing a wheel made specifically for cutting steel would be better next time.

Here’s my handiwork. You can see the stump of the divider running from the case’s front to its back, about two-thirds of the way from left to right.

I had hoped to cut a large hole in the case lid, and cover it with a piece of plexiglass, to make a window where people could peer in and see BMOW’s guts. Given how this cut turned out, though, I think I’m going to abandon that idea. It would probably take me several hours to make a hole that large, and it would end up looked pretty ragged and ugly. Instead, I’ll just pop the lid when I do demos!

A brief note about the dead Arduino that I mentioned in the comments of my last post: I received a replacement Arduino, did some troubleshooting, and determined that there were multiple problems. I’d been using the original Arduino successfully to help test-drive my audio circuit before connecting it to BMOW, when in the span of five minutes it went from working to unresponsive. When the replacement Arduino arrived, initially it didn’t work either. I then tried both the old and new Arduinos on a Mac (primary machine is a PC), and also tried replacing the Atmega 168 chip in the original Arduino with a new preprogrammed chip.

What I found surprised me. First off, my PC seems to have lost the ability to download Arduino programs via auto-reset. It works fine on the Mac, but on the PC I have to manually hit the reset button with Ninja-like accuracy at precisely the right moment, about 1.5 seconds after pressing the download button in the software. I know that auto-reset is resetting the board, because I can see the Arduino program restart, but it never transitions to the download step successfully.

The second discovery was that the Atmega 168 in the original Arduino is dead. I don’t know how I killed it, but nothing I could do would revive it, on PC or Mac, auto-reset or manual reset. After replacing it with a new Atmega 168 that’s preprogrammed with the Arduino bootloader, it works with the same limitations as the new Arduino. I don’t know if the bootloader got overwritten somehow, or the chip itself is toast. I don’t have the hardware needed to restore the bootloader, so it will have to remain a mystery.

Yesterday I found an interesting advertisement. A Berkeley student was moving out of the area, and was selling his entire collection of electronics and robotics parts for $50. Of course I had to pick it up, so I’m now the proud owner of more random electronics stuff than you can imagine! Click the photos below to see larger versions.

Some of the more notable parts of the collection:

• An AIRat2 maze-solving robot. This apparently sells for $400 new! But this one is missing its LCD panel, and I don’t have the software for it. Still, I bet I can get it doing something interesting.
• A second half-built robot, with a couple of geared motors.
• A servo and a stepper motor (I think).
• Assorted robot tires.
• Two sonar rangefinders.
• A Sharp rangefinder (IR based?)
• A Xilinx CPLD development board.
• Some kind of camera and interface board.
• Four 11 volt lithium-polymer battery packs, and a LiPo charger.
• Tons of NiMH and NiCd rechargables.
• A 12 volt, 1 amp power supply.
• A solar panel.
• Lots of protoboards.
• Four LCD text displays.
• Assorted ICs: op-amps, voltage regulators, 555 timers, and more.
• A pile of IR and visible LEDs.
• A “helping hands” tool.
• A very nice wire cutter/stripper tool.
• A zillion feet of wire of various gauges and types.
• A lifetime supply of resistors, capacitors, diodes, transistors, relays, pots, switches, headers, etc.

That’s a ton of stuff! Hopefully I’ll get a chance to use it all well. Some of the parts like the batteries, CPLD, and passive components I can definitely use, but others like the robot or the sonar rangefinder will require a decent investment of time to investigate.

I’m beginning to really hate wire-wrapping. Sure, it’s easy to make modifications to the wiring, and the finished result will be nice and sturdy, but it’s SO SLOW to build! Now that my board is getting pretty full, it’s hard to even see the pin numbers, and I have to hunt around to find the endpoints of each wire. And especially when I need a length of wire that I don’t already have pre-cut, I have to spend more time measuring, cutting, and stripping. All told, I’m averaging a couple of minutes per wire. After about an hour of wire-wrapping, my brain overdoses on connections from AG32 to BB08, I begin to feel dizzy, and I have to stop. This has been my first wire-wrapping project, and I think it will be my last.

What then, if not wire-wrapping? A solderless protoboard is nice for prototyping, but doesn’t work well for large designs. It’s also not very permanent, since it’s easy to accidentally knock a wire loose. I could hand-solder point-to-point wires on a breadboard, but I think that would be like wire-wrapping, only worse. For medium-large designs like BMOW, I think the only real alternative is custom printed circuit boards. Unfortunately custom manufactured PCBs are expensive, at $50 to $100 depending on the size and quality. They’re also difficult to modify if you discover an error, so you’ll probably need to go through several versions of the PCB before you get something that works. Some people have had good success making their own PCBs at home, but it involves some nasty chemicals and drilling lots of holes and other headaches I’d rather avoid.

I did some comparison shopping for a hypothetical 4×6 inch 2-layer custom PCB:

Futurlec: $41 for a single plain board. $77 with soldermask and silkscreen.
BatchPCB: $70, including soldermask and silkscreen. Long lead times.
ExpressPCB: about $70, no soldermask or silkscreen.

Most places have a fairly high setup cost, but low cost for bigger boards, or higher quantities of boards. For example, Golden Phoenix will make a 100 square inch board with soldermask and silkscren for $89, and a 155 square inch board for $99.

I recently took a break from BMOW’s multi-tasking support to work on something completely different. (Actually, I have a multi-tasking demo working in the simultator, but it doesn’t work on the real hardware yet.) The “something different” was a robo-flower: a pulsing light powered from solar energy that’s made to look like a flower from Junkyard Wars. The circuit was based on this Make Magazine article, but the construction design is my own. Here’s a photo of the result:

During the day, the solar cell charges the main storage capacitor. At night, the storage capacitor powers the circuit, making the LED in the flower’s center pulse organically every few seconds. I followed the circuit design from the Make article, with these exceptions:

• Replaced the 1000uF “pumm” capacitor (C3) with a 3300uF one. This was one of the suggested alterations.
• Replaced the rechargable battery with a 1F “super capacitor”. A 10F capacitor was a suggested alteration, but I couldn’t find one.
• Where their diagram shows resistor R3 connected to the positive power supply, I instead connected it through a diode to the negative end of the LED. This makes the LED turn off all the way at the end of each pumm, which I think looks better.

The robo-flower works, but I’m pretty disappointed with how it turned out. For one thing, the pulses of light are surprisingly dim, compared to what I’d expected. They reach a brightness I’d call “on”, but not bright. If you look at the circuit diagram, you’ll see that the pulses come from the 3300uF capacitor (charged to about 3v) discharging through an LED. With no current-limiting resistor, there should be a brief pulse of high current = high brightness, but that’s not what I’m seeing.

The bigger disappointment is that even after leaving the flower in the sun until the main 1F storage capacitor is fully charged (as measured with a voltmeter), the pulsing only lasts for about 15 minutes after the sun’s illumination is lost. That’s pretty lame. Other designs that use rechargable batteries pulse nearly all night, I think, so I was expecting much more. Yes, it’s a capacitor powering the circuit and not a battery, but 1F is a mighty-big capacitance.

If I get motivated enough, I may build another copy of the circuit on a protoboard, so I can experiment with it further, or measure the voltage at various points on the oscilloscope, to see if I can’t improve the behavior. Otherwise it’ll be one more piece of odd electronics junk littering my home.

My Hewlett-Packard 1631D logic analyzer / digital oscilloscope arrived today: the finest 1985 technology that $35 can buy. I bought it dirt cheap from eBay in “as is” condition, but it seems to be working great! With this acquisition, I can proudly say that I’ve crossed the line from ordinary run-of-the-mill nerd to super-nerd.

Holy cow, there are a lot of buttons and wires on this thing. What’s a trigger? Where’s the manual? My head hurts just thinking about it.

After some time spent jabbing hesitantly at buttons, I finally managed to get a scope trace working. Here it is, showing the output of a 1 MHz clock oscillator. Mmmm, square wavy goodness!

While hunting for my soldering iron, I found my first digital electronics project gathering dust in a box. I thought I’d thrown it out long ago, so I was happily surprised to see it. It’s not much to look at– just a 555 timer and a bunch of NAND gates wired to a row of LEDs, configured so that a single “blip” of light races up and down the row like Knight Rider’s front bumper. In fact Knight Rider was probably still on the air when I built this thing in the spring of 1991. I called it The Opinicus Blinker.

Opinicus was the name of a fake technology company I pretended to work for during high school, so that I could get into trade shows and scam real companies for product samples.

Sadly, The Blinker broke a long time ago, which is why I thought I’d tossed it out. I hoped maybe I could troubleshoot the problem and fix it, but after cleaning the battery contacts and installing a new set of batteries, it fired right up. Woohoo! There it is with the second LED from the left illuminated. Not bad for a 17 year old piece of junk. And check out the legend on those chips: “SOVTEK 7400 11/88, MADE IN USSR”. Wow.

The rate of progress on BMOW has been slowing, as I prepare to begin actual construction. Everything is pretty much ready to go, and there are just a few more parts I need. The last real hurdle is working out the physical layout of the machine: where to fit the chips on the board, where to fit the board in the case, how to connect power, and so on. I’ve decided to mount everything on a piece of wooden shelving for the time being, rather than build a real case. I didn’t want to get so hung up on case design that it distracted me from the main task of getting the CPU built and running.