Victor Vicki - Fehlerhafte Bildschirmausgabe

Jungs, da bin ich wieder ...

Zitat von Toast_r

Einerseits ist es ja recht interessant, was ihr da so alles überlegt.
Andererseits würde mir die Geduld fehlen, zumal das meiste ja sowieso auf Vermutungen basiert.
In der Zeit hätte längst den 6845 augelötet, gesockelt, und das ganze mit einem anderen getestet.

Jeder auf seine Weise. Wenn es darum geht, einen 40 poligen Käfer auszulöten, versuche ich halt erst mal sicher zu gehen, dass sich das lohnt. Gut, das Sockeln ist immer ein Gewinn, aber es ist schon ein ziemlicher Aufwand, verbunden mit einem gewissen Risiko.
Und was die Zeit angeht: Handbücher und Datenblätter studieren, Zusammenhänge suchen und im Forum diskutieren kann ich fast immer und überall. Die Vicky und die Lötstation stehen dagegen im Keller, und da komme ich an vielen Tagen nicht länger als eine halbe Stunde hin.

Zitat von kpanic

Funktioniert aber auch anders herum.
Ich hab auch schon aus Spaß an der Freude eine voll funktionstüchtig e CIA am C64 gesockelt. Übung schadet nie

Kann ich sogar nachvollziehen, aber einerseits habe ich die Zeitbegrenzung, und andererseits ist ein C64 zum Üben deutlich geeigneter als das Mainboard einer Vicky.

Wie auch immer, ich habe mich an den 6845 bisher noch nicht rangetraut, und ich bin auch immer weniger überzeugt, dass er der Schuldige ist (siehe nächstes Posting).

So,

im Anhang ist ein Bild. Heute von der Vicky geschossen, kein Fake ^^

Gut, ein bisschen musste ich nachhelfen, und der "Effekt" ist auch nicht wirklich von Dauer. Aber der Reihe nach.

Zuerst mal habe ich festgestellt, dass der Befehl 132c.com den 132-Zeichen-Modus nur vorbereitet, aber nicht einschaltet. Im Wesentlichen wird der spezielle Zeichensatz und vermutlich ein Stück Programmcode geladen.
Mit dem Befehl 132on.com wird der Modus dann umgeschaltet, und als ich das probiert habe, passierte folgendes: Der CRTC wurde umprogrammiert, das Raster war auf einmal 50*132, der Cursor klein, und auf dem Bildschirm erschien ein lustiges Durcheinander von Zeichen und Bitmustern.

Für mich war das ein weiteres Indiz, dass der 6845 vermutlich in Ordnung ist - die fehlende Umschaltung, die ich immer vermisst hatte, hatte es einfach noch nie gegeben.
Und außerdem wurde mir klar, dass das System im normalen Textmodus (25*80) offenbar zufällig auf den zusätzlichen Zeichensatz des 132-Modus gestoßen war, und da eben nicht "passend" (das wär auch des Zufalls zuviel gewesen).
Und offenbar wird der kleine Zeichensatz - obwohl für die 6*8 Pixel locker 8 Byte pro Zeichen gereicht hätten - wieder in je 16 Worten abgelegt, so dass der "Zeichenversatz" immer gleich blieb und auch mit dem 10*16-Raster nur eines der kleinen Zeichen dargestellt wurde.

Die nächste Aufgabe war nun die Suche des Zeichensatzes im RAM. Dazu habe ich per 132c.com den zusätzlichen Zeichensatz geladen und dann wieder über die serielle Verbindung einen kompletten Speicherdump der ersten 128 KB gemacht. In diesem Dump habe ich die Zeichen gesucht und gefunden: Die Klammer, die immer statt eines Blanks gezeichnet wurde, liegt von 0xD088 bis 0xD0A7. Allerdings fehlte unten ja immer eine Pixelreihe, und oben waren Pixel eines anderen Buchstabens zu erkennen, so dass offensichtlich die Bytes an den Adressen 0xD080 bis 0xD09F gelesen werden.

Das "echte" Bitmuster des Blanks liegt dagegen von 0x1080 bis 0x109F. Ergo sind da zwei Bits gesetzt, die nicht gesetzt sein dürften:

