This resource could prove very helpful:
https://www.noisebridge.net/wiki/Big_LED_Screen
It describes the pinout going to the shift register and led drivers, which would be where a micro would be plugged in.
This resource could prove very helpful:
https://www.noisebridge.net/wiki/Big_LED_Screen
It describes the pinout going to the shift register and led drivers, which would be where a micro would be plugged in.
Yup. Shane posted that way up thread. Downside to that approach is that you
dont get brightness control.
Thereâs also an editor for creating your own animations, built into
the âmain programâ that runs the sign. Itâs one of the menu items,
IIRC. I think I put the instructions for using it on the floppy disk.
âŚbut I want wifi and serial
Further update, I realized (with Ashâs help) that I miss labeled a couple pins in terms of their connection to the ISA bus, I have updated the dropbox spread sheet.
Had a go at emulating things, the IOW line is pulled low for each transfer, clock seems to be more or less ignored, and the T/C line goes high for one pulse after each 32 byte transfer.
No luck on getting the sign to do anything though, I would be happier if it at least glitched out. As a door prize when testing sign starts up all pixels on so the the power supply makes a lovely loud high frequency whine thatâs probably going to put a notch in my hearing so it makes the whole process less fun.
So I am having a debate if I just bail on this line of attack and do what noisebridge did by going direct to the serial shift registers (and get brightness by switching off pixels every X refresh cycles). Iâm just trying to figure out how to do it without cutting any of the existing cables so it could still run off the 386 if need be.
Donât give up yet! I reckon youâre right on the edge of cracking it. I think you just need to emulate the bus and dma more accurately. Do you know definitively which dma req/ack lines are being us3d by the sign? Can you share the code youâve tried and which signals youâre emulating?
You are probally right, the timing is all over the map as I am using a mix of digital write and port write. With that said the stock config is also kinda over the map tooâŚ
I dropped the .ino in, cant remember where I left off, I was more or less throwing things at the wall by the end of the night:
https://www.dropbox.com/sh/akh9dg6hn3nxu5a/AAAA2MStSt5fEHw_Pivz0AQTa?dl=0
Have you tried adding a short delay between toggles in your clock1() function? If you want to delay less than 1ms, use delayMicroseconds() rather than delay(). Also, the digitalWriteFast library is much faster and just as easy to use as standard digitalWrite().
So update on this,
Ash and I had another crack at it last night. I managed to get step 1 working, when the correct string of 8F 0F 07 is sent in on the data lines (and the address lines are set correctly, and the AEN line strobes after each[I think]) the signâs logic board causes the DRQ1 line to pull high, requesting data from the DMA controller on the 386. This line stays high for the duration of the transfer and drops low if things arenât coming in correctly so itâs a good sanity check.
Problems I had to get that working included dead jumper wires, reversed byte order, timing issues etc.
Basically its like a combo lock and we got the first step open.
Step two, well aside from one blissful moment that I couldnât replicate, I am not getting stuff to the sign. The DMA transfer is a relatively straightforward thing and Ash made a handy set of notes for the sequence, tried them out but its not quite working yet. Updated code is in the dropbox might have another go this evening if I have any ideas.