linie aus punkten zeichen?

Hallo Thomas

Schau mal in das Programm rein. Ist in C und enthält alle Routinen, die 
man für ein LCD braucht. Ist aber nicht von mir.
Im Internet findet man doch alle Routinen die man Braucht.

Die meisten werden nach Bressmann berechnet.

Hier noch ein Link

http://home.t-online.de/home/holger.klabunde/avr/avrboard.htm#GPSdisplay

http://www.indata.si/grega/index.html

MFG Dieter

@dieter: Danke in der ZIP-Datei war alles drin.

Beherrscht ein GrafikLCD keinen Linebefehl?

cu & thx tb

Hallo Thomas

Kommt halt auf den Chip an. Habe hier eine LCD mit KS 0108 Chip, der 
kann von Haus aus noch nichtmal normale Zeichen darstellen. Viele nehmen 
dann einen extra Chip vor dem Display, der sowas alles macht. z.B.: den 
High-Level-Grafikkontroller von.

http://www.lcd-module.de/deu/grafik/grafik.htm#Zubehör

MFG
Dieter

@dieter: sehe ich das richtig, ein standtart-garfik-lcd kann "nur" 
textmodus und einzelne pixel setzen/löschen?

zur lineroutine: zu früh gefreut, ich nutze Display's ohne eigenen RAM 
oder TV-Displays. Durch die HW-Konstruktion (lineare Adressierung) kann 
ich Punkte nur optimal von oben nach unten und links nach rechts 
setzten. Hat jemand zufällig eine daraufhin optimierte Variante?

cu

Hallo Thomas

Also wie gesagt. Den Chip den ich verwende ( KS 0108) kennt noch nicht 
mal einen "Textmodus". Alle Punkte eines Zeichen werden als Pixelmuster 
auf das Display geschrieben, daher auch die Zeichen Defintionen in 
Fonts.c. Andere Chip haben halt den "Textmodus" schon eingebaut, zum 
einfachen darstellen von Zeichen. Einen Standard Chip gibt es halt so 
nicht. Pixel setzen und löschen sollte eigentlich jedes Grafik Display 
beherrschen.

Schreib doch mal, welcher Chip auf deinem Display darauf ist und welche 
Auflösung dein Display hat.

MFG
Dieter

Hi Dieter:

Ich hab noch 2 NL3224AC35-01 Displays aus Bildtelefonen.
Die Teile haben eine Auflösung von 320x240 RGB analog.
Keinen Prozessor, keinen RAM -> nix.

Da es die Teile öfter billig bei Ebay gibt (so ca. 10 Euro)
ist es schon verlockend damit zu spielen. Da die Teile aber nicht ganz 
unkritisch im Timing sind übe ich an einen Mini-TFT-TV (Ansteuerung 
nicht unähnlich).

Bei mir muss halt der AVR alles managen.
Ich nutze einfach einen SRAM, den ich auf lineare Adressierung 
umgebastelt habe. Dadurch sind schnelle zugriffe nur von links nach 
rechts und oben nach unten möglich.

Um nicht jedesmal den AVR zu proggen simuliere ich das ganze unter 
Delphi (Software + Display).
Nur die Linien von rechts oben nach links unten spinnen noch, aber ich 
habs fast...

cu tb

... ein Bild dazu? ...

Um eine beliebige Line zeichnen zu können, mußt Du erst mal einen Punkt 
(Pixel) an eine beliebige Stelle setzen können.
Ich gehe mal davon aus, daß jedes Bit im RAM einem Punkt entspricht - 
dann entspricht dies einfachen Bit-Manipulationen.

@thkaiser: wie man auf den Bilder erkennen kann (oder auch nicht) bin 
ich über das pixelsetzen schon hinausgekommen...

Es geht lediglich um eine zeitliche Optimierung, da ich die 
Speicheradressen nur linear (1,2,3..99,100...) ansprechen kann, 
entspricht von recht nach links und oben nach unten.

