NANDputer lives!

Yep, it’s been a long time since I’ve posted anything on here, so I hope to remedy that by posting some updates of the various projects.

First on the list is the NANDputer.   What is a NANDputer?  it’s a computer made out of nothing but NAND gates of course!  I dunno why, but I thought it’d be fun to make this.  I first had to work out how various parts of a CPU would be made out of NANDs, did a bunch of tests and went to town.

The design took about 2 months to come up with and make.   At the bottom of the post is a few statistics on gate usage and count of each type (2 input, 3 input, 4 input, etc).  As I suspected, the quantity vs. gate input count follows a pretty steep curve, with most gates being 2 inputs, and the fewest being 13 input gates.

Everything on the design is made out of NAND gates, even the 7 segment decoding.   The last PCB though has a few non-NAND gate chips like an NES PPU and a serial chip and stuff, but it’s just a peripheral board and is not part of the NANDputer proper.  (Eventually I want to make a NAND UART and replace that peripheral board).

The basic architecture of the computer is actually fairly conventional.  There’s an accumulator, instruction skipping (like on PIC) for decision making, a full ALU (and, add, or, xor, subtract, add with carry, subtract with borrow, set all bits, clear all bits, shifting), 8 bit registers, separate RAM/ROM areas (harvard arch), and bit set/clearing.  There’s a 3 level stack, and even an interrupt!

While the CPU architecture is fairly conventional, the way it is implemented isn’t.  I went with a bit-serial setup on here to save gates.  The ALU for example is only 1 bit, with a “latching” carry so operations are performed a bit at a time on the 8 bit registers/memory.  The program counter is also bit-serial, and on the first youtube video you can see the carry propagating during the incrementing of it.

The downside of course is that this is much slower than a parallel architecture, but this way takes vastly fewer gates.  It takes 96 clock cycles to run a single instruction:  There’s 16 “T” states and 3 non-overlapping clocks generated using a 6 stage johnson counter with some NAND decoding.   (The flipflops that form the johnson counter are made from NANDs too).  Thus, it’s 16*9 or 96 cycles per instruction.  The clock runs at 10MHz, so this is a bit over 100KIPs (thousands of instructions per second).  This sounds really slow but it isn’t TOO slow.  It’s faster than a TMS1000, and it’s only 2-3x slower than a Commodore 64 which I estimate at 250-300kips when it runs at 1MHz (3 and 4 cycle instructions being some of the more common ones).

I eventually want to load a text adventure game on it, then hook it up to the internet and let people telnet into it and play it!  So far, I have gotten a few test programs to run on it using my 8 word “bogorom”:

8 word test ROM
8 word test ROM

This is made of 32 16 position rotary dip switches, which form 8 words of ROM (program ROM is 16 bits wide).  Each LED by that particular row lights up when it is being accessed.  This plugs into the ROM port.  It’s just 32 switches, 128 diodes, two 74HC245’s, a 74138, and a 74123 astable multivibrator chip to add wait states (this is mainly for testing- I want to use some more exotic ROM some time).

Quick overview of the various PCBs:

Timing board
Timing board
Timing board
Timing board

First stop is the timing board.  It generates the 16 T state phases and has the johnson counter to produce the three nonoverlapping clock phases, denoted phi0 through phi2.  To latch data into a register, one of these clock phases is NANDed with one of the T states.  The crystal oscillator is on the timing board along with the single stepping and animate oscillator.  Interestingly, the crystal I selected was a 3.6864MHz one, but the NAND oscillator is slllightly overdriving it and it’s actually running at 3x this!  About 11MHz as shown on the frequency counter.  I will eventually change it out to see how fast it’ll go.  To quote photonicinduction, I will “Crank ‘er up till she pops” and it quits functioning properly.  I might be able to get it up to 20MHz before the CPU malfunctions.

Program counter high
Program counter high
Program counter low
Program counter low

Next up is the program counter.  Each board handles 8 bits of it.  There’s the basic program counter latches, the 1 bit half adder to increment it, and the 3 level stack.  The stack takes up most of the two boards.   There’s not much more to it.

 

