Hallo an alle älteren Forenbesucher,
vielleicht gibt es ja noch jemanden, der sich mit dem Thema auskennt.
Mich würde mal dringend interessieren, wie man ein CRT/Light Pen System
durch einen LCD Touchscreen ersetzen kann.
Mich interessiert erst mal nur die nackte Theorie.
Meine Idee bis jetzt:
Die Framebuffer-Karte misst ja offenbar die Zeit die der
Elektronenstrahl braucht bis er am Light Pen angekommen ist.
Ich vermute mal vom Zeitpunkt des H-Sync des Monitors an.
Wenn ich also eine kleine MicroIntelligenz habe, die die Koordinaten des
Touchscreens ausliest und auf das H-Sync Signal des Monitors wartet, um
dann einen den Koordinaten entsprechenden Zeitraum zu warten um dann ein
Signal an die Light Pen Logik abzusetzen ... puuuhhh ... komme ich der
Sache damit auf den Grund?
Inputs welcome :-)
Frickolino
Frickolino schrieb:> Wenn ich also eine kleine MicroIntelligenz habe, die die Koordinaten des> Touchscreens ausliest und auf das H-Sync Signal des Monitors wartet, um> dann einen den Koordinaten entsprechenden Zeitraum zu warten um dann ein> Signal an die Light Pen Logik abzusetzen ... puuuhhh ... komme ich der> Sache damit auf den Grund?
Genau das ist die Vorgehensweise. Allerdings brauchst Du auch noch
V-Sync, um die Bildzeile zu bestimmen.
Die Wartezeit nach dem H-Sync-Signal ist vom Pixeltakt abhängig, der bei
EGA glücklicherweise feststehend ist; EGA verwendet bei 640x350/60Hz
einen Pixeltakt von 16.257 MHz und eine Zeilenfrequenz von 21.8 kHz;
eine Zeile ist also inklusive Austastlücke etwa 746 Pixel "lang".
Entsprechend ist das Bild inklusive vertikaler Austastlücke 363 Pixel
hoch.
Mit einem µC müsste das hinzubekommen sein. Die SPI-Schnittstelle wird
mit 16.257 MHz angesteuert, dabei werden kontinuierlich Daten in die
SPI-Schnittstelle eingefüllt (das mit etwas über 2 MByte/sec).
Diese Daten sind immer Nullen, außer bei Erreichen der gewünschten
Position.
Das dürfte durch zwei Pufferbereiche à 94 Byte umsetzbar sein, der eine
bleibt komplett auf Null gesetzt, in den zweiten wird im gewünschten
Byte an der gewünschten Bitposition eine 1 eingetragen.
In der Zeilenschleife wird in Abhängigkeit von der aktuellen
Zeilenposition entweder die Leerzeile oder die Zielzeile ausgegeben.
Die SPI-Datenleitung wird mit dem "Lichtgriffel"-Eingang des Altsystemes
verbunden. Mit einem Monoflop kann die Impulsdauer soweit verlängert
werden, daß die Lichtgriffelmimik auch zuverlässig triggert.
Hallo Rufus,
sauber! Das sind ja mal ne Menge Infos. Danke schonmal dafür.
Hmm - irgendwie kann ich Dir aber noch nicht ganz folgen.
Ich dachte eher dass das V-Sync Signal ja ganz oben links triggert und
ich dann eine definierte Zeit abwarte um den LightPen zu simulieren.
Ich glaube ein Bild lag so bei 16ms. Wenn also der Touchscreen mitten im
Bild berührt wird, dann würde ich nach 8 ms dem Framebuffer vorgaukeln
er hätte einen LightPen gesehen. Das Ganze natürlich in "genau".
Würde dann also mit nem Oszi ermitteln, welche Zeitdifferenz zwischen
Sync und LightPen Puls bei welcher Position entsteht.
Dann mit nem AVR einen Touchscreen digital auslesen und Koordinaten in
Delay umsetzen um dann den virtuellen Lightpen zu triggern.
Wat meenste? Bin ich in der richtigen Spur?
Auch Dein Bildschirm ist zweidimensional. Dein Touchscreen gibt eine
X- und eine Y-Koordinate von sich, und der Lightpenlogik willst Du diese
auch übermitteln. Also musst Du, beginnend mit einem V-Sync-Impuls erst
mal die Zeilen zählen, bis Du zur Y-Koordinate gelangst. Beginnend mit
dem H-Sync-Impuls für diese Zeile musst Du nun die Pixel zählen, bis Du
zur X-Koordinate kommst.
Wenn Du den exakten Pixeltakt der Graphikhardware zur Verfügung stehen
hättest, dann könntest Du natürlich auch den Pixeltakt beginnend mit
V-Sync zählen und ausrechnen, wann der virtuelle Elektronenstrahl an
Deiner Koordinate vorbeikommt.
Ich denke aber, daß Du durch Auszählen von Bildzeilen die vertikale
Positionierung und darauf aufbauend die horizontale Positionierung
präziser hinbekommst - die vertikale ist exakt, die horizontale ist dann
nur so inexakt wie die Abweichung zwischen Deinem eigenen Referenztakt
und dem angenommenen Pixeltakt.
Vielen Dank für Deine Geduld.
Das leuchtet mir soweit ein.
Gibt es denn variable Frequenzen?
Ich denke doch nicht.
Der Multisync Monitor der momentan dranhängt zeigt fH=30.6kHz und
fV=59.0Hz.
Wenn ich also mal davon ausgehe, dass der Touchscreen mittig gedrückt
würde, dann wäre dass doch übersetzt die 350/2 te Zeile auf dem CRT
(Austastlücken unberücksichtigt). Bei einer angenommenen Zeilendauer von
32 uS wäre es dann nicht rein rechnerisch 350/2-1 Zeilen * 32 uS + 32/2
uS (die halbe Zeile) nach der V-Sync Flanke?
Jetzt bin ich gespannt ...
Die alte Lightpen Hardware latchte mittels des Lichtpulses mehr oder
weniger einfach die Adresse des Videoram der Grafikkarte, deswegen wurde
der Lightpen auch direkt an die Karte angeschlossen. Die Latches wurden
dann mittels Software gelesen und wieder zu XY umgerechnet.
Frickolino schrieb:> Wenn ich also mal davon ausgehe
Kannst Du machen, aber das wird schlichtweg zu ungenau sein. Da Du aber
sowieso einen µC verwenden solltest, kannst Du das ja einfach
ausprobieren, erstmal mit "Deinem" Verfahren, und wenn das nicht reicht,
mit den Vorschlägen von mir optimieren.
Viel Erfolg dabei.
@ Rufus,
ich verstehe was Du meinst.
Bei einer Verweildauer von nur wenigen uS pro Zeile kann es leicht um
ein oder mehrere Pixel kippen.
Wie Du ja schon bemerkt hast bekommt man die Zeile mit dem x-ten H-Sync
leicht getriggert. Die Position innerhalb der Zeile bleibt ohne
Pixeltakt in jedem Fall schwer zu erzielen.
Das Ganze "stinkt" schwer nach zeitkritischer Assemblerprogrammierung.
Hast Du eventuell noch detailliertere Informationen zum EGA Timing?
Ich hab mir schon die Finger wund gesucht und immer nur VGA Geraffel
gefunden.
Wenn ich wüsste wie klein die Auflösung sein muss könnte ich schonmal
testen, ob ich das mit dem uC überhaupt so genau hinbekomme.
Frickolino schrieb:> Hast Du eventuell noch detailliertere Informationen zum EGA Timing?
Die Angaben, die ich gemacht habe, sollten ausreichen.
Die von Deinem Monitor angezeigten Werte widersprechen dem allerdings;
EGA hat keine 30 kHz Zeilenfrequenz.
Bist Du Dir sicher, daß das 'ne EGA-Karte ist?
Von den 30kHz war ich auch verwirrt.
Es handelt sich um einen proprietären VME Grafikprozessor aus den 80ern.
Hab dann doch noch zwei Zeilen dazu im Netz gefunden und es scheint
tatsächlich eine VGA/XVGA Karte zu sein.
Macht die Angelegenheit durch die höhere Frequenz nicht wirklich
einfacher.
Am Ausgang sitzt ein Bt471 RAMDAC.
Dessen Clock müsste eigentlich die Pixelfrequenz darstellen.
Würde es reichen die Pixelfrequenz zu kennen, oder brauche ich sie immer
um einen Zähler zu bedienen?
Ich könnte auf der Karte durchaus messen, aber dauerhaft anzapfen möchte
ich sie nicht. Die Dinger kann man mit Gold aufwiegen, so selten sind
die geworden. Da möchte ich kein Risiko eingehen ...
Frickolino schrieb:> Dessen Clock müsste eigentlich die Pixelfrequenz darstellen.> Würde es reichen die Pixelfrequenz zu kennen, oder brauche ich sie immer> um einen Zähler zu bedienen?
Zwar wäre es präziser, wenn Du sie direkt verwenden würdest, wenn Du
aber den Hsync-Impuls auswertest, um den Zeilenanfang zu bestimmen,
dürfte die "Missweisung" durch einen eigenen Pixeltakt nicht kritisch
werden.
Allerdings ist der Pixeltakt bei VGA so hoch, daß die angesprochene
Microcontrollerlösung nicht umsetzbar sein dürfte.
Ich nochmal:
Hab's gerade nochmal weitergedacht.
Mal angenommen der Pixeltakt wäre 25 MHz (was dem Oszillator neben dem
RAMDAC Chip entspricht).
Wenn ich jetzt einen 32 Bit Zählerbaustein mit Comparefunktion hätte
(z.B. den LS7366R) und einen eigenen 25MHz Oszillator, dann müsste der
AVR quasi nur die XY Koordinaten des Touchscreens auslesen, die
Koordinaten in den gepixelten Timerwert umwandeln und in den Timer
laden.
Der Timer würde dann vom V-Sync gestartet und bekommt die Clock vom
Oszillator und im Compare Fall löst er das virtuelle Light Pen Signal
aus.
Das bißchen Arbeit kann dann sogar noch ein Tiny bewältigen.
Das sollte doch ziemlich genau werden, oder?
Nachtrag:
ich bin voll mit Dir d'accord, dass der H-Sync der richtige Weg ist.
Das Problem sehe ich in der Zeile selbst. Hier bedeuten 100ns
Unterschied schon fast mehrere Millimeter. Und hier habe ich nichts mehr
zum syncen ...
Frickolino schrieb:> Hier bedeuten 100ns> Unterschied schon fast mehrere Millimeter.
Ja, aber die Abweichung zwischen dem "Original-Pixeltakt" und dem
nachgebildeten wird nicht so groß sein, daß Du 100ns Versatz hinbekommen
wirst.
Du musst natürlich eine "Trimmfunktion" in Dein Konstrukt einbauen, mit
der Du horizontalen und vertikalen Versatz des nachgebildeten
"Lichtgriffels" kompensieren kannst, das brauchst Du schon, um die
Austastlücken zu kompensieren.
Poste doch mal ein Bild der VME-Bus-Graphikkarte, mit der Du Dich da
beschäftigtst.
Trimmfunktion ist sowieso Pflicht.
Dem VGA Standard entnehme ich einen Pixeltakt von 20.125 MHz - das haut
schonmal hin.
Eben mit dem Oszi gemessen:
34us high Level und 2us low Level auf dem HSync.
Sollten eigentlich 32us H und 4us L sein ... hmmm ...
18ms H und ~0.1 ms L auf dem VSync.
Kommt in etwa hin.
Also -> VGA 640x480
Die GraKa ist absolut proprietär und offenbar für den OEM designed
worden.
Kein Industriestandard - keine Datenblätter.
Dual Display - Dual Lightpen - 100% Blackbox
http://www.fdtgb.co.uk/graphics.htm
Apropos Austastlücken: Sind die nicht auch standardisiert?
ich bräuchte ja eigentlich nur die Obere und die Linke.
Frickolino schrieb:> Dem VGA Standard entnehme ich einen Pixeltakt von 20.125 MHz - das haut> schonmal hin.
25.125 MHz. Typo?
Graphikhardware mit HD63484. Fand' ich auch mal schick, wollte mir damit
was basteln, dann aber ist irgendwas dazwischengekommen, und das Projekt
kam nie über die drüber-nachdenk-Phase hinaus.
Frickolino schrieb:> Apropos Austastlücken: Sind die nicht auch standardisiert?
Naja, sehr theoretisch schon, aber in der Praxis nicht unbedingt. Ist
schließlich keine echte VGA-Karte mit VGA-BIOS, die wegen identischer
Hardware das Timing des IBM-Originals einhält.
Mach das adaptierbar und gut ist.
Jepp Typo - 20,125 MHz
Und Du hast schon wieder Recht. Kein IBM VGA - kein Standard :-)
Bleibt das letzte echte Problem: Der LS7366R
Das Teil gibts schon ne Weile nicht mehr bei Farnell.
Gibt es denn Alternativen dazu?
Also programmierbare externe 32 Bit Counter für 20MHz?
Bin nicht erpicht auf CPLD und uC Programmierung für diese Anwendung.
Dafür bin ich zu doof. Ein normales C-Programm krieg ich hin, aber
nichts suuuper zeitkritisches in Assembler ...
Es sollte programmierbar sein und ohne ein weiteres Studium
funktionieren.
In meinem Fall also mit einem Pixelwert vorgeladen werden triggerbar
sein und beim Match einen I/O Pin schalten.
Eigentlich alles so, wie im uC Timer/Counter.
Ich mag aber nicht sowas programmieren müssen - rabähhhhh
Frickolino schrieb:> Apropos Austastlücken: Sind die nicht auch standardisiert?> ich bräuchte ja eigentlich nur die Obere und die Linke.
Hallo,
beim offiziellen Timing für 640x480 ist eine H-Zeile 800 Pixel lang (bei
25,175 MHz), von denen 640 angezeigt werden. Du brauchst also einen
Offest für vertikal; wenn du einfach durchzählst sind 800 Takte eine
Zeile, aber viel sicherer ist es den H-Impuls auszuwerten, und von da
gibt es nochmal einen Offset HSync->sichtbares Bild. Bei den alten
Röhrenmonitoren war ja alles analog, da kam es nicht so genau drauf an,
sondern da waren einfach Potis drin für V und H, mit denen man das Bild
zurechtschieben konnte. So ungefähr solltest du das auch lösen, 2
veränderliche Parameter sollten reichen, da du die einzelen Zeiten für
Front Porch, Sync Pulse Length usw. garnicht wissen musst. Da gibt es
oft Variationen, oft werden auch Oszillatoren mit 25 MHz statt 25.175
verwendet oder sogar 24 MHz. Soll es ganz präzise sein, greift man am
besten den Originalpixeltakt ab.
Gruss Reinhard
Hallo Reinhard,
danke für die Zusatzinformationen.
Ziemlich genau das habe ich mittlerweile auch bei Tobias' Arbeit
nachgelesen:
www.uni-koblenz.de/~physik/informatik/ECC/vga.pdf
Seite 7 ...
Bei meiner Graka sind es offenbar 25,000 MHz.
Ich bin sicher, dass die Grafikkarte noch einige Überraschungen birgt.
Frickolino schrieb:> Bei meiner Graka sind es offenbar 25,000 MHz.
Nun, miss das genaue Timing der Graphikhardware, also die Zeilen- und
Bildwechselfrequenz und baue Deinen Zählermechanismus darauf auf. Als
Hardware dürfte sich ein FPGA/CPLD vermutlich recht gut eignen, da das
deutlich weniger "Verdrahtungsaufwand" mit sich bringt als eine diskret
aus einzelnen 74xx-Logikbausteinen aufgebaute Variante.
Hab bereits beide Frequenzen mit nem HP Counter gemessen.
Leider hänge ich bei dem LS7366R Problem fest.
Auf eine schnellere CPU zu gehen macht - denke ich - keinen Sinn, da
diese ja > 40MHz laufen müsste und da sind wir bereits in dem für mich
unbekannten ARM Bereich.
Dann bleibt wohl nichts als das CPLD übrig.
Ich melde mich dann in einem oder zwei Jahren wieder, wenn ich VHDL
gelernt habe ...
Bis dahin geht es vermutlich darum die LCD's durch Hologramme zu
ersetzen :-)
Frickolino (CPLD Noob) schrieb:> Bis dahin geht es vermutlich darum die LCD's durch Hologramme zu> ersetzen :-)
Lightpen war gestern, Schubsen auf dem Display ist heute und Gesten im
freien Raum sind morgen - wird allerdings schon getestet.
Gruss Reinhard