cu tb

Hi Thomas!
Mir gefallen deine Spielereien mit der Graphik.
Mich würde nur interessieren wie du mit so wenig Bauteilen so eine 
relativ gute Graphik bekommst.(sieht man überhaupt alle Teile?!)
Vielleicht könntest du ja mal die Schaltung posten.

Oder es weiß jemand anderer wie man so ne Graphik hinbekommt.
Mir gehts in erster Linie um das gleichzeitige Beschreiben und Lesen des 
RAMs ohne das das Bild flackert.
Ich hab gelesen das man das bei den ersten Graphikkarten in den 
sync-Pausen gemacht hat. Erscheint mir aber relativ kurz!
Möchte mit einem normalen RAM und möglichst wenigen Bauteilen und einem 
MEGA163 eine einfache Graphikkarte aufbauen. (So wie in dem obigen Bild 
etwa)
Meine Ideen führen aber immer dazu das ich ne Menge Bauteile benötigen 
würde.

Besten Dank schon mal
Max

Eigene Grafikkarte bauen klingt interessant. Aber hat schon mal jemand 
versucht, eine ISA-VGA-Karte anzusteuern? Sozusagen nen eigenen 
1-Port-ISA-Bus zu bauen? Ist soetwas überhaupt mit einem Atmel machbar 
(>Leistung)?
Hat jemand da schon ein fertiges Projekt/Schaltung/Code? Denn alte 
ISA-VGA-Karten bekommt man ja recht billig (oder hat man noch in der 
Bastelkiste) und nen VGA-Monitor findet man mitlerweile auch fast 
überall, wo Strom ist.

wegen simplen grafikkarten solltet ihr mal nach 8bitrechnerprojekten 
suchen. da gibt es schon ein paar gute sachen, vielleicht ist was bei. 
(z1013, z80 rechner).
es gibt einige, die sich sowas selbst gebaut haben.

@thomas
welchen ram möchtest du beschreiben und lesen ohne bildstörung? 
"videoram"?

mfg

Ich möchte den Videoram lesen und beschreiben.
Mir ist nur nicht klar wie das ohne DualPort gehen kann, ohne das das 
Bild ausfällt. Wenn ich das RAM auslese bleibt mir zu wenig Zeit, um 
neue Daten reinzuschreiben.
Wie könnte das gehen??????????
Danke Max

Hi,

hab das Teil momentan auf Eis gelegt, kommt áber wieder wenn ich Zeit 
hab ...

Bildinhalte ändern ohne flackern geht momentan noch nicht,
ich denke aber möglich. (Indem man die Sync-Signale im Schreibzyklus vom 
AVR erzeugen lässt, und nebenbei den RAM beschreibt, es gibt auch noch 
andere Ansätze.

Ich mach noch mal ne Skizze zur Funktion,
Schaltplan und Quelltexte poste ich bei Bedarf ...

cu. tb

die Skizze, schnell noch mal rekonstruiert wie das
Prinzip funktioniert hat.
Nicht im Bild enthalten ist der Frequenzverdoppler,
der die Eingangsfrequenz des Zählers verdoppelt.
Ist auch nur ein stabiles überschwingen, das mir die doppelte Auflösung 
bringt :-)

Gut, man braucht also 1 Bit für reset, 2 für Sync. + Helligk., bleiben 
also noch 5 für Farbe, Datenlogger oder was immer man will :-)

Da die Hardware funktioniert (ja man sieht alle Bauteile), hab ich mir 
eine Simulation unter Delphi gebastelt, und programmier die. Das geht 
schneller, und wenn etwas nicht funktioniert sind Fehler einfacher zu 
beheben.
Die Umsetzng Delphi>Bascom ist auch sehr einfach.


Die Bildausgabe wird im Moment noch ausgeblendet, wärend der Bildinhalt 
sich ändert, um die Ausschaltzeit zu minimieren brauche ich die 
Linienroutine v.l.o.n.r.u.