ROM and misc. logic
ROM and misc. logic

This board contains the ROM, and a header for a cable (not on this picture).  The added header runs to the bogoROM board.  A bunch of the random logic is on here- interrupt handling and JSR instruction  (jump to subroutine, aka “call”) stuff.  The EPROM is a 64K*16 bit model.  The NANDputer supports 64K words of program ROM, in 16 4K banks.  The program counter only increments the lower 12 bits, while the upper 4 are latched.  This is mainly due to running out of T states to increment all the bits.  If I extended the T state count, I could’ve incremented all 16.

Indexer's bad hair day
Indexer’s bad hair day
Indexer done
Indexer done

Next is the indexer.  Its job is to perform relative addressing, for reading or writing arrays in memory using the index register (X).  The first picture of it is complete, but the wires have not been “dressed” nicely to make it look nice and tidy.  It’s mainly some multiplexing and stuff.

RAM board top

The RAM board is next, and gets most of its inputs from the indexer.  I have an 8K*8 bit SRAM on here.  The empty spot on the board is for a RAM header to use external RAM devices.  I hope to use core memory or a delay line memory for RAM, eventually.

ALU
ALU

The ALU is after the RAM board.  Its job is fairly obvious.  It can add, subtract, rotate left, rotate right, increment, decrement, AND, OR, XOR, set all bits, clear all bits and set/clear individual bits.  I have not dressed the wires since I was still working on it.  I think I have it fully debugged.  This was the hardest part to debug and design due to the convoluted logic I employed.

 

IO Board (missing audio circuits)

The IO board isn’t very NAND-ey but this is peripherals.  I don’t think making an audio or video chip would be terribly easy to do out of NAND gates.  I will probably eventually replace this with a board with a NAND made UART, however.  On this board are two 82C55 triple 8 bit parallel ports, 82C51 UART, 82C54 triple timer, 29F002 2Mbit 8 bit flash ROM (for storing data), RP2C02 NES PPU with 32K of SRAM, SP0256-AL2 speech chip, SN76489 sound chip, and a YM2413 FM chip.  There’s also an AY-3-8912 sound chip, too.

All Nandputer boards installed into the backplane
All Nandputer boards installed into the backplane

To hook it all together is a backplane.   The backplane ties all of them together, and the display board plugs into this, too.

Front panel of the NANDputer with all the LEDs and controls

The display board plugs into the front of the backplane, and shows what’s going on.  The LED descriptions:

Top row is the program counter address and the 16 bit instruction word at this address.

The next three rows of LEDs (16 per row) are the 3 levels of the stack.  Under this is the halt LED (left) and the 16 T states

Then next row is 13 LEDs.  the first 12 LEDs are the RAM address (12 bits) and an unused LED.

The bottom row is the accumulator (left 8 bits) and status bits (carry, sign, zero, interrupt and an extra).

Switches on the very bottom left to right are:  reset, instruction / T-state,  run/stop,  free-run/animate, and single step.  The pot adjusts the speed at which it animates (automatic single step).

An early video of it running the program counter (note how the address “settles” down as the carry propagates up the bits making up the program counter.)

The other video is running a small 8 step program that causes the accumulator to shift a bit back and forth in “Knight Rider” fashion.   The BogoROM is used to store the program.


Here’s the down and dirty on the gate and chip counts:

Gate and Chip Counts
--------------------

Resource usage by chip type:

gate:   00   10   20   30  133   03   total
        -----------------------------------
display 10    1   10    3    0    8   32
timing  21   16    9    0    0    0   46
PCL     39   18    0    0    2    0   59  
PCH     39   16    4    0    0    0   59
ROM     22    5    7    5    1    0   40
indexer 43    4   10    3    0    0   60
RAM     42    7    2    4    1    0   56
-------------------------------------------
total  216   67   42   15    4    8   352

Resource usage by gate type:

