Ist mit zweitem VRAM auf 8 Bit Breite (2x4b) ausbaufähig, dann ist auch
640x480 monochrom möglich.

Passendes VRAM gibt's bei Segor im Resteverkauf (64Kx4) oder Abverkauf
(256Kx4).

Programm dazu, nur monochrom. Nicht 100% getestet. Ein
Kommunikationsprotokoll über UART fehlt.

Ach ja: In der gezeigten Schaltung sind gegenüber der realisierten
Version und somit dem Code die Ports A und C und 2 Pins an Port D
vertauscht (=> config.h).

Deshalb hier die implementierte 8-Bit Version. Für 320x240 wird aber nur
eines der VRAMs benötigt.

Für die Spannungserzeugung vom LCD => Benedikt.

Oder so, wenn sowieso schon 12V zur Verfügung stehen, beispielsweise
weil der Inverter die braucht. Denn dann vereinfacht sich der Schaltung
etwas.

PS: Die 100nF Kerkos für VCC muss man sich dazudenken. Bei Schaltungen
für Lochraster lasse ich die im Plan der Einfachheit halber meist weg.

Hi Andreas,

auf die schnelle hab ich bei Segor nur VRams mit 60-70ns gefunden.
Oder hast Du mehr Info.

Wigbert

64Kx4:  ArtikelNr 41264-ZIP120, steht aber MB81461 drauf.
256Kx4: ArtikelNr 524258AZ-10.

Für letztere war nur ein japanisches Pinout und ein Datasheet vom
TC524258B aufzutreiben, aber das dürfte sich nicht signifikant
unterscheiden.

Die ZIP-Gehäuse sind netterweise ziemlich lochraster-
prototypenfreundlich, denn die Pins lassen sich problemlos so
zurechtbiegen, dass sie in Präzisionssockelleisten passen. Und
platzsparend sind sie zudem auch.

@Andreas Kaiser

hab die Dinger bei Segor gefunden, Preis ist erst mal OK.
Dank Dir.

Wigbert

Man kann das Gatter-IC auch einsparen, indem der Shift/LCD-Takt per
Software erzeugt wird. Dann allerdings, um Zeit zu sparen, vorzugsweise
mit maximalem Takt (8-10MHz), was zwar weit über dem offiziellen Takt
des Displays liegt, aber trotzdem problemlos funktioniert.

Bei der Erzeugung der Displayspannung ist hier der Anschluss eines
separaten Kontrastpotis vorgesehen. Ein Poti im Wandler ist dafür u.U.
nicht sonderlich praktisch, denn das sollte sehr dicht am Wandler
sitzen.

Als Controller ist so ziemlich jeder AVR ab 40 Pins und 16KB ROM
einsetzbar, also auch ATmega16/32 - insbesondere auch der ATmega162 mit
seinen 3 zusätzlichen Portpins.

Anzahl und Grösse der ins Programm integrierbaren Fonts ist natürlich
von der ROM-Kapazität begrenzt. Mit grossem 48x32-Font sind 64KB
erforderlich, für die 3 kleinen Fonts (8x6,10x8,12x8) reichen 16KB aus.

Dafür aktualisierte Programmversion.
Pinbelegung in config.h anpassen!

@Andreas Kaiser ,

mir sind ein paar VRams IBM025161LG5D-6H (256Kx16 5V < 60ns) vor die
Füsse gefallen. Würden die auch gehen? Die wären nun mal da.
Dank Dir mal schon.

Wigbert

Keine Ahnung. Hast du Daten gefunden? Ich nicht.

Wäre natürlich optimal für SVGA und kleinere TFTs, dann aber ist der
Pincount wegen schon ein Mega128 nötig.

hab das DBL da her:

http://www.datasheetarchive.com/I-5.htm

hab noch nie was mit V-Rams gemacht, deshalb meine Frage.

Wigbert

Spricht nichts dagegen, die sehen im Prinzip genauso aus wie die schon
erwähnten Typen, nur breiter. Zwar sind ein paar Pinbezeichnungen
anders, aber die üblichen Modi sind alle dabei und gleich gesteuert wie
bei den 64Kx4 und 256Kx4.

Ist zwar EDO statt FPM, aber das ist egal.

Da Byte-Enables vorhanden sind, könnten die sogar mit pinsparendem
8bit-Bus seitens des Controllers arbeiten. Wenn man die 16bit Breite für
SVGA/TFT braucht.

Wenn du die gesamte Kapazität brauchst, also auch A8, dann musst du halt
den Code etwas umstricken, denn in dem hier gezeigten Code sind nur 8
Adressbits drin und das macht den Zyklus etwas einfacher und schneller.

und die <60ns , wie klein auch immer..
wären schnell genug?

Wigbert

Keine Panik. Die von mir verwendeten Genossen sind -120er. ;-)

Bei diesen hier kannst du die einen oder anderen Brems-NOPs rauswerfen,
beispielsweise die im Refresh.

Dank Dir erst mal,

wird aus Zeitgründen mit dem Nachbau eine Weile dauern,
aber irgendwie wollen die Dinger auch eingebaut werden.

Wigbert

Jetzt mal ne Frage beim Benedikt GLCD Schaltung sollte der Speicher 15ns
sein also recht schnell, wieso schafft dann deiner der nur 120 ns hat
den Bildaufbau? ich glaube da habe ich was nicht verstanden :(

Bei Benedikt wird der Speicher als externes SRAM vom AVR selbst
angesteuert, daher gilt das Zeitverhalten eines externen SRAMs aus dem
AVR Datasheet. Ich weiss aber nicht, ob man da wirklich 15ns benötigt,
oder ob er einfach nur so ein Ding rumliegen hatte.

Bei mir wird das VRAM fast (SC per Timer) bis ganz (SC per Software) vom
AVR zu Fuss gesteuert, d.h. mit Pingewackel in Software. Was kein
Problem ist, weil man pro Zeile nur einen einzigen VRAM Transfer-Zyklus
(plus Refresh) benötigt, den Rest macht das VRAM per SC ja selber.

Lies dir mal durch was ein VRAM ist, dann wird's evtl. klarer.

Andreas Kaiser wrote:
> Bei Benedikt wird der Speicher als externes SRAM vom AVR selbst
> angesteuert, daher gilt das Zeitverhalten eines externen SRAMs aus dem
> AVR Datasheet. Ich weiss aber nicht, ob man da wirklich 15ns benötigt,
> oder ob er einfach nur so ein Ding rumliegen hatte.

Das Datenblatt schreibt eigentlich ein noch strengeres Timing vor. Es
gehen aber bis etwa 35ns, darüber gibt es Problem. Dies liegt daran,
dass bei 16MHz ein Takt nur 62,5ns lang sind und in dieser Zeit die
Daten auch noch eingelesen werden müssen.

Kann man dem AVR-Zyklus keine Waitstates angedeihen lassen? Oder wird
dann das Timing zu knapp?

Das kann man, allerdings wird das Timing dann von 3 Takten auf 4 Takte
pro Zugriff verlängert. Das reicht noch, aber man spürt es schon
deutlich.