1. Ein Panel, das kleinste Element besteht aus einem Rechteck von 20×16 (BxH) Pixeln.
2. Eine Spalte besteht aus 11 Zeilen, also 11 Panels übereinander und 18? Spalten: 18×11 (BxH).

04:18 < x5444> pin 1 ist durchverbunden, kann man wohl am abschluss für nen rückkanal nutzen, so dass man die anzahl der segmente zählen kann
04:18 < x5444> pin 2 ist dateneingang für die zeilen (also die seite mit 20 pixeln)
04:18 < x5444> pin 3 ist die strobe
04:18 < x5444> pin 4 und 5 sind die OEs
04:19 < x5444> pin 6 ist takteingang für die spalten (also die seite mit 16 pixeln)
04:19 < x5444> pin 7 ist takt für die zeilen
04:19 < x5444> pin 8 ist daten für die spalten
04:20 < x5444> pin 9 ist der ausgang des zweiten nichtinvertierten schieberegisters für die spalten auf der input seite (dem flachband kabel), auf der buchse unbelegt
04:21 < x5444> pin 10 und 11 sind ein wenig komisch, die sind jeweils ein bestimmter pegel (hab ich grad nicht im kopf) sobald an einer der steuerplatinen in der kette die matrix die tatsächliche display-einheit verbunden ist
04:21 < x5444> pin 12 bis 20 ist ground

Man nimmt ein kleines FPGA, und etwas RAM(z.B. im FPGA enthalten) und hat einen Prozess,
der die Daten zu den Schieberegistern schreibt. Der Pin9 sollte zum Prueflesen benutzt werden.
Nun teilen wir den RAM in 2 Bildschirmspeicher ein:
Einer der Speicher wird angezeigt, und der andere kann geladen werden.
Ein Toggle-Bit im config-Register des FPGA schaltet zwischen Bildschirmspeicher und Vorbereitungs-
Speicher um. Bei Flankenwechsel des Speicherschalt-Bits wird der Update-Prozess ausgeloest.

Insgesamt kann man das Verhalten wie bei den grafikfaehigen Industrie-Displays LCD gestalten, sodass
man vorhandene Linux-Treiber fuer den Druckerport nutzen und anpassen kann.

Von der Ansteuerungsseite aus wird man z.B. 2 Addressen sehen, mit 8bit breiten Daten.
Addresse0 ist das Daten-Transferregister.
Adresse 1 ist config register:

Beschreibung:

Wenn error-flag gesetzt, bringt ein read vom
dataport den errorcode
wenn error-flag nicht gesetzt, bringt read vom
data port, den zuletzt mit addresse selektierten
ram_inhalt.

Man kann im Config-Register 2 Register unterbringen,
wenn Register nur lesbar oder nur schreibbar sind, wird
je nach richtung das Register selektiert.

Also haben wir eine Address-Select-Leitung
und eine 8-bit-Datenleitung fuer den hackerport

Bedeutung der Kommandos:
Config-Register:
Bit0 invert: invertiert den bildschirmspeicher. Zusammen mit Redraw zum Blinken und Oelverteilen /W 1=Invert
BIT1 redraw: Schiebt den Bildschirmspeicher raus bei jedem uebergang 0→1
BIT2 speed: 0=slow, 1=fast, Speed fuer schieberegister /W
BIT3 error_flag (irgend ein error ist da) /R error_clear /W
BIT4 ADDRESS_STROBE fuer Addresse_Highbyte wird aus Inhalt, der im Register an Addresse 0 liegt, gesetzt
BIT5 ADDRESS_STROBE fuer Communikations-Register an Addresse0 → Addresse_Lowbyte wird aus Inhalt, der im Register an Addresse 0 liegt, gesetzt
BIT6 DATA_STROBE fuer Communikations-Register an Addresse0 → Daten werden in zuvor selektierte Addresse
BIT7 TOGGLE_FRAMEBUFFER →1=Higher Buffer wird angezeigt, lower kann gefuellt, gelesen werden. /W
Redraw: entweder 3xToggeln Bit 7 oder Bit1 toggeln,
je nach Erfahrungen mit dem Schieberegisterkram.
Wir koennen auch den Redraw unabhaengig vom Buffer-Select BIT7
machen, sodass man mit Bufferselect ein Redraw befehlen muss, wenn man rausschreiben will.
So koennte man evtl. auch den Aktuellen Puffer manipulieren, um einen Blink-Cursor zu machen.
Intelligente Ansteuerung nach “Was hat sich geaendert” werden die Schieberigister nicht koennen oder?
Wenn ja koennte man die Elemente einzeln an das FPGA machen und so z.B. auch nur das sich geaenderte
Element updaten. I/Os haben FPGAs genug

Rambedarf ist Pixelzahl zweimal
Mein Vorschlag waere ein kleines automotive-fpga von actel.
Als Bildspeicher:
Wenn ichs richtig hab:
20*16*11*18
63360BIT*2
rund 128Kbit, also 16KBYTE RAM, ein paar Addressleitungen und 8 bit datenleitung zum
FPGA und fertig. Wird auf nen 1-Lager passen.
Als RAM ein altes CAcHE-SRAM vom 586er oder 486er Mainboard, denn SRAM ist zahm in der Ansteuerung,
kein Refresh und so zeugs. Address/Datenbus, r/W, da wars schon.

Asynchrones Reset und Clock versteht sich fuer das ganze Design von selbst.

Takt mit beliebigem Quarz z.B. 14.xxx MHZ aus Bastelkiste/ISACLK aus altem Mainboard.

Wegen altem Mainboard, frueher TM war IDE nur ein per Puffer und Addressdekoder rausgefuehrter ISA-BUS!
Und das Zeugs ist aufwaertskompatibel. Man koennte das FPGA-Ding als “Festplatte” an den IDE/ISA-Bus haengen,
denn IDE wird aehnlich addressiert:-)
ich waere dafuer, dass man die beiden 8-bit Register (Config und Data) zusaetzlich ueber SPI zugreifbar macht,
einen SPI-Core von opencores.org nimmt, und so das Teil an irgendeinen OpenWRT-Router drandengeln kann,
und so ein web-interface hat, wo man SW-BMPs hochladen kann.

Ob man jetzt per Parallel-Port oder SPI drauf geht ist egal. SPI waere aber schon cool wegen Router-Recycling.
Hab mal fuer ein MIL-Projekt SPI per LVDS angesteuert, ist sicher fuer einige Meter ok.
Vorteil der FPGA-Loesung ist, dass das SW-Timing voellig egal ist, denn das FPGA kuemmert sich um das Geschiebe und das Timing
Theoretisch koennte man durch das Prueflesen des Schieberegisters bis zur Geschwindigkeitsgrenze der HW gehen.
Ich wuerde aber sagen, dass 2MHZ schiebe-Clock genug sind. Wir nehmen z.B. besagten 14MHZ-Quarz oder sonst was ab 10MHZ,
und teilen uns den Clock wie wir ihn brauchen. Evtl, im Configregister noch ein Flag fuer FAST/slow shift haben
(z.B. 2MHZ vs 500kHz)

Das wars schon mal aufs erste.

luja