TI Voyage 200 Taschenrechner

Displayreparatur

Beim Voyage 200 von Texas Instruments handelt es sich um einen programmierbaren graphischen Taschenrechner. Er kam 2002 als Nachfolger des TI-92 auf den Markt. Der Rechner hat ein CAS (Computeralgebrasystem) integriert, wodurch er auch rein symbolisch arbeiten kann.
Drinnen arbeitet ein MC68000, was mir natürlich besonders gefällt.

Mein erster Rechner in der Unterstufe war ein TI 30 eco RS und in der HTL kam dann ein TI 36XII. Mit dem arbeite ich seitdem. Gerade im Fach Elektrotechnik war die Editierbarkeit der Ausdrücke ein großer Vorteil gegenüber dem TI 30, weil man in der komplexen Wechselstromrechnung sehr oft den gleichen Ausdruck sowohl mit sin als auch mit cos rechnen muss. Diejenigen die noch einen einfacheren Rechner damals hatten, kamen bei den Tests oft in zeitliche Bedrängnis während man z.B. mit dem 36er einige Geschwindigkeitsvorteile hatte. In letzter Zeit habe ich mal überlegt, ob nicht ein leistungsstärkerer Rechner etwas für mich wäre, aber so richtig angelacht hat mich keiner. Bei einem Funkerkollegen habe ich mir einen aktuellen graphischen Rechner mit Farbdisplay anschauen können, aber das Teil gefiel mir irgendwie nicht so und der Preis war nur zum mal "spielen" auch zu hoch.

Da traf es sich ganz gut, dass ich ein paar Tage drauf mit einem anderen Funkerkollegen beim Mittagessen saß und wir uns über Taschenrechner unterhielten. Da meinte er, seine Freundin hat noch einen Voyage 200 der ein neues Zuhause sucht. Da war ich natürlich sofort dabei. Sie haben ihn vorher dann noch getestet, doch da zuckte nur kurz der Bildschirm und dann war Ruhe. Wir dachten zuerst, dass vielleicht die Pufferbatterie leer ist und die Kiste nur einen Reset braucht. Ich hab ihn also mitgenommen dann im Labor untersucht. Allerdings konnte ich ihn nicht zum Reden bringen. Als nächstes habe ich dann mal auf dem Bus des 68000 herumgemessen und bemerkte, dass die CPU läuft und auch bei jedem Tastendruck aufwacht. Sogar die Verbindung zum PC mit dem Interfacekabel hat funktioniert. Es arbeitete also nur der Teil nicht, der für das Display zuständig ist. Rechts unten befindet sich ein ASIC von TI (der quadratische), der einzige Chip der nicht von der Stange ist. In dem ist offenbar der ganze Peripheriekram integriert, unter anderem der VRAM und die Refreshlogik für das Display.
Als Display kommt ein LCD mit 240x128 Pixel zum Einsatz. Es ist leider mit diesen dünnen Folienleitern direkt auf die Platine montiert (sieht aus als wären sie mit ihren Enden heiß auf die Leiterbahnen gepresst). Dieser Umstand wird später noch eine Rolle spielen, aber der Reihe nach.
Ich konnte durch ein paar Messungen ermitteln, dass die LCD Treiber (Toshiba T6B07 und T6B08) keine Steuerdaten vom ASIC bekamen. Damit war die Aussicht auf eine Reparatur scheinbar mit einem Schlag beendet. Jetzt fuchste mich das Ganze aber. Wenn ich vor einem 35kg schweren Messgerät von HP kapitulieren muss weil irgend so ein absolut unreparierbares Dünnschichtmodul für 26GHz den Geist aufgibt, sehe ich das ein. Aber von einem Taschenrechner lass ich mir keine lange Nase drehen! Ich schaute also bei einer bekannten Seite nach, ob jemand aus meiner Umgebung so ein Teil verkauft und ich wurde fündig. Der Preis war auch absolut human, selbst wenn ich ihn nur zum Ausprobieren haben wollte und er dann im Regal landen würde. Kurz bevor ich zu dem Verkäufer aufbrechen wollte, rief er mich an und sagte mir, dass er den Rechner gerade noch ausprobiert hatte und der jetzt etliche vertikale Streifen auf dem Display hatte. Es war natürlich die bekannte Krankheit dieser Serie, weil da offenbar nach all den Jahren die Folienleiter Kontaktprobleme bekommen. Schade, wär ein gutes Angebot gewesen. Doch während des Telefonats fiel mir ein, dass ich aus diesem Rechner ja den benötigten ASIC ausbauen könnte und ich hab ihn sofort abgeholt und den Chip getauscht. Erstmal war die Freude groß, denn der Rechner lief mit dem neuen ASIC. Aber auch er hatte bereits eine Linie am Display und zeitweise entstanden auch noch weitere und das trübte das den Gesamteindruck doch etwas, zumal davon auszugehen ist, dass mit der Zeit immer mehr solcher Streifen erscheinen (was sich in den nächsten Tagen auch bewahrheitet hat).

