7 ms·

These kind of projects are cool to me because they are a sort of blend of retro and modern. In that MCUs only got fast enough fairly recently to do this sort of

by tyingq 3y ago

These kind of projects are cool to me because they are a sort of blend of retro and modern. In that MCUs only got fast enough fairly recently to do this sort of thing well. All those older low resolution led scrolling signs you used to see around in the 70s, 80s, 90s, etc, had to use a CPLD or FPGA to get a decent refresh rate. Now that fast-ish MCUs are a thing, it's easier to get a mostly software based solution that looks decent, has a reasonable refresh/scan rate, etc. Edit: Noted below, I had missed that these were addressable matrixes, not passive ones.

londons_explore 3y ago
I don't think thats true... A 90's microcontroller could run a 48x32 game screen easily.
- tyingq 3y ago
  If you want varying brightness, good refresh rates, etc, no...they don't do well with a passive matrix display. Examples you can find with slower MCUs are sacrificing duty cycle, or brightness control, single color, etc.
  - londons_explore 3y ago
    These are neopixels though right? So the pixel itself can maintain a brightness, you just send it update commands. (obviously that isn't 90's tech)
    - daemonologist 3y ago
      The tricky thing with bit-banging neopixels is that the entire string has to be sent in sequence and the timing is quite tight. With the standard (modern) libraries you need the entire string ready to go in memory, which would've made things tricky with 90s RAM capacities. Semi-related: non-real time systems like the Raspberry Pi usually need to make use of audio/PWM hardware for neopixels and thus can only control one string, but Jeremy Bentham wrote some fantastic code which uses the secondary memory interface to drive up to 16: https://iosoft.blog/2020/09/29/raspberry-pi-multi-channel-ws2812/ https://iosoft.blog/2020/09/29/raspberry-pi-multi-channel-ws... .
    - tyingq 3y ago
      Ah, yeah, I missed the 'addressable' bit, so they aren't a passive matrix. Fooled by the 32x8 module, last I saw they were all single row strips or strings.
      - jacquesm 3y ago
        Effectively they are a single row that serpentines across the display backing board. You have to send all of them in order to change the last one so they are 'addressable' but not directly addressable.
nine_k 3y ago
In 1970s a large scrolling LED / neon sign would use a bunch of shift registers as the backing store and the scrolling mechanism. You only needed 1 bit; likely in 1980s you could add another bit (for red and green). This approach makes the display highly modular. 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.
masto 3y ago
I built an LED scrolling sign in my basement using the same 8x32 panels as the OP, controlled by the more-than-fast-ish-enough ESP32. 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 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 https://github.com/masto/LED-Marquee
- thousandknives 3y ago
  How much did that cost you to build? What kind of hardware did you use?
  - Max-q 3y ago
    You actually don't need more than the ESP32 and the led matrix. The LEDs are connected in series and you send a bit stream of RGB. Each led had an internal shift register with one input pin and one output pin, connected to the next LEDs input pin. So one microcontroller with one output pin available is all you need. Since there is no clock signal, timing needs to quite tight. To find more information you can google WS2812 or Neopixel. Libraries to use the protocol exists for most microcontrollers. An ESP32 module is a good choice because it costs $2-3, includes wifi and BT, antenna or UF-L plug, and is pre-certified.
    - thousandknives 3y ago
      Small misunderstanding. With hardware I meant the LEDs/LED matrix. What kind of LEDs did you use and how much did it cost you is what I wanted to know...
      - angus-prune 3y ago
        The information was in the post - ws2812 (or ws281x, there are variations) which are also known by the semi-brandname "neopixel". They come in various form factors including fairy lights, strips and matrixes. They are very easy to work with, and there are good libraries or open source platforms (eg wled) to run them.
kragen 3y ago
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 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=Signetics_2513 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

by tyingq 3y ago

londons_explore 3y ago

I don't think thats true... A 90's microcontroller could run a 48x32 game screen easily.

tyingq 3y ago
If you want varying brightness, good refresh rates, etc, no...they don't do well with a passive matrix display. Examples you can find with slower MCUs are sacrificing duty cycle, or brightness control, single color, etc.
- londons_explore 3y ago
  These are neopixels though right? So the pixel itself can maintain a brightness, you just send it update commands. (obviously that isn't 90's tech)
  - daemonologist 3y ago
    The tricky thing with bit-banging neopixels is that the entire string has to be sent in sequence and the timing is quite tight. With the standard (modern) libraries you need the entire string ready to go in memory, which would've made things tricky with 90s RAM capacities. Semi-related: non-real time systems like the Raspberry Pi usually need to make use of audio/PWM hardware for neopixels and thus can only control one string, but Jeremy Bentham wrote some fantastic code which uses the secondary memory interface to drive up to 16: https://iosoft.blog/2020/09/29/raspberry-pi-multi-channel-ws2812/ https://iosoft.blog/2020/09/29/raspberry-pi-multi-channel-ws... .
  - tyingq 3y ago
    Ah, yeah, I missed the 'addressable' bit, so they aren't a passive matrix. Fooled by the 32x8 module, last I saw they were all single row strips or strings.
    - jacquesm 3y ago
      Effectively they are a single row that serpentines across the display backing board. You have to send all of them in order to change the last one so they are 'addressable' but not directly addressable.

nine_k 3y ago

In 1970s a large scrolling LED / neon sign would use a bunch of shift registers as the backing store and the scrolling mechanism. You only needed 1 bit; likely in 1980s you could add another bit (for red and green). This approach makes the display highly modular. 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.

masto 3y ago

I built an LED scrolling sign in my basement using the same 8x32 panels as the OP, controlled by the more-than-fast-ish-enough ESP32. 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 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 https://github.com/masto/LED-Marquee

thousandknives 3y ago
How much did that cost you to build? What kind of hardware did you use?
- Max-q 3y ago
  You actually don't need more than the ESP32 and the led matrix. The LEDs are connected in series and you send a bit stream of RGB. Each led had an internal shift register with one input pin and one output pin, connected to the next LEDs input pin. So one microcontroller with one output pin available is all you need. Since there is no clock signal, timing needs to quite tight. To find more information you can google WS2812 or Neopixel. Libraries to use the protocol exists for most microcontrollers. An ESP32 module is a good choice because it costs $2-3, includes wifi and BT, antenna or UF-L plug, and is pre-certified.
  - thousandknives 3y ago
    Small misunderstanding. With hardware I meant the LEDs/LED matrix. What kind of LEDs did you use and how much did it cost you is what I wanted to know...
    - angus-prune 3y ago
      The information was in the post - ws2812 (or ws281x, there are variations) which are also known by the semi-brandname "neopixel". They come in various form factors including fairy lights, strips and matrixes. They are very easy to work with, and there are good libraries or open source platforms (eg wled) to run them.

kragen 3y ago

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 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=Signetics_2513 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