older low-resolution led scrolling signs (with passive matrixes) are driven by shift registers and discrete logic, not cplds and fpgas, neither of which existed in the 70s. a current chip you can use for this is the 74hc595, which features tristate outputs and latching, neither of which are necessary for this application. i think maybe in the 01970s you'd use a 74164, which first came out in 01974

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