Starting in the late 80's They did use CPLDs and FPGAs to keep up. Here's one example on a low-resolution, 90's single color sign. It's the type you saw at movies theaters a lot. The controller was very typical, most were very similar.
https://wls.wwco.com/ledsigns/m-500/inside-the-m500.php
That's an Altera EPM3032A.
one quibble. if two 32-pixel-wide panels are daisy-chained, doesn't that mean it's sending one 64-pixel-wide row one pixel at a time, which gets shifted through the first panel into the second one?
you obviously know a lot more than i do, so maybe i'm missing something, but in either case i wouldn't expect noise or reflections, the signal levels and timing get restored at every shift stage, even low voltage cmos usually has more than a volt of noise margin, the traces are pretty short, and we're talking about longwave to shortwave frequencies, not microwave frequencies
True, but those tend to flicker because of that, they are not on steadily and that robs you of a lot of potential to create shades (and you'd need RGB individually, these WS2812B's are 3 LEDs in a single package).
Each LED decodes, stores and regenerates the signal to preserve integrity, that's why it work, there is about 200 ns lag for every LED that you add to a string.
admittedly most other alternatives like the buddhist, hebrew, discordian, and assyrian calendars have the same problem, but worse
http://www.nerdkits.com/store/NKLEDARRAY001/
Multi panel extension: http://www.nerdkits.com/videos/multipanel_spi_ledarray/
I have been thinking about display controllers for a while. In the 8-bit age home micros (like the C-64, TRS-80 Color Computer, Atari 400, TI-99/4A) usually had an ASIC display controller.
Some people have built sequels of those computers using DIP chip electronics, such as
and get frustrated because a decent framebuffer takes a lot of parts: there is an ad in Byte magazine from 1979 or so that shows a color framebuffer for an S-100 machine that is almost as large as my 4080 in area and packed with chips on both sides. It's not hard to design such a thing out of latches and counters and comparators but it is a lot of parts that need to be repeated across rather wide data paths. It's expensive for a product so they wind up making a display controller based on an FPGA or a microprocessor instead, if and when they do get to the point of making an ASIC it will be to put almost the whole computer on one.
in the crtc design space i think there's significant unexplored territory around polynomial interpolation that could allow you to get by with a lot less memory than you need for a whole framebuffer. but it'll probably stay unexplored because it's nowadays a lot more practical to just whack a up5k or something in there, and that has plenty of memory
______
†offer not valid for addition instructions, additional stack manipulation fees may apply, multipliers sold separately, your mileage may vary
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