gate:   2-in  3-in  4-in  8-in 13-in  2-OC unusd total
------------------------------------------------------
display  40     3    20     3     0    32   -2     96
timing   84    48    18     0     0     0    0    150
PLC     156    54     0     0     2     0   -1    212
PCH     156    48     8     0     0     0   -1    211
ROM      88    15    14     5     1     0    0    123
indexer 172    12    20     3     0     0    0    207
RAM     168    21     4     4     1     0    0    198
------------------------------------------------------
total   864   201    84    15     4    32   -4   1196
%     72.00 16.75  7.00  1.25  0.33  2.67 

unused gates
------------

gate:   2-in  3-in  4-in  total
-------------------------------
display   1     0     1     2
timing    0     0     0     0
PCL       1     0     0     1
PCH       0     1     0     1
ROM       0     0     0     0
indexer   0     0     0     0
RAM       0     0     0     0
-------------------------------
total     2     1     1     4

 

 

Well, I have deemed the FPGA Synthesizer “done”, at least in its current revision. I have still not lit up the MIDI port, but I don’t think I want to write a bunch of MIDI code in 6502 asm, so for now I have put the project on ice. It has exceeded all my expectations at this point.

So far, it plays the following stuff (all in hardware):

.NSF (complete with support for NES, VRC6, VRC7, FME7, N106, MMC5, FDS expansion audio)
.SID (complete, with quad-SID support, filters, RSID, PSID, and Compute! Gazette MUS format)
.GBS (complete, with normal Gameboy and Gameboy Colour support)
.SAP (complete, with dual POKEYs)
.SGC (complete, with support for SN76489, Colecovision, SMS, Gamegear modes)

It also plays a variety of FM music formats through a Verilog’d OPL3 (.CMF, .RAW, .IMF, .WLF, .D00)

Internally the following sound chips are written in Verilog by me:

6581/6582/8580 SID (quad, with full filters, full combined waveforms, proper ADSR w/ original bugs, 95% of a C64 to run RSID tunes, hardware filters)
RP2A03G NES (all expansion chips supported: VRC6, VRC7, FME7, N106, MMC5, FDS)
POKEY (As found on the Atari 8 bit line)
SN76489 (used for GG/SMS/Coleco)
AY-3-8910 (Written, but not used by a replayer yet)
OPL3 (FM support, can play OPL2 music also)

There’s around 70 or 80 separate sound channels that eventually get mixed down inside to the final DAC outputs. Most outputs have full user control of volume and channel selection, and if it gets filtered by the hardware filters or not.

The packaging was finally finished, along with the capacitive touch panel for the user interface. Battery charging and control are likewise finished, and I ended up implementing a first order derivative for the end of charge detection. Voltage depression isn’t very detectable on NiMh cells, so I couldn’t use that easily. The PIC’s ADC was too noisy to pick up the changes, so I went with delta temperature over delta time. When temp rise hits 3 degrees/minute, the charging is terminated. It works very well and doesn’t detect false ends of charge. There’s also a maximum temperature cutoff and a maximum time cutoff in case of some other kind of failure.




This is the UI PCB, it is a capacitive touch based affair.




Front of the finished synthesizer.




Side view.




Back view, showing power button and charge LED.




The guts.


So that’s the finished result. It didn’t come out too bad after all, but I did have to hack up the UI PCB some to make it work- Specifically I had to mount it on the top of the box and run wires to a cut up PCB inside that has the touch chip on it. The plastic was just way too thick on the enclosure for it to work through the plastic, unfortunately. But, the end result is pretty nice and the capacitive touch stuff works extremely well, so in the end it all worked out.

I will be working on a new synthesizer sometime in the future, which will be programmed in C, making development alot easier. Midi’s being reserved for that time.

FPGA Synthesizer Progress

Well it’s been awhile.  I haven’t been lazy, far from it.  Been so busy I haven’t had much chance to update the blog!  I spent the last 2 months learning verilog, and then performing a 100% conversion of my project from schematic entry to 100% verilog!  I didn’t know anything about verilog until having a little discussion with someone about it, and it seemed like a good time to learn it.   I already had a working project in schematic entry (around 150 schematics all linked together in this case) and figured it’d be a good learning experience to port it to verilog.

