Victor Vicki - Fehlerhafte Bildschirmausgabe

    Hallo in die Runde,


    die vielen Sirius/Victor-Threads der letzten Zeit haben mich veranlasst, mal wieder meine Vicki (portable) rauszuholen und in Betrieb zu nehmen. Ich hatte sie vor einiger Zeit eingelagert, weil ich damals mit dem Fehlerbild nicht zurecht kam - jetzt ist es vielleicht Zeit für einen neuen Anlauf.


    Hier ein Bild von der schon bekannten Seite Home of the ACT Sirius and Victor Computers:
    [Blockierte Grafik: http://www.actsirius1.co.uk/pages/images/vicki/vicki1.jpg]


    Die Vicki ist eine transportable Version des Sirius/Victor 9000 mit all seinen Macken und Vorteilen: hochauflösende Grafik mit selbstdefinierbaren Fonts, >1MB auf normalen DD Disketten (allerdings 96tpi) durch Drehzahlanpassung, von Tastatur steuerbare Helligkeit/Kontrast/Lautstärke etc.


    Der Fehler in meiner Maschine sieht gar nicht so dramatisch aus: Der Rechner läuft, bootet von Diskette und reagiert auf Tastatureingaben. Es werden aber keinerlei Zeichen auf dem Bildschirm dargestellt, nur der Cursor ist zu sehen. Dieser reagiert auch völlig normal auf meine Eingaben; bei jedem Tastendruck springt er eine Stelle weiter, bei Return an den Anfang der nächsten Zeile etc.
    Auch der Rest sieht ganz gut aus: Bei dem (blind eingegebenen) Befehl DIR springt das Laufwerk an, und auch die Helligkeitsverstellung per Tastatur funktioniert (Cursor wird heller/dunkler).


    Der Rechner verwendet offenbar einen 6845 CRTC (siehe Logicboard im Anhang) - gibt's hier jemand, der sich mit dem gut auskennt? Wie werden die normalerweise eingesetzt, speziell hinsichtlich der Cursorerzeugung? Wo könnte ich sinnvoll nachmessen, an welcher Stelle die Informationen verloren gehen? Irgendwelche Ideen?


    Leider gibt's wohl nirgendwo Schaltpläne, und die Unterlagen vom Sirius erscheinen mir in dieser Hinsicht unvollständig und auch nicht übertragbar.


    Bin für jeden Tipp dankbar.
    Georg

    • Offizieller Beitrag

    Wäre auch mein erster Ansatz gewesen, aber da der Rechner ja mit veränderbaren Fonts arbeitet, ist das wahrscheinlich etwas komplexer.
    Evtl. wird das Char-Rom beim Sytemstart in ein eigenes RAM kopiert , und dabei geht was schief ?
    Oder es gibt eine Umschaltung zwischen RAM und ROM, und die zeigt fälschlicher Weise auf das beim Systemstart initialisierte, und daher leere, RAM ?
    Man müsste die Architektur der Maschine besser kennen ....

    Zitat von kpanic

    Klingt irgendwie nach einem Problem mit dem Character-ROM...


    Ich gebe Dir völlig Recht - nur hat die Vicki (wie der Sirius) kein Character ROM :grübel:
    Die Zeichensätze werden (beim Systemstart bzw. später vermutlich auch bei Bedarf durch den Anwender) im RAM abgelegt - evtl. sogar von Diskette gelesen. Das ist das Problem bei diesen Exoten: keiner weiß genaues nicht. :roll:


    Da sonst alles funktioniert, halte ich es für wenig wahrscheinlich, dass das RAM ausgerechnet an dieser Stelle großflächig Probleme macht. Ich denke eher an eine zentrale Stelle in der Videologik: Die Bits aus dem Zeichengenerator (egal ob nun RAM oder ROM), die ja parallel gelesen werden, müssen für die Ausgabe auf dem Bildschirm serialisiert werden. Entweder diskret per Schieberegister oder evtl. erledigt der CRTC das selber. Der Cursor wird dann z.B. hinterher dazugemischt, indem zum richtigen Zeitpunkt der Ausgangspegel angehoben wird. Kann aber evtl auch im CRTC passieren, denn auf der Platine ist ja erstaunlich wenig analoges Zeugs drauf. Wenn jetzt an der Stelle ein Fehler ist (es reicht eine schlechte Lötstelle oder ein schlechter Kontakt im Sockel), könnte das zu dem Fehlerbild führen.


    Wie gesagt, ich kenne den CRTC zu schlecht und muss mich erst mal in das ganze Thema einlesen und ein paar typische (dokumentierte) Schaltungsbeispiele studieren. In der Analyse der Platine (Leiterbahnverfolgung) bin ich zu schlecht - da möchte ich erst ein paar Ideen haben, auf welche Leitungen ich schauen soll. Deshalb hatte ich auf einen 6845-Helden gehofft :tüdeldü:


    Und wenn ich weiß, wie das typischerweise abläuft, ist es ein leichtes, mit dem Oszilloskop zu prüfen, ob was vom Char-Gen kommt, oder ob am seriellen Ausgang noch was ankommt und erst später verloren geht etc.


    Zitat von Toast_r

    Wäre auch mein erster Ansatz gewesen, aber da der Rechner ja mit veränderbaren Fonts arbeitet, ist das wahrscheinlich etwas komplexer.
    Evtl. wird das Char-Rom beim Sytemstart in ein eigenes RAM kopiert , und dabei geht was schief ?
    Oder es gibt eine Umschaltung zwischen RAM und ROM, und die zeigt fälschlicher Weise auf das beim Systemstart initialisierte, und daher leere, RAM ?
    Man müsste die Architektur der Maschine besser kennen ....


    Genau, das ist leider das Problem. Diese Ideen können ebenfalls zutreffen (wobei der Zeichensatz entweder im BIOS-ROM enthalten ist oder tatsächlich von Diskette geladen wird, denn es befindet sich kein weiteres ROM auf dem Board).


    Georg

    Lt. Datenblatt kann der 6845 für alpanumerische, semigrafische und voll-grafische Grafiken verwendet werden, so dass ein Charakter-RAM nicht unbedingt notwendig ist.
    Der Baustein bietet eine Hardware-Cursor - d.h., der Controller hat alle notwendige Logik eingebaut, die notwendig ist, an einer vom Prozessor vorgegebenen Position einen definierbaren Cursor einzublenden. Dazu wird vom 6845 zu den notwendigen Zeitpunkten das Cursor-Signal gesetzt, das dann an geeigneter Stellen dem Video-Signal zugemixt werden muss.
    Bei Deinem Gerät dürfte also ab der Stelle, ab der das Cursor-Signal zugemixt wird, alles ok sein, das Problem tritt vorher auf - oder anders gesagt, es gint noch jede Menge Fehlermöglichkeiten :(
    Ohne Schaltplan wird es auf jeden Fall schwierig. Und falls der nicht aufzutreiben ist, würde ich Applikationen für den 6845 sammeln und darauf abklopfen, ob eine "Verwandschaft" zur, auf dem Vicki realisierten Grafik vorhanden ist.

    Einmal editiert, zuletzt von dlchnr ()

    • Offizieller Beitrag

    Die beiden SRAMs (2 x 2kB) würden von der Speichergröße her gut für Videospeicher und Zeichengenerator passen.
    Der Zeichensatz kann eigentlich nur mit im ROM sein, wenn der Rechner schon in der Lage ist, irgendwas lesbares darzustellen, bevor von Disk gebootet wurde.
    Wenn es nur einen ladbaren Zeichensatz gäbe, könnt der Rechner keine Fehlermeldungen vor dem Laden von Diskette / Platte anzeigen.
    Ich gehe aber einfach mal davon aus, daß er in der Lage ist, solche Fehlermeldungen auzugeben, also muß der Zeichensatz ja irgendwo aus dem ROM kommen.
    Da offenbar kein dediziertes Zeichensatz-ROM vorhanden ist, wird das also vermutlich aus dem System-Rom ins Zeichensatz-RAM kopiert.

    Guten Morgen und Danke für die Rückmeldungen!


    Zitat von dlchnr

    Und falls der nicht aufzutreiben ist, würde ich Applikationen für den 6845 sammeln und darauf abklopfen, ob eine "Verwandschaft" zur, auf dem Vicki realisierten Grafik vorhanden ist.


    So ungefähr hatte ich mir das auch vorgestellt. Ich habe auch schon nach solche "typischen" Schaltungen gesucht, aber das ist erstaunlich schwierig, wenn man bedenkt, dass der 6845 recht häufig verwendet wurde. Z.B. im CPC, aber man liest auch, dass dort die Schaltung nicht gerade typisch war ...


    Ich hatte mich vor ca. 20 Jahren schon mal mit dem Thema beschäftigt - ohne Internet, ohne Google, nur mit Zeitschriften und Büchern - damals bin ich irgendwie auch an Material drangekommen, fast leichter als heute ?( Leider habe ich vieles im Lauf der Zeit wieder vergessen ...


    Aber zurück zum Thema. Dass eine externe Beschaltung nötig ist steht ja nun fest; ich werde also mal die entsprechenden Leitungen gezielt nachverfolgen und so versuchen, das Schieberegister zu identifizieren - dort werde ich dann mit den Messungen beginnen. Ist schon mal ein Ansatz.


    Zitat von felge1966

    Wenn ich mir die Platine so ansehe, wären die beiden MM2016P der erste Ansatz. Eventuell sind die RAMs, in die der Zeichensatz kopiert wird.


    Wenn ich die Informationen zum Sirius richtig gelesen habe und diese Dinge auf die Vicki übertragen darf, stellen die 2016 den Bildschirmspeicher dar. Der Zeichengenerator wird wohl dynamisch vom Hauptspeicher abgezwackt (je nach Zeichensatz unterschiedlich viel). Wenn ich das richtig verstanden habe, kann die Maschine deutlich mehr als nur 256 verschiedene Zeichen darstellen. Müsste ich aber noch mal genauer durchlesen. Ist sehr interessant, aber für mein Problem z.Zt. vermutlich weniger relevant.


    Zitat von Toast_r

    Der Zeichensatz kann eigentlich nur mit im ROM sein, wenn der Rechner schon in der Lage ist, irgendwas lesbares darzustellen, bevor von Disk gebootet wurde.


    Da hat Du natürlich recht - bloß fehlt mir jede Erinnerung daran, wie sich das Teil früher gemeldet hat, und entsprechende Dokumentation habe ich nicht gefunden. :(


    Frage in die Runde der Sirius-Besitzer: Meldet der sich irgendwie, wenn ohne Diskette gebootet wird?


    Mal sehen, wenn ich mit vernünftigem Aufwand meinen alten Eprommer ans Laufen bekomme, werde ich die mal auslesen - dann sollte sich das klären lassen.
    Das wird aber erst richtig wichtig, wenn sich rausgestellt hat, dass mit dem Zeichengenerator etwas nicht stimmt. Ich hoffe ja immer noch, dass es irgendwas an der Videologik ist.


    Gruß
    Georg

    Zitat von felge1966

    Wenn ich mir die Platine so ansehe, wären die beiden MM2016P der erste Ansatz.


    Man kann so sicherlich einen Zufallstreffer laden, wird aber, wenn man einfach auf Verdacht tauscht, häufig daneben liegen.
    Wenn mir das Teil gehören würde, würd' ich mir 'nen Schaltplan generieren, wenn er im Internet nicht zu finden ist.
    Erster Schritt wäre mal ein derartiger Bestückungsplan (auf Seite 2), so dass man einen einfachen Zugriff auf die einzelnen Bauteile-Typnummern hat, (ohne jedesmal Augenkrebs zu bekommen, wenn man was nachschaut), danach die Datenblätter sämtlicher Bausteine sammeln, soweit möglich.
    Ich generiere mir dann immer ein Textfile, in dem ich sämtliche ICs aufnehme und innen in den IC sämtliche Pin-Bezeichnungen aus den Datenblättern übernehme. Dann bekommt man von großen Teilen der Platine (besonders von den ganzen Bussen) schon mal einen ganz guten Überblick und kann ausmachen, was u.U. verbunden sein kann (bei Prozessoren und Spezial-ICs sieht man wesentlich mehr, als auf dem beigefügten Beispiel). Das teste ich dann mit 'nem Pipser und trage gefundene Verbindungen in das Textfile ein. Irgendwann wird man sicherlich nicht umhin kommen einzelne Leiterbahnen auf der Platine zu verfolgen, aber mit Geduld und Spuke entstehen so nach und nach wesentliche Teile oder der komplette Schaltplan.

    Zitat von Georg

    stellen die 2016 den Bildschirmspeicher


    Wenn die Informationen hier stimmen, reichen die beiden Käfer nicht für den Bildspeicher.
    Bei einer Auflösung von 800x400 benötigen wir wenigstens 320000bit == 40kByte - die beiden Käfer geben nur 8kByte her.
    Der Rechner dürfte einen Grafik und einen Text-Modus haben, die beiden Käfer könnten durchaus ein Character-RAM im Text-Modus sein.
    Wenn sich unter den, auf dem Foto nicht identifizierbaren Bausteinen, nicht noch weiterer Speicher findet, wird der Grafikspeicher wohl den 256kByte DRAM rechts abgezweigt!?

    Zitat

    Man kann so sicherlich einen Zufallstreffer laden, wird aber, wenn man einfach auf Verdacht tauscht, häufig daneben liegen.


    Auslöten würde ich auf Verdacht keinen der Käfer.
    Der erste Schritt wäre mal das Ansehen mit dem Logiktester (im laufenden Betrieb).


    Gruß Jörg

    Ist das 40-Pin-IC links unten auf dem Foto eigentlich der 8086 (zumindest ich kann das nicht auf dem Foto erkennen)?
    Oder hat sich Victor von Fujitsu 'ne Special-Version "backen" lassen, die sich dann wohl eher hinter dem 48-pin-MB15619 verbirgt?
    Übel auf jeden Fall mal, dass über die beiden Fujitsu-Bausteine (MB15619/MB15620) nichts zu finden ist!
    Womöglich tatsächlich Spezialanfertigungen für Victor?

    Ich bin mir recht sicher, dass es sich bei den zwei mal 2kx8 SRAM um den char mem handelt. Normalerweise wird ein solcher Speicher zwischen den CRTC und die Videoausgabe geschaltet. Der SRAM wird dann wie eine Lookup-Table für den Zeichensatz verwendet. Der Fehler könnte also beim einlesen aus dem ROM, bei der Ansteuerung des SRAM durch die CPU oder den CRTC oder beim SRAM selbst liegen.


    -Jonas

    Danke für all die Ideen und Hinweise. Ich kann gar nicht so schnell reagieren, wie ich hier mit Ideen zugeworfen werde ;) - dazu fehlt mir einfach auch die Zeit.


    Den Thread "seltsame Karte" habe ich jetzt mal quergelesen, und in das TA1000-Projekt habe ich auch schon mal reingeschut. Wenn man die komplette Funktion eines Boards zu analysieren hat oder damit rechnen muss, immer mal wieder dran arbeiten zu müssen, weil sich dauernd Baustellen auftun, ist diese systematische Vorgehensweise sicherlich richtig.
    Ich werde aber zunächst mal gezielt die Stellen angehen, die "verdächtig" sind, d.h. alles rund um den 6845.


    Dafür hatte ich eben versucht, ein hochauflösendes, gut belichtetes und unverzerrtes Bild der Karte zu erhalten, indem ich sie auf den Scanner gelegt habe (eben damit ich nicht immer in den Keller muss, während ich die Sachen zusammensuche). Früher mit meinem alten Scanner hat das wunderbar funktioniert, der hatte locker über einen cm tief scharf abgebildet. Ist leider bei meinem modernen Gerät nicht mehr der Fall - die gesockelten Bauteile liegen auf der Glasplatte und sind schön scharf, aber schon die ungesockelten sind nicht mehr zu entziffern, von den Leiterbahnen gar nicht zu reden. Moderner Mist!! :( Und den alten habe ich natürlich längst entsorgt ...


    Immerhin habe ich den alten DOS-Rechner mit dem Eprommer ans Laufen gebracht und die Eproms ausgelesen. Ist zwar im Augenblick nicht wirklich hilfreich, aber musste sowieso mal gemacht werden. Irgendwo mitten drin habe ich auch schon etwas gefunden, was aussieht wie ein Zeichengenerator, aber das muss ich mir noch mal in Ruhe ansehen und Bits abmalen ... 8-)


    Gruß
    Georg


    PS. Ja, links unten ist ein ganz normaler Intel 8086. Die beiden Fujitsu-Teile sind übrigens auch einer der Gründe, weshalb ich nicht den Ehrgeiz habe, das ganze Ding zu analysieren und zu verstehen.


    Fritz: Danke für die Links und besonders den Artikel. Einiges davon hatte ich bei meiner Suche auch schon gefunden - es gibt vieles zur Programmierung des 6845, aber ich wollte gerne mal ein paar typische Beschaltungen finden - das ist arg schwierig. Allerdings ist das Blockdiagramm schon ziemlich detailliert, und ein paar Beispiele habe ich ja doch schon gefunden.
    Was die Informationen zum Sirius/Victor 9000 angeht habe ich langsam den Verdacht, dass die Maschinen zwar kompatibel sind, sich aber in der Technik deutlich unterscheiden. Von daher muss man aufpassen, nicht völlig falsche Schlüsse zu ziehen.

    Zitat von stynx

    Der Fehler könnte also beim einlesen aus dem ROM, bei der Ansteuerung des SRAM durch die CPU oder den CRTC oder beim SRAM selbst liegen.


    Wie oben schon mal erwähnt, ist der Fehlerraum groß und er könnte durchaus in den genannten Gebieten liegen.
    Ich würde mich dennoch zunächst auf den Bereich konzentrieren, wo die 8 Bit serialisiert werden bis hin zu der Stelle, wo der Cursor dazugemixt wird.
    Wenn der Fehler vor der Serialisierung liegen würde, müsste er der Gestalt sein, dass er auf allen 8 Datenleitungen über die ganze Zeit "schwarz" produziert.
    An der Serialisierungsstelle und danach genügt ein einfacher Fehler, um das Feherlbild hervorzurufen - z.B. genügt es, wenn die Shiftclock fehlt - oder der ShiftOut-Pin hinüber ist - oder die Leitung zum Mixer einen Riss hat - ...

    Einmal editiert, zuletzt von dlchnr ()

    Zitat von Georg

    Ich werde aber zunächst mal gezielt die Stellen angehen, die "verdächtig" sind, d.h. alles rund um den 6845.


    Also in dem Fall würde ich erst mal schauen, wo das Cursor-Signal (6845-Pin19) überall hingeht, um den Mixer zu identifizieren (der steckt hoffentlich nicht im MB15619 oder MB15620) - von da aus könnte man sich auf dem eigentlichen Bildsignalpfad dann rückwärts bewegen.

    Zitat von dlchnr

    Also das könnte sehr hilfreich sein - das SRAM dürfte dann doch dem "Screen Memory" zuzuordnen sein


    Statt des ROM wird 'einfach' ein SRAM verwendet. Eventuell wird einer der beiden SRAMS von der CPU gefüllt und dann in einem Takt gegen das andere 'ausgetauscht'?
    Oder das beschreiben findet in der Austastlücke statt...


    EDIT: Ich habe eine leicht modifizierte Datei angehängt. Die Ansteuerung des SRAM von der CPU aus wird natürlich etwas komplizierter sein als dargestellt.

    Das das SRAM ein "Character-RAM" sein kann, hatte ich ja schon in Beitrag 12 erwähnt - die gewisse Skepsis von Beitrag 15 entstand, weil das SRAM in der "victor9000.pdf"-Datei in einem Zug mit den 128kByte RAM und den 16kByte ROM genannt wird, und nicht in Verbindung mit der Grafik oder dem CRT.
    Das Block Diagramm des Victor 9000 ordnet das SRAM aber gnaz klar der Grafik zu, so dass man davon ausgehen kann, dass das beim Vicki auch so ist.
    "Ausgetauscht" wird da ziemlich sicher nichts - Austastlücke oder ein Zeitmuliplexing werden das Beschreiben der SRAMs möglich machen.

    Zitat von dlchnr

    Das das SRAM ein "Character-RAM" sein kann, hatte ich ja schon in Beitrag 12 erwähnt - die gewisse Skepsis von Beitrag 15 entstand, weil das SRAM in der "victor9000.pdf"-Datei in einem Zug mit den 128kByte RAM und den 16kByte ROM genannt wird, und nicht in Verbindung mit der Grafik oder dem CRT.
    Das Block Diagramm des Victor 9000 ordnet das SRAM aber gnaz klar der Grafik zu, so dass man davon ausgehen kann, dass das beim Vicki auch so ist.
    "Ausgetauscht" wird da ziemlich sicher nichts - Austastlücke oder ein Zeitmuliplexing werden das Beschreiben der SRAMs möglich machen.


    Es ist mitunter einfacher ein 'dual-port' Ram zu simulieren, indem man einfach 2 komplette Ramblöcke vorhält und diese bei bedarf ein und aus wechseln kann.
    Es ergibt für mich keinen Sinn 4k char-Ram zu integrieren. 2k reichen für 256 8x8 Zeichen... ausser man will 16x8 Zeichen verwenden können.


    Meine Spekulation geht in die Richtung, dass 2 komplette Zeichensätze vorgehalten werden können. Immer einer (video) aktiv für den CRTC und einer (video) inaktiv erreichbar für die CPU. Per 'Befehl' wird dann der Zeichensatz-ram gewechselt... alles andere ist stark von Timing abhängig und macht eine Ansteuerung komplizierter. Wang Sirius Systems Technology hätte sicher die technisch einfachere (aber teurere) Technik gewählt, da sich das Gerät ja nicht im Hobbymarkt verkaufen sollte.


    Aber ohne Schaltplan ist das alles Spekulation ;)


    -Jonas

    Zitat von stynx

    "Wieso Wang ? Hab ich da was nicht mitbekommen ?"


    Ich meinte natürlich Sirius Systems Technology :rotwerd: ... ich hatte irgendwie das Usericon (s.o.) im Kopf ...


    -Jonas



    Genau GEORG <=> WANG :tüdeldü:


    DAS wahren noch tolle Zeiten als wir zusammen gebastelt haben :thumbup:
    Im Vordergrund die WANG ...



    Korrektur: eine der WANG von Georg.

    Hallo Jungs,


    freut mich, dass Ihr Euch mein Problem so zu Herzen nehmt und so intensiv die Architektur dieser Maschine erörtert. :thumbup:


    Es sind tatsächlich eine Menge Fragen offen, und die fehlende Doku bietet reichlich Gelegenheit zur Spekulation. Alles sehr interessant, aber ich fürchte, in Beitrag 21 ist schon das dringendste Problem angesprochen worden:


    Auf dem ganzen Board findet sich kein Schieberegister, wie es für die Bilderzeugung nötig wäre. Die interessanten Leitungen (Pin 19, Cursor oder Pin 21, Clk) sind von unten angebunden - da muss ich das Board noch mal rausbauen und von unten analysieren. :(
    Nicht dass dlchnr mit seiner Befürchtung Recht hat ...


    OT: Sorry, dass ich Euch mit meinem Icon/Avatar/wasauchimmer schon durcheinander bringe .. :P
    Das leuchtende Logo hat mir ein Freund aus dem Forum mal auf seiner Fräsmaschine geschnitzt - danke, Heiko!
    Hinterlässt wirklich Eindruck, nicht wahr, Jonas? :tüdeldü:


    Georg

    Zitat von stynx

    Aber ohne Schaltplan ist das alles Spekulation


    Naja, vielleicht stellt Georg ja irgendeine Form von Bestückungsplan ein - dann können wir schon mal weiter spekulieren.
    Was mich schon mal iritiert - unter den ICs, die ich entziffern konnte, finde ich kein Schieberegister - und arg viele sind es nicht, die ich nicht identifizieren konnte.

    Einmal editiert, zuletzt von dlchnr ()