Das sich diese Grafikkarte NICHT für Animationen eignet, sollte wohl 
klar sein. Das bedürfte etwas mehr Gehirnschmalz, ist aber ohne 
Hardwarestress mgl.

cu und viel Spass

Danke mal für die Erklärung.
Bin ich also richtig gelegen, dass das beschreiben und lesen nicht so 
toll funkt wies aussieht (Auflösung sieht echt gut aus). Mit zwei RAMs 
die man abwechselnd beschreibt und liest sowie einem CPLD der das ganze 
steuert und adressiert müsste man doch eine flüssige Darstellung 
bekommen.

@Max:
beim schreiben -> kein Bild, sondern schawarz (für 1 Halbbild)

beim lesen -> wie man sieht ist nix zwischen den Datenleitungen und dem 
Videoausgang, warum sollte das Bild also unstabil sein???? Das Bild 
steht astrein, ohne jegliche Störungen ...

einziges Problem (um ohne Dunkeltastung zu schreiben) ist das Timing der 
Syncsignale ...
oder einen zweiten RAM und nix weiter, warum immer unnötig Bauteile 
verbraten???
es gibt wohl auch einen 8535 (als Mega) der 16MHz kann, damit könnte man 
in der Austastlücke noch einiges mehr machen (ohne das das Bild 
flackert).
Ein vernünftiges (flackerfrei und stabil) Videosignal bekommt man im 
übrigen ohne Probleme mit einen AVR@4MHz und zwei Widerständen hin, ich 
hab mal angefangen ein "PONG @ AVR" zu basteln und bin dabei auf die 
Idee mit der GraKa gekommen,
um bei unterschiedlichen Displays nicht alles neu machen zu müssen.

Ich code fast ausschließlich mit BASCOM (und Delphi zur Sim.),
und hab damit beste Erfahrungen gemacht, obwohl es hier nicht den besten 
Ruf hat.

cu tb

Also beim Lesen ist mir klar, dass das Bild ok ist.
Wenn ich nun kontinuierlich Schreiben und lesen will (bewegte Grafik wie 
bei Pong) dann wird das Bild sicherlich flackern. Da man ja relativ oft 
schreiben muss, wenn sich viel bewegt.

Mit 2 RAMs könnte man trotzdem ein flüssiges Bild mit einem langsamen µC 
und viel Grafik hinkriegen. Nur würde sich halt die Grafik langsamer 
bewegen, da der eine RAM solange gelesen wird bis der zweite das neue 
Bildchen drinnen hat. Dann wird umgeschalten auf RAM2 und im ersten 
Lesevorgang das ganze auf RAM1 kopiert als auch gleichzeitig 
dargestellt. Dann kann man RAM2 solange lesen bis das Bild für RAM1 
fertiggerechnet ist. Und so weiter...
Das Ganze soll von einem megaAVR, einem CPLD von Lattice 
(ispLSI1000/2000), 2 Rams und etwas Kleinzeug realisiert werden.
Sollte jemand Zweifel oder bessere Vorschläge, ich bin an allem 
interessiert.
Wenn ich was Zusammenbring werd ichs da veröffentlichen.
Hab zwar erst mit den CPLDs angefangen, bin mir aber sicher das es damit 
super funken wird.

Max

Ich hatte mir mal etwas überlegt:
Ein Dual Port DRAM aus einer Grafikkarte:
Dieser ist 256k x 4 groß und hat sowohl einen normalen DRAM Anschluß 
(zum uC) und einen seriellen Anschluß, über den man Sektorenweise (z.B: 
512Werte) seriell auslesen kann -> Optimal für Displays.
Der uC muss nur die neuen Werte ins DRAM schreiben, ab und zu Refreshs 
durchführen, und neue Werte ins seriell Register laden. Fertig ist die 
Grafikkarte. Ein kleiner AVR dient als Controller, und emfängt die Daten 
vom normalen uC und verarbeitet diese.