0001 0000 1000 0000b - erwartete Startadresse des Zeichenmusters
1101 0000 1000 0000b - tatsächliche Startadresse

Die unteren 5 Bits dieser Adresse werden durch die Rasterzeilenadressbits des CRTC geliefert, die oberen Bits dagegen aus dem Bildschirmspeicher (Refresh Memory/LUT - auf jeden Fall das SRAM), genauer aus dessen Datenausgängen. Da dieser Speicherbereich beim Auslesen korrekte Werte anzeigt, werden diese beiden Bits offenbar auf dem Weg von den Datenausgängen des SRAM zu den Adressleitungen des Hauptspeichers verändert. Das ist jetzt ein überschaubarer Bereich, den ich mir als nächstes mit dem Oszilloskop anschauen werde.

Um meine Theorie zu prüfen, habe ich ein Miniprogramm geschrieben, dass den Zeichensatz von seiner "korrekten" Position an die "erwartete" Position im Speicher kopiert. Original: 0x00c80 - 0x02c7f, Kopie: 0x0cc80 - 0x0ec7f

Und danach habe ich den Screenshot angefertigt

Natürlich ist das nicht von Dauer, weil das nächstbeste Programm beim Laden diesen Zeichensatz wieder überschreibt. Aber die eingebauten DOS-Befehle kann ich problemlos absetzen, und mir geht es zunächst nur ums Prinzip.

Jetzt hoffe ich nur, dass die Adress- und Buslogik nicht auch in dem Fujitsu-Käfer steckt. Eigentlich hat es auf dem Board genügend Decoder/Multiplexer etc.
Und vielleicht wiord dann auch endlich gelötet

Danke für alle Rückmeldungen!

Wegen der Sache mit den Adressen habe ich mal das Original-Blockdiagramm aus der Victor-Doku angehängt und dann eine zweite Version, in der ich die Texte lesbar erneuert habe. Die folgende Beschreibung gilt grundsätzlich für den Textmodus; im Grafikmodus sieht es minimal anders aus:

Der 6845 hat zwar 14 Adressleitungen (kann also 16KB adressieren), nutzt aber nur die unteren 11 (MA0-MA10), um die 2048 Worte des SRAM zu adressieren. Die restlichen 3 Leitungen sind ungenutzt bzw. haben Sonderaufgaben (s.u.).

Von den 16 Bit, die als Daten von den SRAMs ("Screen Buffer RAM") geliefert werden, werden 5 Bits für die Attribute verwendet und völlig separat genutzt, während die restlichen 11 Bits (um die Verwirrung zu maximieren ist das wieder die gleiche Anzahl wie bei den 6845-Adressen; es handelt sich aber um völlig andere Signale) zusammen mit 4 Rasterzeilenadressen (die wiederum direkt vom 6845 kommen) die Zeichentabelle ("Dot Matrix RAM") im Hauptspeicher adressieren.
Die 4 Bits dienen dazu, eine der 16 Zeilen, aus denen ein Zeichen besteht, auszuwählen; mit den 11 Bit aus dem SRAM können 2048 verschiedene Zeichen adressiert werden. Insgesamt ist das ein Bereich von 32K Worten oder 64KB.

Eines der freien Adressbits des 6845 (s.o.) wird nun zusätzlich verwendet, um eine von 2 Speicherbanken (d.h die ersten oder die zweiten 64K im Hauptspeicher) auszuwählen (man kann also durch Umprogrammierung des CRTC zwischen zwei Zeichensätzen umschalten). Insgesamt müssen die Zeichendefinitionen auf jeden Fall in den unteren 128 KB des Hauptspeichers liegen - das steht so auch in der Doku.

Die Adresse einer Pixelreihe im Hauptspeicher wird also folgendermaßen aufgebaut:

000B SSSS SSSS SSSR RRR0

Dabei ist B das Bankselect-Bit vom 6845, S ist der 11 Bit lange "Font Cell Pointer", der vom SRAM geliefert wird, und R ist die 4 Bit lange Rasterzeilen-Adresse vom 6845.

