Újraépítettem az áramkört egy nagyobb panelon, és jobb vezetékekkel. Így áttekinthetőbb lett, a forrasztások is stabilak és a vezetékek sem olvadtak meg.
A végeredmény - majdnem - ugyanaz. A kép elsőre megjelent és stabil, arduinoval meghajtva az egyforma karakterek gyönyörűen olvashatók, azonban a különböző karakterek összefolytak, zagyván szemeteltek. Mindent többször ellenőrizve arra jutottam, hogy ez nem forrasztási vagy kábelezési hiba.
Az eredeti áramkör 2716-os EPROM-mal készült, ehelyett azonban AT28C16-os EEPROM-ot használtam. Az adatlapok szerint az EPROM válaszideje 450ns, míg az EEPROM-é 150ns. Mivel úgy tűnt, a szemetelés az adott karakterpozícióban a következő karakter kódjától függ, egyre nagyobb lett a gyanúm, hogy a baj az, hogy gyorsabb az EEPROM, mint az EPROM.
Pontosan ugyan nem értettem, mi történik, de arra jutottam hogy, az R508-C501 - ami a shift regiszter LOAD jelét késlelteti - értékeik nem jók az EEPROM sebességéhez.
Az R508 helyére betettem egy potmétert, amit tekergetve végül gyönyörűen stabil, és helyes képet kaptam, amin már minden pozícióban tetszőleges karakter is megjelenhet, nem zavarják egymást. Az R508 értéke most 135 ohm az eredeti 270 helyett.
Megpróbáltam megérteni, mi is történt, de nem áll össze a kép. Ha az R[0-14] buszon 0 van, az jelenti a bal felső sarkot. Ekkor a RAM 0. bájtján lévő karakterkód megcímzi az karaktergenerátort, aminek az adatvezetékein eredetileg kb. 500ns múlva megjelenik a karakter első sorának 8 (azaz 6) pixele.
Valamikor ekkor már jönnie kellene a LOAD jelnek, és már így is csak 500ns marad, hogy ez a 6 pixel kikerülhessen a képernyőre, mert azután már jön a következő karakter. De ha a 450ns azt is jelenti, hogy 400-nál nem kevesebb, akkor van összesen 900ns a pixelek megjelenítésére. Ez azt is jelenti, hogy a képernyőn megjelenő pixelek 500ns eltolással kerülnek ki, valamint a képszinkron eleje is 500ns-mal hosszabb.
Ha ez valahogy így is lenne, akkor a gyorsabb EEPROM-ból 450ns helyett 150ns alatt érkező válasz 300ns-mal hamarabb kerül a shift regiszter bemenetére ... De a shift regiszter legrosszabb esetben is kb 750ns időt tölt a pixelek kitolásával, azaz a 0.3ns-os válaszidőcsökkenés nem kellene, hogy megzavarja ...
És itt elveszítettem a fonalat. Nagy vonalakban úgy tűnik, mintha érthető lenne, mi történik, de konkrétan mégsem áll össze a kép...