Damit kann man allerdings nicht nur SW sondern auch Farbbilder 
erstellen: Ein RAMDAC aus einer Grafikkarte dran (enthält Farbtabelle 
für 256 Farben, und 3x DA Wandler mit Leitungstreiber).

Zur Ursprünglichen Frage (Wie senden man einfach Liniendaten von rechts 
unten nach links oben ?):
Lösung: Ein großes RAM am uC mit parallelem Adressbus, in dem das Bild 
aufgebaut und berechnet wird. Jede x. Frame wird der Inhalt in das 
Bildausgabe RAM geschrieben.
Da ein LCD etwa 60 fps hat, würde eine Reduzierung um 6 fps nicht weiter 
auffallen: Jedes 10. Bild wird für solch einen Datentransfer verwendet.

@Max: bei PONG verwendete ich gar kein RAM, sondern erzeugte die Signale 
in realtime (mit 4MHz).
wenn Du das schreiben ohne dunkeltastung realisieren möchtest brauchst 
Du nur ein zweites RAM und 7 UND-Gatter zur Steuerung!!!
Viel Spaß beim basteln.
Wenn ich mal wieder etwas Luft hab, versuche ich mal die Gameboycam 
anzuschließen.

@Benno: dich versteh ich leider gar nicht!

> RAMDAC aus einer Grafikkarte dran
? wofür??? das sind nur Widerstände!!!

> enthält Farbtabelle für 256 Farben,
ganz sicher!!! Farbtabelle und dann noch 256 Farben
aus 4 Bit, ich mag zwar Gags, aber nur mit Sinn

> und 3x DA Wandler mit Leitungstreiber
für was denn das jetzt schon wieder???
Videosignal war doch was bei 1 Volt oder?

Ich hab 512k*8Bit, 1 für reset, 1 für sync., bleiben 6 mit denen ich 
machen kann was ich will. z.b. R,G,B,h1,h2 ->
das gibt dann so 32 Farben (mit sync. 48??)

Die Antwort zur ursprünglichen Frage hab ich gar nicht verstanden!!! Wie 
kann ich Deinen Vorschlag in eine ASM-Routine packen???

Generell gilt doch: was ich programmieren kann muss ich nicht löten, 
oder?

Der Unterschied:
Mit dem RAMDAC hat man 256 Farben.
Allerdings ist es etwas umfangreicher an Hardware.
Ein 256k x 4 Dual Port RAM für LCDs (haben meistens 4bit Dateneingang) 
oder 2x 256k x 4 für die 256 Farben RGB Version.
H und V Sync müsste der uC, der sowiso nur für die Grafik zuständig ist 
erledigen.

Das RAMDAC IC enthält nicht nur Widerstände, sondern ein komplettes 3x 
6bit x 256 SRAM.
Man sendet ein Byte an den RAMDAC, der schaut nach welcher RGB Wert (3x 
6bit) dem Byte zugeordnet ist, und sendet diesen an den internen DAC. 
Deshalb heißt das Teil auch RAM-DAC.

Versteh ich immer noch nicht.
> RAMDAC IC enthält ... 3x 6bit x 256 SRAM
ein 4608 Bit SRAM? für was ist das? eine Videozeile?

> Man sendet ein Byte an den RAMDAC, der schaut nach welcher RGB Wert (3x 6bit) 
dem Byte zugeordnet ist, und sendet diesen an den internen DAC

ich lege Variablen mit Farbnamen an, weise denen den Leitungswert zu und 
arbeite damit:

rot=4 grün=2 blau=1; h1=8 h2=16
weis = rot + grün + blau
hellgrün = grün + h1  ... usw.

Ich sehe keine Notwendigkeit zusätzliche Hardware zu implementieren, 
bzw. verspreche mir keinen Vorteil davon.

cu tb