Die defekten Bits kommen also eigentlich aus dem SRAM - dort stehen sie aber richtig drin, wenn sie der Prozessor ausliest. Deshalb komme ich auf die nachfolgende Multiplexer-Demultiplexer-Logik als Ursache (denn die Daten der SRAMs müssen je nach Zustand entweder auf den Datenbus oder den Adressbus des Prozessors gelegt werden - je nachdem ob es sich um einen Datenzugriff des Prozessors oder einen Videozugriff des CRTC handelt. Und genauso müssen die Adressleitungen der unteren 128 KB mal vom Prozessor, und mal von der Video-Logik adressiert werden - dual ported).

Ich weiß, das ist eine schwierige Materie, wenn man sich nicht intensiv damit befasst, aber ich hoffe, es ist etwas klarer geworden.

Zitat von dlchnr

Wollte nicht ausschließen, dass es so ist, sondern nur ein wenig davor warnen, sich darauf zu versteifen.
Ist das aus der Doku der Victor 9000 oder der Vicki? Wenn Vicki - super - dann ist dieser Punkt geklärt - wenn 9000, liegt die Vermutung nah, dass es auch geklärt ist, kann aber auch anders sein!

Wär schön, wenn ich was zur Vicki gefunden hätte, aber da gibt's irgendwie gar nichts

Da aber die beiden Systeme softwareseitig kompatibel sind und insbesondere die gleichen Leistungsdaten im Videobereich haben, bin ich ganz optimistisch, dass die interne Logik weitgehend identisch ist. Und was ich bisher rausgefunden habe, passt auch dazu.

Ich habe heute abend etwas das Board analysiert; war etwas mühsam, aber da ich relativ genau wusste, wonach ich suche, war es doch überschaubar. Ich habe mich dabei tatsächlich an die Empfehlungen aus einem der ersten Postings von dlchnr gehalten, nur eben beschränkt auf die Datenleitungen der SRAMs. Die landen zunächst mal über einen Bus-Transceiver auf einem (sekundären) Datenbus - mit entsprechend vielen unübersichtlichen Verbindungen in alle möglichen Richtungen.

Aber an einer Stelle geht es recht offensichtlich für einen Teil der Datenleitungen zum Adressbus des Hauptspeichers:

SRAM-Daten <=> 245 Bus Transceiver => 374 D-Flipflop => Adressbus

Der 245 müsste ok sein, weil z.B. die CPU die Daten richtig liest. Ich habe also im Moment den 374 im Verdacht. Mal sehen, was die Messungen ergeben - und dann kann vielleicht endlich gelötet werden

Zitat von dlchnr

Wird überhaupt überprüft, ob in Deinem System 256kByte Hauptspeicher zur Verfügung stehen, oder könnte es sein, dass im System effektiv nur 64kByte vorhanden sind, weil zwei Adressbits klemmen?

Zitat von dlchnr

Ob Du da nicht doch auf dem gemultiplexten Adress-/Datenbus des 8086 (Primärbus) gelandet bist und der gefundene 374er allein der RAS-/CAS-Adressgenerierung bei 8086-Zugriffen auf den Haupspeicher dient?

Du kannst einem ja Hoffnung machen Ich habe wirklich angefangen zu zweifeln

Naja, aber hin und wieder darf man dann doch mal Glück haben. Ich habe wie beabsichtigt mit dem Oszilloskop die Ein- und Ausgänge von den Flipflops verglichen (unter Berücksichtigung der Clock und -OE-Eingänge) und tatsächlich zwei Ausgänge gefunden, die bei aktivem -OE dauernd auf 1 gingen - obwohl der Dateneingang vorher eindeutig auf 0 lag (siehe Anhang).

Ich hab's dann riskiert, den 20-poligen Käfer rausgelötet und durch einen Sockel ersetzt, einen 74LS374 eingesetzt und -

Als "Beweis" habe ich ein Bild nach dem Booten - auch ohne mein Hilfsprogramm wird das Logo und alle Texte angezeigt. Und schließlich auch noch einen Eindruck vom 132-Zeichen-Modus - der auf dem kleinen eingebauten Bildschirm aber eher unangemessen ist.

Ich bin glücklich

So, jetzt sind ein paar Danksagungen fällig.

