Big Mess o’ Wires

Photo by Joe Pankow Oh ye gods! Crazy, nutty, insane. The past few days have been among the strangest of my life. I think I’ve had my 15 minutes of fame and then some. First there was the article about BMOW 1 on Wired.com, then the story got picked up by CNet, Digg, Slashdot, Engadget, Gizmodo, Reddit, and many others, all over the web. My inbox overflowed with people asking about the project. Then came the Maker Faire, where a few thousand people came through the BMOW booth over a two-day period. People were amazingly enthusiastic, and quite a few people told me they came to the Maker Faire specifically to see BMOW! In the Wired article about “What to do at the Maker Faire“, BMOW was even the featured attraction for the entire event. In the end, it won an editor’s choice award for the show, and I talked myself hoarse.

While I appreciate all the attention this project has suddenly received, I have to admit I feel like a fraud. For one thing, Bill Buzbee’s fabulous Magic-1 homebrew computer was also at the Maker Faire, and it’s twice as cool as BMOW, but didn’t get nearly the press coverage. I also think that most of the people talking about BMOW thought it was something it’s not. A lot of people seemed to have the idea that I’d built a CPU entirely out of wires, as if wires themselves could perform computations. Or they thought I’d built some kind of giant machine the size of a refrigerator. When they saw a rather ordinary-looking 12 x 8 inch board at the show, they looked disappointed. Many people also seemed to have the idea that I’d built a CPU out of thousands of individual transistors. Nope. BMOW is made from sixty-five chips including 7400-series parts, 22v10 PALs, ROMs, SRAM, a video DAC, and an AY audio chip.

It was an incredible time at the Maker Faire. Setup began on Friday, so I was able to get in before the show opened to the public, and chat with some of the other Makers before the crowds arrived. The show is sprawling, massive: two giant expo halls, plus all the grounds between and around them, and half of an enormous parking lot. It was really too much to experience in a single day.

One downside of being a Maker presenting BMOW is that I didn’t get much chance to visit the other exhibits. Fortunately, I did have a chance to talk with a few amazingly brilliant people. I spoke to Jeri Ellsworth, creator of the C-One reconfigurable retro-computer (who was demoing DIY transistors), Limor “Lady Ada” Fried, inventor of all manner of Arduino and other electronic projects, and evilmadscientist.com’s Windell Oskay, who was demonstrating the Candy Fab 6000 sugar-based 3D printer. There were also many other amazing and creative people I spoke to, not all of whose names I caught, but it was great to get wrapped up in an aura of geeky achievements with them all.

Thanks to everyone who came by the BMOW booth at the Faire, and to my friends Kevin and Eric for helping out as BMOW crew members for the weekend. The booth was packed almost non-stop from open to close, both days. If I’d had the foresight to make extras, I could have sold a ton of books and T-shirts, and lots of people asked about them. Some people even asked about buying kits. I can only assume they had a spare year with no particular plans, and were looking to fill it. A few people came by the booth and gave me free stuff! A guy from Parallax gave me a Propeller development board. I’ll definitely have to play around with that.


A few questions about BMOW came up again and again:

• “What’s the operating system?” When I answered “there isn’t one”, this seemed to blow people’s minds. How could you have a computer without an OS? For BMOW the hardware is so simple, the programs themselves essentially *are* the OS.
• “What compiler did you use to write programs?” Some people seemed genuinely astounded that it’s possible for a human to write programs in assembly language. Whether they’re too young to remember when that was the norm, or have just spent too much time coding in Python or something, I don’t know. Yes, it’s all BMOW assembly language, which is mostly identical to 6502 assembly. I tinkered with retargeting a C compiler for BMOW, but never went very far with it.
• “Where are the wires?” Ah yeah. I supposed it’s false advertising to have a project called “Big Mess o’ Wires”, and not have a giant hairball of wiring hanging out somewhere. There wires are all hidden on the underside of the system board. Sorry.

In the end, BMOW won a Maker Faire Editor’s Choice award. In fact, it won one twice. I’m not really sure what happened there, but when the second editor came by with Lady Ada to give me the award, and heard that someone else had already given me one, he seemed pretty ticked. I’m guessing maybe different editors were supposed to give awards in different categories, and two different editors claimed BMOW in their category. Regardless, I’m thrilled and excited to be recognized by Make.