Long story short, the conversion was a success, and I ended up fixing a few bugs and adding some features along the way.  I ended up 100% redoing my OPL3 core, and vastly simplified and improved it, reducing device resource usage immensely.    To date, I have full support for the following sound chips:  SID (quad),  POKEY (quad), OPL3 (full support),  NES audio, N106 (8 chan wavetable), VRC6 (3 channels), VRC7 (FM synth), MMC5 (two squares+digi), FME7 (3 squares), and FDS audio (1 chan wavetable).  The wishlist of additions is:   Atari 2600 with extended range, Gameboy sound, and coleco/SMS sound (SN76489).  These shouldn’t be too tough, but before I can implement those I need to emulate the target CPUs which are Z80 and GBCPU.

This leads me to the current work:  I created a small RISC CPU for the FPGA which can emulate other 8 bit CPUs with cycle accuracy.  I figured that emulating the 8 bit CPUs would be by far more resource efficient on the FPGA, since to change the emulated CPU I only have to change the code in the block RAM.  Thus, 6502, Z80, GB CPU, etc. can be accomodated without sacrificing accuracy or speed, while only requiring one peice of hardware.  Ironically, the RISC CPU is smaller than the 6502 it will replace in FPGA resources.  The only minor downside is the 4K of blockRAM I used, but that’s a small price to pay ultimately for what it can do.

The specs on the CPU are:  18 bit instruction word, single cycle instructions, 32 bytes of RAM,  single and dual byte address modes, and a few special instructions to make CPU emulation easier such as jump tables and bit setting and clearing.  I named it the “KevRISC”  CPU 🙂

Altoids Tin FM Radio

…and now for something completely different! I got interested in super-regenerative receivers a few weeks ago, investigating ways to do simple, cheap radio links. Turns out it’s REALLY easy to do a few hundred feet with only a few parts. The secret words are “Super Regenerative”. A single transistor acts as an oscillator and detector and everything else, all in one shot. It’s an incredibly clever circuit, but it’s also old- older than even the super heterodyne. I won’t go over how it works- I will leave that up to Wikipedia.

My design isn’t 100% original, I poked around on the net for superregen circuits and then cribbed some ideas and came up with this circuit. It uses a second oscillator to quench the RF oscillator, which performs the detection of the signal. I used a schmitt trigger for this, setting it up as a simple RC oscillator, then used the approximate sawtooth produced on the capacitor to push the RF oscillator in and out of oscillation. This quench frequency is around 50-70KHz depending on the setting of the quench frequency. (This is adjusted so that it doesn’t cause a beat note with the 19KHz stereo pilot)

So, that’s what it is. Everything ended up fitting very neatly into an altoids tin. I soldered a piece of metal from the top of an RF shield to act as a battery holder. There’s a few wire loops soldered to the sides to hold wires, and I used some molex connectors to make a neat “install”. Unfortunately, the pictures aren’t very great.

Oh yeah, almost forgot. The coil is 4 turns on a 1/4″ form of #22 or so wire, tapped at 1 turn. Tap is near the ground end. Other than that, building it shouldn’t be difficult. If you cannot locate a suitable varactor diode, a variable capacitor will work… around 60pf max would be good. It’s hard to see, but I built it on perfboard, with the solder pad side up. The blank side of the perf is flat against the bottom of the tin for good shielding of the circuit. I used some resistor ends to attach the PCB to the bottom of the tin by soldering it. (Altoids tins are super nice to solder to, it takes the solder readily and easily due to the thinness of the metal). I used a mix of SMD and through hole depending on what I had to jump. The 74C14 is soldered in SIP fashion which ended up working very well.




View of the inside.




Another inside view.




Aaand the schematic. I forgot to make the part designations a darker colour. Sorry ’bout that. I will eventually get a better version.


FPGA Synth Power Supply

Welll, I worked some more and got the power supply designed, built, and assembled. Everything seems to work on it so far. The 5V and 12V outputs, both 2.8V linear LDOs, 5-12V converter (for USB in) and the battery charger seems to charge. The PCB was designed to drop in on top of the first PCB and it fits around the connectors and things perfectly. There’s some openings to allow for placement of the JTAG connector and stuff.




