Victor Vicki - Fehlerhafte Bildschirmausgabe

  • Jungs, da bin ich wieder ... :D


    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. :(


    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 :thumbup:


    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 :P

  • ...so dass der "Zeichenversatz" immer gleich blieb...


    da schau an - gab's doch tatsächlich eine andere Erklärung für den konstanten Versatz!
    Viel Glück bei der weitern Suche - und hoffentlich wirst Du außerhalb der Fujitsu Bausteine fündig.
    Eine Sache ist mir noch aufgefallen - der 6845 generiert 14 Adressleitungen (MA0..MA13) und die ersten 14 Adressleitungen sind auch ok.
    Mit de LUT ließen sich zwar aus 14 Adresssignalen 16 generieren, muss man aber nicht so machen, es könnte gut sein, dass dort wirklich nur
    14 Adressleitungen übersetzt werden, die obersten beiden Datenleitungen der SRAMs also ins leere laufen.
    Da mit 16 Adressleitungen nur 64kB zu adressieren sind, der Hauptspeicher der Vicki aber wesentlich größer ist, müssen über A14 und A15
    hinaus weitere Adresssignale generiert werden - vermutlich umfasst der Adressbus A0..A19 (der komplette, mit dem 8086 mögliche Adressraum),
    so dass es durchaus möglich wäre, dass die Adressen A14 und A15 gemeinsam mit A16..A19 generieren werden.

  • 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. ?(

  • Die defekten Bits kommen also eigentlich aus dem SRAM


    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!


  • 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 :D

  • Die landen zunächst mal über einen Bus-Transceiver auf einem (sekundären) Datenbus


    Deine Beschreibung liest sich wie die untere Anordnung auf dem Bild, erwarten würde ich eher 'ne Anordnung wie oben auf dem Bild - über den 245er geht es zum Datenbus, so dass das SRAM gelesen und beschrieben werden kann, über den 374er geht's bei der Vidoeausgabe zu den Adressleitungen des Hauptspeichers?

  • Ok - da der 8086 einen gemultiplexten Adress-/Datenbus besitzt, wäre die untere Anordnung auch denkbar - dann würden aber 8086- und Videozugriffe auf den Hauptspeicher die gleichen Bausteine zur RAS-/CAS-Adressgenerierung benutzen und es ist dann schwerlich zu erklären, dass beim Videozugriff Adressfehler auftreten und beim 8086-Zugriff nicht?

  • 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:


    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?

  • 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?


    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 :shock: Ich habe wirklich angefangen zu zweifeln 8-)


    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 -


    Tusch!!!


    Die Vicki läuft wieder!


    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.


    :juchee: Ich bin glücklich :vivat:


    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) :tüdeldü:


    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! :applaus:



    Und jetzt dürft Ihr gratulieren ... :D

  • Gratulation! :thumbup:


    Und eine weitere coole Kiste ist wieder bereit produktiv genutzt zu werden ;)


    Ist aber einerseits faszinierend, andererseits auch erschreckend zu sehen, wie sehr das MS-DOS angepasst wurde... Ganz schön ungewohnt, wenn man jahrzehntelang nur mit IBM-kompatiblem DOS zu tun hatte.
    Spitze. Freut mich echt saumäßig, dass der Rechner wieder rennt. :anbet:

    • Offizieller Beitrag

    Das freut mich wirklich, daß Du es hinbekommen hast. Gratulation!
    Und vor allem Respekt für die Ausdauer!


    Was den 40-Pinner in 5 Minuten angeht: Mal sehen... Ich wurde bereits gebeten, die Heißluftlötstation zum nächsten Treffen nach Brühl mitzubrignen, weil da ein Patient einige Käferchen lassen soll.
    Auf der letzten CC waren mit der Methode 16 4164 RAMs ratzfatz raus ... ich glaube das hat unter 5 Minuten gedauert.
    Man kann ja mal probieren, ob das mit einem 40-Pinner auch so flott geht.

  • Super, dass die Vicki wieder läuft :thumbup:
    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.

  • Also das untere Bild.


    Ich hatte die obere Variante erwartet, da die mir besser ins Blockdiagramm der 9000 reinpasst (statt dem einen 245er müssten es mit einen 8086 natürlich zwie 245eer sein) - vermutlich gibt es auf der "Transistorebene" aber doch Unterschiede zwischen der 9000 und der Vicki.

  • Sieht doch gut aus. Immerhin hast du jetzt auch einen tieferen Einblick in deinen Victor bekommen.

    Zitat

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


    Da ich dir da nicht unbedingt weiterhelfen konnte, wollte ich dich nicht sinnlos in irgendwelche Irrwege schicken.


    Gruß Jörg


  • 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? :roll:

  • Erstmal gute Besserung an Dich. Und zur Vicki: Gute Arbeit. Und toll hier im Reparaturthread dokumentiert. Habs interessiert mitgelesen, finde sowas immer spannend.


    Viele Grüße
    Andreas

  • 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.


    Erstmal herzlichen Glückwunsch! - Super Arbeit!
    Das mit dem 132er tut mir leid, gelobe Besserung (genauere Beschreibungen).
    Und wegen der Software: Klar kein Problem - melde Dich einfach bei mir....wenn ich helfen kann: gerne!


    Sirius-Grüße aus Berlin ;)

  • 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 :D


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


    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.


    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]

  • Sorry, dass ich das falsch geschrieben habe.


    ein Sorry ist da beileibe nicht nötig - aber den Punkt zu klären, war sicherlich sinnvoll - ein Punkt bei der Entwicklung eines Blockdiagramms für die Vicki.
    Würde an Deiner Stelle da jetzt nicht aufhören und die erzielten Erkenntnisse und weitere Untersuchungen zumindest soweit fortführen, bis ein Blockschaltbilod für die Vicki gewonnen ist
    (der Aufwand für ein Blockschaltbild sollte sich in Grenzen halten verglichen mit dem Aufwand, 'nen kompletten Schaltplan zu generieren)!

  • Die Vicki läuft wieder!

    Glückwunsch !!! Software für den Victor - und damit auch für die Vicki - dürfte hier ja genügend im Umlauf sein. :)
    In Berlin sind ja gerade zwei Boxen voll gelandet - mal sehen was ihr da an Schätzen habt :)


    Gruß
    Hans