To the guy I talked with who’s got some unused wire-wrap boards, please send me an email, and I promise to give them a good home. To the guy who turned out to live down the street from me in Belmont, email me, and maybe we can hook-up for some neighborhood nerd projects. For anyone else who emailed me already, if I didn’t reply, try me again.

Last but not least, I’m taking orders for SWAG. If you’d like a few BMOW stickers, send me a SASE or $0.50 by PayPal, and I’ll get you some. I’ll also be placing another order for BMOW T-shirts in a week, on June 7. If you’re in the USA, send me $28 by PayPal before the 7th, along with your shirt size, and you’ll get a shirt in a couple of weeks. If you’re outside the USA, email me to ask about shipping costs. Sorry, but 5-color silkscreened T-shirts for small run orders aren’t cheap. I’m not making any profit off these.

Whew! It’s been an amazing couple of days, but I’ve had enough. Time to go crack open a beer.

Meeting Bill Buzbee, creator of the Magic-1:

A day at the Maker Faire:

Crazy day today! Maker Faire setup begins tomorrow, and BMOW is featured on wired.com, and is the #1 Top in All Topics story on Digg! Oh man, this poor server is getting hammered.

Many people have asked for high-res photos. See this entry from February, and click any of the thumbnails to get the high-res versions of wire-wrapping craziness.

For people interested in viewing or buying the “Making of BMOW” photo book, you can order it from Shutterfly here.

Here’s a summary of  the project, for everyone following the link from the article.

Big Mess o’ Wires 1 is an original CPU design. It does not use any commercial CPU, but instead has a custom CPU constructed from dozens of simple logic chips. Around this foundation is built a full computer with support for a keyboard, sound, video, and external peripherals.

My original goals were:

• Build the CPU from scratch, primarily using basic 7400-series logic. No 6502, Z-80, etc.
• Keep the hardware complexity to a minimum. I’m not an electrical engineer.
• Be capable of running “real” programs, not a 4-bit CPU or toy machine.
• Provide a way to interface with a PC.
• Be fast enough to run interesting programs interactively.

Stretch goals:

• Boot into a simple integer BASIC program, capable of interactively editing and running its own programs.
• Support multiple programs executing simultaneously, via a pre-emptive multitasking OS.
• Provide keyboard input, VGA video and sound output.

Initial design began in November 2007 with a high-level sketch of the CPU internal design. A simplified Verilog hardware simulation proved the key design details. Construction began in earnest in February 2008, using a large wire-wrap board to interconnect the 50 or so chips needed. In April, a half-finished BMOW 1 booted up for the first time, computing fibonacci(12) = 144 using a simple ROM-based program. One by one the original system goals and stretch goals were met, including VGA video, three voice audio, BASIC, and a bootloader for communication with an attached PC. BMOW 1 eventually gained the ability to run complex programs written in assembly or compiled from C. The main construction phase ended in February 2009, with the completion of a customized case to house everything. As of March 2009, Big Mess o’ Wires 1 is fully functional, but will probably never be “finished”.

Architecture

BMOW 1 borrows liberally from other homebrew designs, as well as the MAYBE design presented in the book Computation Structures by Stephen Ward and Robert Halstead. Data busses are 8 bits wide, and the address bus is 24 bits. Four 8-bit registers are used for general data, and three 24-bit registers store the program counter, stack pointer, and a scratch/working address pointer. Registers and the arithmetic and logic unit are interconnected by one data bus, while RAM, ROM, and memory-mapped hardware devices use a second data bus. The ALU also has dedicated left and right data input busses.

Machine language instructions are implemented as a series of micro-instructions, stored in three parallel ROMs to create a 24-bit microcode word. One micro-instruction is executed each clock cycle, and the micro-instruction bits are used directly as enable and select inputs to control all the chips in the machine. Up to 16 micro-instructions may be needed to implement a single machine language instruction.

Note: Some additional devices are not shown here, including the VGA display circuitry and real-time clock.

24-bit addresses allow for up to 16MB of memory, but only a little more than 1MB of combined RAM and ROM is installed. The most-significant byte of the address is called the bank byte, and is normally invisible to programs. The standard instruction set presents a 16-bit interface to programs, with most instructions implicitly referencing the current bank. Cross-bank references are possible, but awkward (think x86 segment registers).