The supply board’s all plugged in and ready to go. It mates with a 10 pin power connector, a 2 pin signal connector and a 2 pin USB power connector. I will use standoffs and screws to join the boards eventually so they don’t come unplugged.




Top view semi closeup




Bottom view semi closeup.


The supply on this synthesizer had to fairly complicated. It had to perform the following functions: run off of 4 recharagable AA cells, run off of a 9V DC line lump, and run off of USB power. On top of that it has to charge the batteries from USB or the line lump. This is a fairly difficult thing to achieve for several reasons. The biggest problem is the output voltages (5V and 12V). The input voltage to the 5 and 12V regulators could vary between 3V (discharged AA rechargables) all the way up to potentially a bit more than 12V. So this means that the input voltage could dive UNDER the 5V output or over the 12V output… causing one supply to go out of regulation.

The solution was twin SEPIC converters which can handle this condition with ease. Running the two SEPIC converters are the two major inputs (USB power and line lump power “OR’d” together using diodes, and battery power). Both of these major inputs pass through P-channel FETs which can turn one source on at a time while isolating the two sources completely. This is done with two P channel FETs per input, wired back to back so the body diodes cannot both forward bias at the same time. I used two dual FETs for this function.

The battery charger simply connects between the power input (line lump / USB) and the battery input.

A PIC micro controls all functionality. It runs on 2.8V so it is quite low power. The PIC will run all the time, waiting for the user to press the power button if it’s totally “off”, and will control battery charging (it can control charging rate to accomodate various operational modes), control powering up of the unit, and it can take temperature of the batteries and internal environment to accomplish quick charging of the battery pack.

I have a “one wire” type interface between the PIC and the FPGA for communications. This will send USB operational modes up, and key presses and battery state, etc. down to the FPGA. There’s a second “one wire” interface between the power board and the to-be-designed capacitive touch panel board which will be the final piece of hardware for this unit.

First Light on the Big Board

So I spent another week or so, and finally got all the power supplies mounted, power sequencer done, and everything connected up on the board so far. I made a power control/sequencer dealie so that I can turn the supplies on 2 at a time. This will prevent me popping the circuit breaker if I tried to turn all 16 on at once. The caps charging would suck a dip in the mains big enough to cause the lights to dim in the city I think. Other than that the pics are fairly self explainatory I think. Everything seems to be working and tomorrow I will mount the remaining 6 LED boards, and try it out on a full array. Note that the bottom LED boards show the data flipped. I thought I had set the bits in the controller but I guess I didn’t. There’s bits on the display signal streams that let my mirror the displayed data along X and Y, but I obviously didn’t set them, so the lower half is upside down. whoops.




Lots of holes have been drilled into the plywood “chassis”. The 64 holes for the supplies aren’t on there yet though.




All 16 supplies have been mounted to the board, woot.




Aaaand, here’s where all the nice new connectors I added poke through the front.




Closeup of the supply wiring connecting all the 120V stuff and what not.




These 8 relays sequence on one at a time to turn the two supplies on each.




First light with 4 boards!




Then some gameboy action




And now 6 boards.

Display of Doom Comes Together!

Well even though I haven’t posted in awhile, I have been busy! I designed, ordered, and received custom machined brass parts that solder to the LED boards so I can mount them. These brackets allow me to mount the display boards without having anything that passes through the board or anything like that- this is important of course if you want a matrix that looks good.

I spent about a week looking for brass U channel stock to make the brackets, but I came up empty. The “legs” have to 1/16″ thick and spaced 1/2″ apart. This seems to be unobtainum. While I found plenty of U channel, it had 1/8″ thick legs, which wouldn’t work. It *has* to be 1/16th of an inch or else they’d hit chips and routes and stuff which is definitely Bad(tm).
(click ’em and watch most of the pics grow)




Brackets as received, and how they will mount on the PCB.


I soldered one on the board and it fits perfect.




Aaaand, all 5 installed.