Bis zu dieser Stelle kann man die bereits erfolgten Arbeiten noch als zum Reich der Vernunft gehörig ansehen, aber wie es oft so ist mit Leuten die quasi ihr ganzes Leben einem bestimmten Fachgebiet verschrieben haben, verlassen wir hiermit diesen Bereich.

Eigentlich muss man sagen, dass man einen >14 Jahre alten Rechner, bei dem man noch zusehen kann wie er einen Sinus aufs Display pinselt, getrost in die Tonne werfen könnte und sich am besten einen modernen kauft. Aber irgendwie widerstrebt mir das und es juckte mich einfach, ob ich die Kiste wieder flott bekommen könnte. Was danach kam, war eine reine Spielerei ohne wirtschaftlichen Nutzen. Wenn ich zurückdenke, kam allerdings ein großer Anteil meiner Erfahrung von genau solchen Aktionen.
Ich plante also, die Daten die aus dem ASIC in Richtung Displaytreiber gehen, mithilfe eines Mikrocontrollers auf ein anderes Display umzuleiten. Also musste ein geeignetes Display gefunden werden. Das DOGXL240-7 von Electronic Assembly passte sowohl von der Auflösung als auch den Abmessungen in das Gehäuse. Zumindest nach meinen Messungen. Eventuell müssen oben und unten ein paar Zehntel ausgefräst werden, aber das stellt ja kein Problem dar.
Nun musste ein Weg gefunden werden, um die Displaydaten in den Controller zu bekommen. Der Toshiba IC bekommt vom ASIC die Daten mit jeweils 4 Bit parallel und einem Clock von ~700kHz. Bei einer Anzahl von 240 Spalten braucht der Spaltentreiber also 60 Clocks wo er jeweils 4 Bit übernimmt, um eine komplette Zeile zu erhalten. Danach wird der Zeilentreiber um eine Zeile weitergeschaltet und das Spiel beginnt von neuem. Es mussten also die Nibbles mit einer vergleichweise hohen Frequenz in den RAM vom Controller geladen werden. Dafür bot sich DMA an. Üblicherweise verwende ich die 8-bit AVR Controller, aber die haben keinen DMA. Ihre etwas mächtigeren Familienmitglieder, die XMega Serie, hat aber sowas und sogar noch ein Eventsystem. Die Taktfrequenz ist mit bis zu 32MHZ auch höher. Ich holte einen ATxmega128A1U aus dem Lager und lötete ihn auf eine Platine, die noch von einer Prototypenserie übrig war.
Erstmal musste ich mich mit dem Chip vertraut machen (ich hatte nur die Platine damals gemacht, aber nicht die Firmware). Er ist ein bisschen Anders als meine üblichen AVRs, aber man gewöhnt sich schnell um. Nachdem ich den DMA und das Eventsystem beherrschte, versuchte ich bei jeder fallenden Flanke eines Taktsignals die Bits eines Ports in den SRAM zu laden. Selbst bei 5MHz Taktrate funktionierte das noch tadellos, somit war dieses Hindernis mal aus dem Weg geräumt. Ich hatte mir ja bereits die nötigen Leitungen aus dem Rechner herausgeführt. Diese TIs haben einen sogenannten Viewport Anschluss, an den man transparente LCD Schirme anklemmen kann, die man auf den Overhead legt (für den Unterricht). Für diesen Port hat er einen 74HCT244 drin, der sämtliche Signale puffert. Das passte mir natürlich sehr schön ins Konzept, denn so war der ASIC geschützt.
Mit Hilfe der Toshiba Datenblätter und meinem treuen HP 1650A Logikanalyzer sowie dem DSO konnte ich mir die Datenübertragung anschauen (allerdings sind 1024 Samples pro Kanal beim Analyzer doch etwas wenig) und somit genau festlegen, wie wann und wo der Controller den DMA Transfer triggern muss. Das erforderte einiges an Rumgewerke zu einer Uhrzeit, an der andere normalerweise Schlafen (oder bereits wieder aufstehen...) aber es hat sich ausgezahlt, denn nach einigen sorgfältig formulierten Zeilen C und Assembler, marschierten die Bytes brav da hin wo sie sollten.

