Örülök, hogy segíthettem. :) Azért javasoltam az LS00-s megoldást inkább, mert ott még egy kapunyi idő kimarad az E kapuzásából, hiszen nem kell invertálni az E jelet.
Azt nem tudom, hogy eredetileg miért nem volt rossz bizonyos esetekben, de az biztos, hogy nagyon gondatlan tervezés eredménye ez, nem nagyon fektettek energiát abba, hogy ne nyissanak szembe a meghajtók, hogy rendben legyenek a setup és hold time-ok. Eléggé amatőrnek érzem a tervezést.
Ahogy elkezdtem nézni a kapcsolási rajzot, egyre világosabb lett, mi történik, s az is, mit rontottak el, ezért javasoltam azt, amit leírtam. A -S0 dekódolása sok szintű kombinációs hálózattal történik, minimum öt, ha jól számolom, aztán ott a multiplexer, az már hét szint. Ha a CPU az E jel megszűnésekor elveszi az érvényes adatot, az LS245-ön ez hamar átmegy, míg a VRAM-nak egy jódarabig aktív marad a -WR lába, annak megszűnése sokat késik. Ez viszont baj, mert az utolsó pillanatban még beíródhat az érvénytelen adat.
Az is fájdalmas, hogy míg a karakterek címzése a CPU gépi ciklusaihoz van szinkronizálva, addig a shift regiszter léptetése, azaz a karakteren belüli pontszélesség egy szabadon futó, trimmer potméterrel állítható RC oszcillátorra lett bízva, amit valamelyest hozzászinkronizálnak a karakter elejéhez, tehát a LOAD jelhez. Vagy a LOAD jel előállításában az az RC-tag is szörnyű látvány.
Mondom, manapság egy PIC32MZ sorozatú MCU SPI interface-ével, egy DMA kontrollerével és talán három timer-ével, meg mondjuk két PWM moduljával alig néhány passzív alkatrész felhasználásával meg lehetne ezt úgy csinálni, hogy a CPU futásidejének elenyésző részét vinné el a display kezelés, majdnem az egész, 200 MHz-es, 32 bites MIPS core megmaradna az érdemi feladatra, amibe lehetne BASIC interpretert írni, vagy akármit. Mindenféle varázslatos RC-tag, trimmer potenciométer, és egyéb ráolvasás nélkül.