A 512K ROM contains a bootloader/menu program. A USB-to-TTL interface based on an FTDI chip provides an easy way to move data to and from a connected PC. A standard PC keyboard with PS/2 connector is used for keyboard input, and a 24×2 character text LCD serves as a debug output display. Custom video circuitry drives a standard VGA monitor, with a maximum resolution of 512 x 480. A three-voice programmable sound generator provides music and sounds.

BMOW 1 is built on an Augat wire-wrap board pre-populated with thousands of wire-wrap pins. The chips are pushed into the board without soldering, and can be easily removed, similar to a prototyping breadboard. Unlike a breadboard, the pins are individually connected on the underside of the board according to the needs of the circuit design. A wire-wrap tool is used to wrap stripped wire ends tightly around each pin. Wires can be removed fairly easily in case of a mistake. BMOW 1 contains about 2500 such wire wraps.

Specs

• Current clock speed is 2MHz. It could theoretically go to about 3MHz (untested).
• 512 KBytes of RAM, 512 KBytes of ROM.
• Power draw is 10 Watts, 2.0A at 5V.
• VGA video output is 512×480 with two colors, or 128×240 with 256 colors.
• Audio and music is provided by a three-voice programmable sound generator.
• Keyboard input is a standard PC keyboard with PS/2 connector.
• Debug display is a 24×2 character text LCD.
• There are roughly 1250 wires connecting the components, so 2500 individual hand-turned wire wraps.

Please send me your thoughts and questions!

BMOW 1 Photo Gallery

Four more days until the Maker Faire, and preparations have reached a fever pitch. I was interviewed by a Wired reporter on Friday, and a photographer is coming tomorrow to get pictures of me in my “workshop”, which should be good for a laugh. It’s all for an article that will appear on wired.com Wednesday or Thursday.

Friday is setup day, and I’ve arranged to take the day off from work. It’s not that I really need much setup, but I want to be there while everyone else is setting up, and scope out the exhibits. There are also a couple of Maker-to-Maker events on Friday before the faire opens to the public Saturday morning, including a Maker dinner on Friday night that I’m pretty excited about.

Big Mess o’ Wires will be in the main Expo Hall, booth 296. It’s on the other side of the floor from the Sparkfun booth, in a cluster of about a dozen other small booths. It looks like a pretty good location, near one of the doors so it’ll get some traffic, and not next to the bathroom or behind the stage or someplace similarly odd, so I’m optimistic. I’ve also recruited a couple of friends to be the BMOW crew for the weekend, so there will be someone on hand if I need to leave the booth for a while, or to help handle the teeming crowds that will no doubt be packing the BMOW booth. *cough*

Meanwhile, preparations on the home front are nearly complete. BMOW is fitted with its new transparent laser-etched cover, and tested with its demo attract loop. I’ve got photos, stickers, T-shirts, a “making of” book, and a technical manual with all the schematics and other documentation. I’ve even got a dummy wire-wrap board for people to check out, or try their hand at doing some wraps themselves.

I’ve created a BMOW Powerpoint presentation to answer the questions of “what is this, and why should I care”, which will be looping continuously on another computer in the booth. I welcome feedback on anything that has too much or too little detail, or other general suggestions for improvements.

I hope to meet some of you in person this weekend at the faire!

Edit:  The WIRED article about BMOW is up. Thanks Priya!

Finally, I got the Uzebox to work! I’m not quite sure what made the difference, though.

First, I tore apart my earlier breadboard setup, and rebuilt the circuit from scratch, as neatly as I possibly could. Then I scrapped my grayscale DAC, and dropped the AD725 RGB to NTSC chip into the circuit (which had arrived in the mail since my previous attempts). Soldering the AD725 was my first experience at SMD soldering, and it was a little challenging, but not too bad. I managed to get 15 of the 16 pins soldered successfully on the first attempt, but the last pin just wouldn’t bond to the pad. I must have made 20 attempts to solder it, and was about to give up and solder a jumper wire to the pin, when I finally got it.

I connected the circuit to my finicky Dell monitor, turned it on, and voila! It worked!

