There is a tar file with STL files for the controller from 'Thingiverse' and lightburn files for the wood parts as well as the 48x32 include file that drives the display and reads the joysticks, this is used to build all games upon. The file is here: https://jacquesmattheij.com/48x32.tar
If you make any improvements I'd love to hear about them, soon I'll have a gitlab repository up with all of the code related parts as well as a schematic for the hardware (though it is so simple that if you just read the include file you'll know exactly how to hook it all up).
Best of luck with any re-creation efforts, if you run into trouble feel free to mail me (email in profile).
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.
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.
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:
They practically give ESP32s away with an oil change, so you could call it done at that point, but I chose to use a QuinLED Dig-Quad (https://quinled.info/pre-assembled-quinled-dig-quad/) to make it easy to wire up and mount on the wall. That cost me about $60 shipped. And I added a MEAN WELL LRS-100-5 power supply for $20.
Finally for the laser-cut frames, I burned up about $30 of wood, and there's some minimal amount of 3D printer filament as well. Along with the incidental things like having to buy a spool of 3-conductor cable, connectors, etc.
So all together I'd guess it was around $300. A completely no-frills version could be maybe half that.
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.
I made a little portrait frame and MCU that draws Conway's Life.
https://www.amazon.com/gp/product/B09CTQ37DB (I got the 16x16 for $16). Another <$10 for the ESP32. A soldering iron ($40 for a pinecil), $verylittle for solder and hook up wire. In my case, a 3D printer ($500) plus filament ($20), and some design software ($500/year, because Fusion 360 expensive).
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.
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-ws... .
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.
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.
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
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.
yeah, if you're not trying to replicate design blunders like the 99/4a you can probably do a lot better; the mup21 showed that if you're making an asic and willing to depart radically from the conventional wisdom you can get a crtc and a one-clock-per-instruction† 20-bit cpu with a pretty high clock speed into 7000 transistors, less than a z80
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
This brings back memories. I ordered a NerdKit many years ago and one of the projects was making a scrollable LED panel using similar techniques you're describing:
The shift registers are still there on the passive panels, that's the end bit...I was talking about the controller that drives the image to the panels. It sends one row at a time, to one panel...the panels are daisy chained. So, if you have 2 panels, each 32 pixels wide, it's only sending one row of 32 pixels at a time. Add in PWM for brightness, and a PWM rate for variable brightness that's fast enough to be viewed outdoors, and as you mention, more leds per pixel for 2+ colors...it outpaces a normal MCU pretty quickly.
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.
oh, yeah, for sure, once you're trying to generate a separate pwm waveform for each pixel, you need something more sophisticated than a 74hc595 driving the columns. aside from the ws2812 approach and the cpld/fpga approach, these days you can get custom led driver chips that do this, a separate pwm waveform (or sometimes programmable current sink) for each output pin, driven by daisy-chainable shift registers with multiple bits per pin
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?
It works like that for every LED. So the data for LED 1536 in a set of 6 ganged 8x32 arrays goes through all 1535 preceding LEDs! It's a miracle it works at all given the amount of stages, you'd expect that at some point there would be some noise but there really isn't, it's rock solid. The 8x32 is arranged such that it's 32 LEDs in one row (or actually, 96+a tiny processor) and then it moves to the next row so they serpentine across the board. Daisychaining multiple board just extends the serpentine further, it's all still one string. That's also why you need to treat odd and even rows a bit different during pixel addressing.
sure, in the led 1536, but the older panels we're talking about were multiplexed, so the data would only have to go through the (shift registers for the) previous leds on the same row
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
> but the older panels we're talking about were multiplexed, so the data would only have to go through the (shift registers for the) previous leds on the same row
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.
Why do you put a zero in front of the year? It took me way too long to figure out what you meant by “01976”. I have never seen anyone do this lol. I’m aware that date codes on components sometimes do that kind of thing but using it in text is just bizarre
my concern with the holocene calendar is that it introduces unwanted ambiguity in assertions like "we expect two meters of sea level rise by the year 12124". is that in 100 years or 10100 years?
admittedly most other alternatives like the buddhist, hebrew, discordian, and assyrian calendars have the same problem, but worse
I’ve been wanting to get into playing with LED matrices since seeing a great show by United Visual Artists in London which made a lot of use of them for really cool minimal visual effects.
My research suggests the best way to get started is with a HUB75 LED matrix (you can buy 32x32 or 64x64) and a MatrixPortal S3 board, which is an Arduino type thing with all the relevant connectors etc. for the LED board already installed. You can also buy and solder the relevant connections to an existing board, but I wanted something as easy as possible out of the box (even easier would be the Pimoroni Cosmic Unicorn, which contains it all in one pre built enclosure)
A few weeks ago I went through one of those drive through Christmas light displays. It had dozens of 10-20ft metal sculpture frames of various designs that were wrapped in lights. On some structures there was very basic programming, certain lights would turn off and on in a sequence to simulate movement, but the basic metal structure had a pre-defined shape. It got me thinking if it would be possible to build a cheap metal structure that's like 20ftx40ft LED wall using chinese WLEDS in a grid, using arduino etc. Basically a giant, cheap, low resolution, display. Anybody seen something like this this?
Like every video wall? You can buy LED panels like this from a ton of vendors. They’re frequently used for signage and concert effects, etc. infinite tiling and arbitrary shapes
It’s a very common project in the maker scene in general. Look up Bitluni on YT for some examples, he’s done full-wall sized ones in his house. Theres lots out there though, we’re working on a full-window one at my local hackerspace.
which implements space invaders on an LED display. The visuals are absolutely gorgeous but the machine at my local mall is set to be a ticket redemption machine which doesn't deliver enough gameplay per dollar to really seem fun.
That's very nice use of the tech though. It also makes me wonder if you could do some kind of 'bring your own screen' to a party where they will all join up to allow you to make an impromptu larger display. That would be a very neat trick.
> This is a problem, but not one that I can directly solve because the school mandates that they have both an Android smartphone and a Windows laptop.
That seems really weird, how does it work when the state mandates that a minor has to have access to proprietary software, from a TOS/user agreement point of view?
Not enough. Out of two classes of 30 kids I'm the only parent that doesn't agree with it. Pretty weird to be the 'luddite' when I've always been at the tech frontier.
It doesn’t seem that weird, if you are at the tech frontier you must know how bad most of it is.
This seems like a very odd situation. At least in the US, I’m under the impression that enforcing TOS and contracts against children is generally considered, if not impossible, at least riddled with with caveats because kids generally are not considered legally competent to sign contracts. I think (I could be wrong about this, though, layman here), that the parent is often considered “on the hook…,” but I really can’t imagine how that works in this case, where the school is making you let them agree to it. What a mess!
It will run off a battery for a bit but not for very long, the LEDs draw a fair bit of power, especially when you start lighting up a lot of them. To protect the circuitry and to run it directly off a USB port I reduced the brightness to a maximum of 16 out of 256, that seems to work fine but when all of the LEDs are illuminated you can sometimes see a bit of a ripple when it is on a small charger.
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.
Assuming you're not speaking in jest: I'm actually trying to figure out how to make these things much cheaper so I can give them away easier, but the LEDs put a base cost of about $70 for each display. So I'd need something cheaper and smaller that is not an LCD or I'd have to find a way to drive a small LCD in a similar way so that it simulates the LEDs, but that's going to ruin some of the ease of assembly and the ability to figure out how it all works. Suddenly the display would be 'magic'.
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.
Divoom makes some pretty nice hardware [1] using LED screens and at decent prices for retail. It’s a long shot but maybe you can figure out who their supplier is, or hit them up for a collab :)
Oh cool, I never even heard of them. That looks like it is quite a bit more dense than the ones that I'm using (these are at 10mm pitch, the Divoom displays look like at least half that maybe better still). Slick packaging too.
I used a cheap 'Sculpfun' 33W one (I doubt it's actually 33W but it will cut 18 mm softwood so it definitely has quite a bit of power). They're about $800 if you shop around a bit.
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.
That's really neat! I have all 1536 LEDs in a single string and that definitely is a limiter in terms of framerate but the resolution is so coarse that this hasn't been a problem (so far). But this driver takes it to a completely different level. Unfortunately the Pi Pico (which I would have liked to use) only does 3 A/D channels so that would have ruled out two player games with full x/y control. Fixing that and some other issues would require much more hardware work and I want it to be so simple that even a novice (motivated 12 year old) has a chance of putting it all together.
Connect the led strip data pin to an available Io pin on the pi, connect the strips and to pi gnd pin and to a 5V power supply gnd pin, and connect the strips + to the 5V power supply.
it just seems a shame there are so many projects like this where people spend so much time making it, but then run yet another pong or snake on it. there are a lot of cool game concepts you can do on a 40x48 RGB grid, as shown by some recent 8-bit releases. Check out pico-8 and tic-80 for examples too. Having a multiply or divide instruction available is game changing
I run 'pong' and 'snake' on it because they're recognizable and because they can teach kids what makes the games they already know tick on the inside. Of course you can make anything else on it as well, and my kids come up with all kinds of neat ideas all by themselves.
If you make any improvements I'd love to hear about them, soon I'll have a gitlab repository up with all of the code related parts as well as a schematic for the hardware (though it is so simple that if you just read the include file you'll know exactly how to hook it all up).
Best of luck with any re-creation efforts, if you run into trouble feel free to mail me (email in profile).