Der erste Abschnitt bestand darin, eine einzelne Zeile in den RAM zu bekommen, via RS232 an den Rechner zu schicken und dann mit dem zu Vergleichen, was ich auf dem Logikanalyzer sah. Dabei musste noch ein Bisschen an der Triggerroutine verfeinert werden, damit er wirklich genau beim ersten Byte anfängt. Als das geschafft war, erweiterte ich die Firmware so, dass er das für jede Zeile widerholt. Allerdings stellte sich heraus, dass die allererste Zeile verschluckt wird, weil die Daten ja bereits im Spaltentreiber sein müssen, wenn der Impuls für die erste Zeile zum Zeilentreiber kommt, auf den ich ja Triggere. Ich brauchte also sowas wie einen Pretrigger. Mit einer "framesync" Routine warte ich auf diesen Impuls, lasse dann die restlichen 127 Zeilen dieses Frames kommen (mit dem Line-Pulse) und dann schalte ich den eigentlichen Trigger scharf, so dass ich wirklich bei Zeile 0 anfange. Anschließend wandern die Bytes in den SRAM.

Zum Prüfen der Daten habe ich ein einfaches C# Programm geschrieben, das aus den übermittelten Bytes den Schirminhalt rekonstruiert. Ein paar Anläufe hat es gebraucht bis sowohl der Controller als auch das Programm am PC das gemacht haben, was sie sollten.

Noch ein paar Formatierungsfehler, aber auch darüber freut man sich am Anfang schon

Schon besser, nur das erste Nibble ist jeweils abgeschnitten und am Ende dafür verdoppelt (ging aufs Konto vom C# Programm)

Korrekt ausgerichtet. Nur die oberste Zeile ist noch ganz Unten (noch ohne Pretrigger)

Na bitte, geht doch.

Platine

Herausgeführte Leitungen mit Logikanalyzer-Probes und Controllerplatine

DSO und Logikanalyzer beim Beobachten der LCD Signale

Nachdem also die Daten sauber in den RAM gelesen werden konnten, ging es nun an die Ausgabe. Das ausgesucht Display ist momentan noch nicht da, also hab ich ein anderes genommen. Es hat aber nur 128x64 Pixel. Darum kann ich darauf nur einen Ausschnitt anzeigen. Eine unangenehme Sache ist das Format der Displaydaten. In jedem Byte des Puffers ist nur das untere Nibble interessant (es gehen immer nur 4 Bit zum Toshiba IC) und jedes Nibble stellt 4 aufeinanderfolgende Pixel in einer Zeile dar. Die meisten graphischen LCD Displays mit integriertem Controller, darunter auch dieses, sind allerdings in Pages aufgeteilt, wo jedes Byte eine vertikale Reihe von 8 Pixel darstellt. Die Firmware baut aus den Daten vom ASIC jeweils eine Page komplett fertig und lädt diese dann auf das neue LCD. Beim Umformatieren der Daten fuhrwerkt der C Compiler ganz schön rum, da werde ich eventuell dann in Assembler eine optimierte Variante schreiben. Weiters werden die Daten momentan per Software auf das LCD übertragen (noch nicht mal per hardware SPI). Aber selbst mit diesen ganzen Performance-Bremsen war die Reaktionszeit akzeptabel. Mit Optimiertem Code und per DMA angesteuertem SPI wird sich die Performance um einiges steigern lassen.

Hier sieht man einen der ersten Versuche:

Ausschnitt des Schirmbildes auf dem testweise angeschlossenen 128x64 LCD. Der Fleck links unten ist ein Schaden am Display

Einen weiteren praktischen Nebeneffekt hatte das Unterfangen bereits: Ich hab mich in den XMega eingearbeitet und finde ihn super. Gerade die Events und der DMA Controller sind Gold wert, wenn man sie braucht. Somit war das Ganze alleine wegen den Erfahrungen bereits die Arbeit wert.

Als nächstes wird das richtige Display bestellt, damit man auch das ganze Schirmbild sehen kann. Fortsetzung folgt voraussichtlich in Kürze!

(C) 2018 Ing. Christoph Baumann, OE2BCL

Alle Angaben ohne Gewähr.
Ich übernehme keine Verantwortung für die Richtigkeit der hier gezeigten Inhalte sowie für Schäden, Folgekosten o.ä.
durch die hier beschriebenen Informationen!
Arbeiten an elektrischen Geräten aller Art dürfen nur von sachkundigen Personen durchgeführt werden!
Impressum