Allen voran natürlich dlchnr - Du hast eine Menge Ideen und Input geliefert; teilweise war es sehr kontrovers mit Dir, aber Du hast mich dadurch auch dazu gebracht, sehr intensiv über alles nachzudenken. Vor allem aber warst Du unermüdlich - man hätte meinen können, es geht um Deinen Rechner

retro64 - Danke für die harten Fakten zum Victor. Hin und wieder ist es gut, wenn man nicht immer nur spekulieren muss, sondern auch mal was Handfestes bekommt. Du hättest mir aber früher verraten können, dass der 132-Zeichen-Modus mit dem 132c.com nur vorbereitet, aber noch nicht aktiviert wird
Achja, wir könnten uns demnächst mal über Software unterhalten. Ich muss aber zuerst ein paar passende Disketten zusammensuchen.

kpanic - der Fachmann für PCs und DOS: kurze, knackige, präzise Beiträge

Toast_r - Ich freu' mich schon auf Deine Lötvorführung. Ich habe heute für den 20-Pinner 10 Minuten gebraucht - Dein Angebot steht hoffentlich noch (40 Pins in 5 Minuten)

stynx - Auch Dir ein Dankeschön für die Interpretationshilfen und die Analyse der Handbücher

x1541 - Jetzt, wo die Vicki wieder gesund ist, wäre Stuttgart ja nur noch eine Kür?! Ich denke trotzdem drüber nach.

fritzeflink - nein, ich habe keinen Genie mehr für Dich! Aber vielleicht kann das mit Stuttgart was werden ....

felge1966 - hast uns ja schon recht früh verlassen, aber dennoch danke für Deine Beiträge.

So, ich hoffe, ich habe keinen vergessen ... Für alle gilt: Herzlichen Dank!

Und jetzt dürft Ihr gratulieren ...

Zitat von dlchnr

Super, dass die Vicki wieder läuft
Trotzdem würde mich noch interessieren, welche Veriante meiner Bilds nun tatsächlich vorliegt - die obere oder untere?

Der defekte 374er lag definitiv an den "Ausgängen" oder besser gesagt an der "Gegenseite" des Transceivers (ist ja bidirektional). Also das untere Bild.

Zitat von dlchnr

Ich hatte die obere Variante erwartet, da die mir besser ins Blockdiagramm der 9000 reinpasst.

Wenn ich wieder an die Vicki rankomme, werde ich das nochmal prüfen. Ich habe gerade noch mal einen Blick in meine Notizen geworfen - die sind an der Stelle aber nicht eindeutig. Das hat mich jetzt verunsichert

Leider kann ich im Moment aber nichts machen, weil mich eine Erkältung umgehauen hat - jetzt, wo es der Vicki besser geht, bin ich krank: Fehlfunktion von Hals und Lunge. Obere I/O-Kanäle verstopft. Nur noch halbe Rechenleistung. Trotz Runtertakten erhöhte Core-Temperatur.
Irgendeiner 'ne Idee?

So, ich bin wieder auf den Beinen. Danke für die Genesungswünsche (weiß nicht, ob es dadurch schneller ging, aber es hat gut getan) und auch für die Glückwünsche zur Reparatur. Ich bin heute Abend noch mal unten gewesen und habe die Vicki wieder zusammengebaut - und sie läuft immer noch

Vorher habe ich aber noch mal die Messspitzen reingehalten, um diese Frage endlich zu klären:

Zitat von dlchnr

Ich hatte die obere Variante erwartet, da die mir besser ins Blockdiagramm der 9000 reinpasst

Deine Ferndiagnose war vollkommen korrekt - ich hatte mich wohl zu lange mit dem Bus jenseits des 245 beschäftigt und deshalb fest im Kopf, dass ich *alles* jenseits dieses Transceivers gefunden hatte. Tatsächlich hängen die Eingänge des 374 also doch direkt am SRAM. Sorry, dass ich das falsch geschrieben habe.

Zitat von retro64

Das mit dem 132er tut mir leid, gelobe Besserung (genauere Beschreibungen).

Ist schon ok Was vermutlich zu selbstverständlich für Dich.
Apropos Software: Was für Disketten verwendest Du an der Maschine? "Moderne" HD-Disketten oder DD? Oder tatsächlich 4D-Disketten (die doch ziemlich selten sind)?[imgwidth][/imgwidth]