After soldering 5 brackets to all 13 boards I have (12 good, 1 for parts and testing), it was time to mount them. I went to Lowes and bought all the materials needed. plexi, 1 by 6, and two kinds of plywood. The board that everything mounts to is 1/2″ thick plywood. It’s 48*32 inches which is in the “friggin’ huge” category! The entire unit will be about 34*54 inches when done, and under 5 inches thick. Inside will be 12 LED boards, 12 power supplies and the controller along with a blower I salvaged from a microwave oven. I designed the unit so I could mount 16 boards, if 4 more ever show up (anyone got extras? please? 🙂 but I will only stuff 12 for now. I have one more board than this, but it’s missing alot of LEDs and has tons of problems. I used it for fixing the other 12, and for testing stuff so I didn’t screw up the good boards.

Anyways, enough of that. here’s the pics that everyone wants to see I’m sure:




What 192 LEDs wide looks like! (did this so I could get the holes all drilled right)




All holes for displays drilled, and this is the 6*2 array of boards that I will be using.




Another view of it propped against a wall.




Finally, a pic of the blower I will be using to cool the works.


LED Matrix System Controller Hardware

Well took a week but I now have a complete system controller that can run up to 16 of these 72*24 LED boards. I designed it on saturday/sunday, ordered PCBs on sunday along with parts and just got the boards/parts today and put it together. So 6 days from design to finished unit. The unit is quite simple, it’s just a Cyclone 3 FPGA with some peripheral hardware.

There’s a 256K*36 bit wide SRAM for the frame buffer, two 16 channel LVDS transmitters to communicate with 16 LED display boards, a 16 jack ethernet panel, some regulators, a 40 pin “digital” input for plugging it into gameboys and such, power, programming and “user interface” connectors, and an NTSC/PAL/SECAM video decoder/digitizer.

The final goal of the entire device is a 144*144 pixel, RGB LED display with full 24 bit colour depth or as close to that as I can achieve realistically. I will first get some debug information working (the plasma again, then Conway’s Game of Life maybe, a real time Mandelbrot zoomer, and a Gameboy Colour will be attached. Finally, I will work on getting real live video input into it via the decoder.

This weekend I hope to get the LED controller communicating with one of the displays. After much debugging, I got the board to work I think. Quartus recognizes the FPGA and configuration ROMs, and I manually checked out the connections to make sure I didn’t have any shorts/opens and everything SEEMS to be a go. So now I will work out a simple serial interface via LVDS to communicate with these displays.

And now the fun part, pictures!




Some of the parts that go onto the board, along with the two bare boards (one front up, one front down).




Finished board




End view showing ethernet jacks




Side view




Bottom view. The ethernet jack panel isn’t fully soldered, in case there is some issue that requires me to pull it. I don’t think it will need to happen but I’d rather not unsolder 128 pins if I don’t have to.


LED Matrix Again

Well I’ve been working hard on those LED boards. I now have 12 fully working boards! I couldn’t fix the badly damaged board, but that’s fine- I have been using it for parts to fix the others. After some bad setbacks, I finally got 12 fully working and debugged boards running.

I learned something pretty valuable from the experience though- do not use a hot air rework station to attempt to remove LEDs! At least not these LEDs. I tried to remove 1 defective LED and the hot air killed 11 LEDs around the bad one. Turns out the epoxy cracked or pulled away from the substrate taking the bond wires with it, rendering a bunch of LEDs dead. I am not sure if it was a heat problem that did it, or popcorning where traces of moisture in the plastic package caused the plastic to crack as it turned into steam.

The solution to removing the LEDs turned out to be pretty simple. I took a piece of 1/4″ copper tubing and carefully bent the end into a square shape that fit around one LED. Then, I jammed it on the tip of the iron, tinned the copper, and proceeded to heat up all 6 connections on the LEDs at once. This neatly removed the LED without damaging the traces or anything around it. Of course it destroys the LED, but since it is already bad it’s no loss.

To remove good LEDs from the parts board took a bit of doing. I ended up using hot air, but I heated the board from the BOTTOM instead of the top. This melted the solder nicely and I could just pop them off with tweezers. I tested each LED of the 20 or so I removed and all worked fine proving that the technique is pretty decent.

After removing the bad LEDs from the boards and obtaining new ones, it was a simple matter to clean the boards up and stick new LEDs on. Except the connection pads are fully UNDER the LEDs. I tried some solder paste but this didn’t work. It ended up shorting out underneath. Turns out the solution is to go in hot and fast. Similar LED datasheets say to reflow at 260C, but at 260C the copper was sucking the iron’s heat away and it wouldn’t melt worth a damn. I turned it up to 400C and went in fast and it worked VERY well. I got good enough to put in 1 LED a minute near the end of the work. After their treatment all LEDs worked the first time.

One of the boards though had been reworked before I got it and whoever did it ripped three of the pads off one side of the LED, killing red and blue drive for it and the 3 LEDs below. I used some 30 gauge thermocouple wire as mini “zip cord” to route some wires around the break to get the lower 3 LEDs working, then some more soldered to the bottom of a new LED to replace the missing pads. The LED is crooked a tad but when viewed head on it looks fine.

Here’s a pic of the wired fixes:

It’s kind of hard to see but the wiring sits between the LEDs and when they are on, you cannot see it at all.

Soo, that was the fixing fun. I also have some more pics of the back side showing power/programming hookup since a few people wanted to see that. And now that I have 12 fully working boards the real project can begin: connecting all 12 together to make one massive 144*144 LED matrix. That’s 20736 LEDs, or 62208 LED dice! This week I will design and make a board for the controller. It will be a cyclone 3 FPGA, some RAM, video decoder, external input (for digital video sources), and a 2*8 jack ethernet patch bay with some LVDS transmitters. I *really* wanted 14 boards so I could make a giant gameboy resolution screen, but I have to take what I can get. The person I bought the boards from ran out and I bought all he had.

Oh yeah, I sawed up the remaining boards too so now all the boards have been sawn down to the right size for tiling.






Laying out the boards to get an idea of the finished size (40″ diagonal, 72*72cm). Some of the boards have rework marks on them, but this does not affect operation when they are lit.






Power and JTAG hookups




Back side overview




Another pic w/ closeup


LED Project Update

Wellll I have the goods all figured out now on gamma correction and LED drive levels so that it closely replicates a CRT-like response curve. This means that my test palettes look pretty much like they do on the PC. I have obtained 13 of these boards in total, and soon I will be putting them on a table saw to carefully remove about 3mm from the edges so that the boards can be tiled.

I tested the saw on 4 boards and it works very well. The boards continue to function after their ordeal and the boards fit together properly so that they can be tiled to make one super array without any gaps… at least in the Y direction. I will have to make a special cutting jig to do the cuts in the X direction, since the boards are so oblong. I will get a piece of wood or plastic and square the end, then screw the board to it and use this as a cutting guide. The cut has to be very precise so I do not saw through anything I want to keep.

Fortunately, the board is designed so that all the “stuff” is UNDER the LED array completely, so cutting the useless edges off does not impact anything at all. The two ends where a route can be seen inside the board is no trouble, it’s just a ground to the mounting holes. I will cut off one set of mounting holes so that the boards will tile properly on the Y direction.

After all 13 boards are properly cut and still work, I will then proceed with designing the system controller board. No sense wasting money on that if I screw the boards up.

Speaking of that, one of the 13 boards I have is really screwed up. About 100 of the LEDs don’t work right, and some of the driver lines are shorted. I will have to do some surgery on it if I hope to make that one work properly.

On two of the boards, the 5V and 3.3V drivers are shorted together on the output of the FETs, so I fixed that by lifting the 3.3V driver input.. This puts 5V on one row worth of red and green, but it doesn’t affect anything. The drivers get a tiny bit hotter is all, but since it’s constant current no other troubles arise.

Four of the boards have from 1 to 3 LEDs that don’t work either, but pressing on the LEDs causes them to light so the fix there is to put a little solder paste on and reflow it and those will be fixed.

So that’s the status on that project. Here’s a video of the thinger in action!