48x32: A 1536 LED Game Computer (opens in new tab)

The input likely would have been a punched card for a fully bitmapped display, or something more complex for a character-syntherizing display with a ROM inside it.

In late 1980s you'd likely already use a 8-bit CPU and a bit of SRAM, with scanning.

I never got around to making a proper video about the construction and installation, but I do have this demo of one of the applications I wrote for it:

https://www.youtube.com/watch?v=gSq8dYBHVBQ

I should do a full write-up so I can submit it to HN. Code's on GitHub anyway. https://github.com/masto/LED-Marquee

the basic outline of the circuit is that the leds are in a matrix, one row of the matrix is turned on at a time, and each column of the matrix is wired up to an output pin on one of the 74hc595s through a resistor. that pin can pull it low to turn on one led in that column, or not (an uln2003 open-collector driver will work here, and can handle a lot more current than the 74164's rated 27.5 milliamps, which is helpful for getting good brightness). all the shift registers are chained together with a common clock, so you can shift a new row of pixels into any number of them with just two wires, clock and data

this may sound like a lot of chips and complexity to drive the columns, and actually it kind of is, but there's no way to avoid it with a cpld or fpga, even today; each of those columns needs tens or ideally hundreds of milliamps, and it needs a separate pin on a driver chip. like maybe you can cheat somewhat with charlieplexing but not very much. instead the trend is ws2812ing an entire driver chip into every led package

the row lines have to carry a lot more current, several amps, so you need a power transistor for each one to pull it high at the appropriate time. when you switch from one row to the next, you need to shift a new row of pixels into the shift register. the newfangled 74hc595 (from 01982) lets you do this while it's still driving the old row, switching over on a positive-going edge on its rclk line. the 74164 lacks this feature and so to guarantee glitch-free updates you need to shift new data into it while no row line is active

selecting which of the rows to pull high can be done with a 3-bit or 4-bit counter driving a bcd decoder chip

where do you get all those pixels to shift into the shift registers, though? from a character generator rom. don lancaster's tv typewriter cookbook https://www.tinaja.com/ebooks/tvtcb.pdf lists the signetics 2513 and the monolithic memories 6072 among others. you feed them an ascii code (or in some cases six bits of one) and a line number and get a row of pixels out, which you then need to load into a parallel-in-serial-out shift register. the 2513, released in 01970 and used in the apple 1 http://www.thealmightyguru.com/Wiki/index.php?title=Signetic..., could run at over a megahertz, so it can handle a 6-megahertz dot clock if there's one blank column between characters. the 74164 is rated for 36 megahertz

typically you want to scroll the sign by one pixel column between redraws, not one character, so you need a way to advance the signal by one to six pixels. i don't know what the standard approach to that was, but several clear possibilities present themselves

then you're left with the question of where you get the ascii codes to drive the character generator. you can get those out of a ram or rom chip driven by a counter, but a lot of cheap designs from the 70s use long recirculating serial-in-serial-out shift registers instead, so they don't have to generate addresses

you don't actually need a whole lot of speed for this, as electronics go. the display might display 32 6×7 character cells at 60 hertz. that's only 80640 pixels per second. if your shift registers don't have the helpful latching outputs of the 74hc595, you have to load all those pixels when the display is turned off (during the horizontal blanking interval, as it were), so you might need to use a 240 kilohertz dot clock to avoid cutting into the leds' duty cycle too much. everything else is much slower. the character generator and the memory driving it run at a sixth that speed, 40 kilohertz. it advances the horizontal scroll every "vertical blanking interval", 60 hertz. it switches to a new row 7 times as often, 420 hertz. (dank.) the horizontal blanking state machine might run at four times that frequency, 1680 hertz

once you could get things like an intel 8748 (first released in 01976, 1 kibibyte of eprom expandable to 4 kibibytes externally) you might have been well served to move all the control logic into software except shifting the row pixels into the electronic centipede of column-driver shift registers, for which you probably want to output 8 bits at a time. in practice i think it took designers sort of a long time to come around to this point of view

Running in series with the regular adafruit library would work as well but at this number of pixels the refresh rate might start to get a bit choppy, and you probably want to add power in the middle of the string regardless so the wiring isn't any harder.

Then use a library on the pi, for example this: https://github.com/jgarff/rpi_ws281x

https://m.youtube.com/watch?v=mGU8dlvOPUY

But there are 3.5 x 2.8 mm LEDs that use the same principle (though they are less bright) which would allow for half the pitch, or maybe it could be done with the original ones (but they are pretty expensive at $0.032 each in quantity 10000).

Any ideas on cost reduction would be much appreciated.

These LEDs put out an insane amount of light at full illumination, they do a about 50 mA each so if you were to set all of them to 'white' and maximum intensity (255,255,255) then that would work out to 1536x.05A or a whopping 75A. You'd need a very beefy power supply to be able to do that and you'd need to power each of the LED boards separately (they already have leads soldered on for that purpose but I left those unconnected for now).

At 5V power consumption would be 375W, and I reckon the boards would get fairly hot, each LED would do .250 W.

So for practical reasons I think limiting the intensity is a smart move, unless you know for sure that you will be illuminating only very few LEDs.