The image quality is OK, but seems a bit blurry, and there’s noticeable color blooming. The interior of a red letter R is dark red instead of black, for instance. The photos here actually make it look cleaner than it really is. It’s certainly very playable, though, and maybe I’ve just forgotten what composite video quality looks like.

The rewired circuit on the breadboard:

Pac-Man title screen on the Dell monitor:

Pac-Man maze on the Dell monitor:

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.

BMOW shirts arrived today. Not a giveaway– just enough for family and crew at the Maker Faire.

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.

I’ve been going a little overboard with all the BMOW stuff for the Maker Faire. I’ve spent about $300 on assorted stuff, which is a little crazy considering that this isn’t a profit-making enterprise, and there’s really no good reason to have stickers and posters and books and things, but I can’t stop myself. Help, I think I have a problem!

I used Shutterfly to print four large photos of the wiring side of the BMOW main board, which I’ll have around the booth at the Maker Faire. While I was browsing the the Shutterfly site, I also noticed a special they were running: a twenty page 8 x 11 inch hardcover photo book for $23. I couldn’t resist, so I spent a few hours designing a “Making of BMOW” book for people to browse at the booth. It’s a condensed version of the past year and a half of this blog. The book arrived yesterday, and it’s awesome! The front cover has a hole cut in it, framing the photo on the title page, which is a nice touch.

Here are a couple of sample pages from inside the book. It all looks really professional.

I should have stopped there, but I didn’t. Another idea I’ve been mulling for a while is creating a clear cover for the BMOW case. I’m a little worried it might get damaged or spilled upon if I leave the case cover off during the Maker Faire, but with the existing cover in place, it becomes just a boring beige box. I wasn’t really sure how to go about making a custom clear cover though, and never took the idea any further.

Last week it occured to me that a custom clear cover doesn’t really need to be a complete replacement for the metal cover, with full sides, back, guide rails, and so forth. All I really need is a 2D cover that can be mounted to the system board using standoffs, and will protect the board from most hazards from above. That would still leave some small gaps at the sides and edges, but they’d be small enough to not be worrisome. So I took some measurements, spent an hour designing a cover using Corel Draw, and mailed the file off to Pololu, a company that does custom laser cutting of various materials.

The cover arrived yesterday, and it’s pretty much the coolest thing ever. It’s 1/8″ clear acrylic, with laser cut mounting holes, and a grille for the speaker. The BMOW logo is also etched into the cover, using the laser at a low-power setting so it didn’t burn all the way through.

I’m just blown away that I can spend an hour in a vector drawing program, send the file off into the ether, and three days later get an exact physical part on my doorstep for $29. I’ll definitely be looking for more excuses to custom fabricate parts in the future.

I haven’t yet confirmed that the cover fits, since I need to get the correct size standoffs first. It looks perfect to an eyeball test, though. My vector layout file was based on hand-measurements made with a ruler, so it’s entirely possible that the mounting hole positions are slightly off. I made the hole diameters bigger than needed to allow for some error, and if worse comes to worse, I’ll try drilling out the holes to correct any major mismeasurements.

Over the past few days I’ve done a huge amount of reading about both 3D graphics hardware and FPGAs, and I’m starting to get a better picture in my mind of how this 3D Graphics Thingy might be built. My surprising conclusion is that 3DGT may not require any custom hardware at all, but could be entirely implemented using an off-the-shelf FPGA development board. This is either good or bad, depending on your point of view.

Looking back at my earlier “construction notes” posting, I described a vision of 3DGT as a single-board computer with a CPU, FPGA, RAM, ROM, keyboard, USB, and VGA output. That more or less exactly describes an FPGA development board. All the work would then go into creating the HDL for the graphics pipeline, which would be programmed into the FPGA, turning 3DGT into a mostly firmware project. There would still be a few missing hardware pieces when using an FPGA development board, however:

• CPU – I still need a CPU to drive the graphics pipeline, and determine what to draw. Some high-end FPGAs actually have a CPU built-in, but those are out of my price range. My first approach will be to embed a “soft CPU” into the FPGA along with everything else. Xilinx provides a PicoBlaze 8-bit soft CPU that only consumes about 5% of the space in a Spartan 3 FPGA. There’s also the OpenRISC soft CPU from OpenCores.org, if something more powerful is needed. And if a soft CPU doesn’t work out, I can add a real CPU on a daughter card, attached to the development board’s expansion connector.
• VGA – There are lots of development boards with integrated VGA hardware. However, the cheaper boards are all limited to a few bits per color channel. The best I’ve seen is 4:4:4 12-bit color. That will be great for initial testing, but ultimately I’ll need to add a separate 8:8:8 video DAC on a daughter card.
• Joystick, etc – Connecting a gamepad will require a bit of custom hardware, also on a daughter card. Any sound hardware would need to be external to the daughter board too. For initial testing, I can use the built-in keyboard connection.

I like where this is going, although it’s a lot less hardware-oriented than I’d initially expected. Essentially, I can purchase an FPGA development board and get started immediately, using a soft CPU, low bit-depth VGA, and keyboard input. Once the guts of the graphics pipeline are mostly working, I can expand by adding a daughter card with a CPU, video DAC, gamepad connector, etc. For the final version I might create a custom single-board PCB for exactly the hardware I need, and ditch the development board, or just keep the development board + daughter board as the final hardware.

The development boards I’m considering are Xilinx’s Spartan-3E Starter Kit and Spartan-3A Starter Kit. These seem to be the best fit as far as including the parts I need, without a lot of other parts I don’t need, or costing a million dollars. There’s also a wealth of information and tutorials online about how to use these boards, from Xilinx and third parties.

Both boards include the FPGA, 32MB RAM, 16 or 32MB Flash ROM, VGA, USB, PS/2 keyboard input, two serial ports, ethernet, and a two-line LCD. I don’t need the serial ports or Ethernet, of course, but there they are. Both kits come with 50MHz clock oscillators built-in, but I couldn’t find any data on their maximum possible speeds, or the speed grades of the specific FPGAs.

• 3E – The $149 3E is the older board, with a XC3S500E sporting 10476 logic cells, 360K bits of block RAM, and 20 dedicated multipliers. The major drawback is that the VGA output is 1:1:1, allowing for just 8 colors. That would let me work on triangle rasterization, but not color interpolation or texturing. If I ever want to ditch the development board and make a custom PCB, though, the 3E kit is the way to go. The exact same FPGA is available from Sparkfun in a breakout board, as well as from other vendors, or it can also be purchased as a bare IC with leads that I can solder myself.
• 3A – The $189 3A is the newer board, hosting a XC3S700A. The 3A has 13248 logic cells, 360K bits of block RAM, and 20 dedicated multipliers. The larger number of logic cells is nice, but the big advantage of this kit is the 4:4:4 VGA interface, enabling 4096 colors. The drawback is that if I later want to drop the development board and make a custom PCB, it’ll be difficult to do without switching away from the 3A. It’s only available in a leadless BGA package that I can’t hand-solder, and I haven’t found any 3A breakout boards or adapters advertised online.

Along with all this research into the development hardware, I also did some reading about other similar 3D graphics FPGA projects, hoping I might learn from them. Maybe I didn’t dig hard enough, but I didn’t find much, and what I did find were all unfinished projects:

• Manticore – A project started by two students at the University of Alberta in 2002, but never finished. They implemented a basic rasterizer that will be very interesting to examine, as well as a memory controller to arbitrate memory requests and talk to DRAM. They never worked out all the bugs in the rasterizer though, and the design lacks a z-buffer and texture mapping.
• Niklas Knutsson Thesis Project – A 2005 Master’s thesis from Linköping University, Sweden. This is a great description of the task of implementing a 3D graphics pipeline in an FPGA, but the implementation was never finished. He got as far as drawing some basic test patterns, but most of the design time was spent on the CPU and memory controller, so the 3D pipeline wasn’t fully fleshed out. The HDL source and schematics don’t seem to be available online, unfortunately.
• Open Graphics Project – This is an ongoing project to build a fully PC-compatible graphics card, using a pair of FPGAs on a PCI card. Coincidentally, it was featured on the front page of Slashdot just yesterday. The majority of the development so far appears to have centered on the PCI interface, and support for legacy VGA modes. The documentation on the 3D pipeline is fairly skeletal, and it appears that little of it has actually been implemented so far.

I’m surprised there aren’t more projects out there like this, and apparently none that were ever successful. I’m guessing that such projects do exist, and I’ll just have to dig a little deeper to find them.