Posts by Georg

Ich komme mir vor, wie die Königskinder, die nicht zueinander finden

Können wir uns mal einigen, was wir unter Bild(schirm)speicher verstehen?

Für mich ist das immer das SRAM. Auch wenn im Grafikmodus darin sicherlich nichts steht, was irgendwie mit dem Inhalt des Bildschirms zu tun hat. Und das Character-RAM liegt im Hauptspeicher - auch wenn im Grafikmodus dort keine "Zeichenaufbauinformationen" liegen.

Ich bin halt eindeutig textorientiert; liegt vermutlich daran, dass ich aktuell nur den Textmodus der Vicki untersuche.

Dagegen scheint für Dich der Begriff Bildspeicher grundsätzlich den Speicherbereich zu benennen, der das Aussehen des Bildschirms bestimmt, und das ist je nach Modus mal das SRAM (Textmodus), mal die 40k Hauptspeicher (Grafikmodus).

Quote from dlchnr

man muss nur verstehen, was der andere meint - ich hatte immer den Eindruck, dass bei Dir das, was ich als LUT bezeichne, auch unter Bldlspeicher läuft.

Richtig - was im Textmodus vermutlich auch bei Dir zu keinem Widerspruch führt.

So, jetzt noch kurz zum Thema Refresh:
Ich hatte das bisher nie angeschnitten und möchte mich damit eigentlich auch gar nicht beschäftigen. Die SRAMs (Bildschirmspeicher ) brauchen keinen Refresh, und der Hauptspeicher muss so oder so refreshed werden - nicht nur die 4K-40K, mit denen der CRTC (indirekt) zu tun hat (und der in der Standardapplikation eh ein ROM ist).

Das kommt durch die unglückliche (antike) Terminologie in dem Datenblatt: Der Videospeicher muss periodisch den Bildschirm "auffrischen" und heißt deshalb in dem Papier Refresh Memory. Hat mit dem Thema Speicherrefresh oder DRAM zunächst mal gar nichts zu tun - wobei ich auch im Kopf hatte, dass der 6845 - wie Du beschrieben hast - als Nebenprodukt seinen *Videospeicher* (d.h. die max. 16 KB), so es sich denn um DRAM handelt, tatsächlich mit einem "Speicherrefresh" versorgen kann. Ist aber egal, wichtig ist der Unterschied: refresh memory (dient zur Auffrischung des Bildes) vs. memory refresh (frischt den Speicher auf).

Schau mal in mein Posting, ich habe extra den aus dem Original zitierten Begriff "Refresh Memory" übersetzt (natürlich wieder mit Bildschirmspeicher - Georg ist im Textmodus), weil ich selber schon drüber gestolpert war ...
Ich wollte genau diese Verwirrung vermeiden, wollte aber auch das Zitat nicht verändern

Quote from dlchnr

??? Nicht gut, zwei anscheinend unterschiedliche Dinge mit dem gleichen Namen ("Bildschirmspeicher") zu belegen.

Ich weiß, es liest sich sperrig, aber ich denke, dass ich es richtig geschrieben habe. Bildschirmspeicher (im Datenblatt Refresh Memory) ist der Speicher, wo ein zeichenbasiertes Videosystem seine Inhalte anlegt, d.h wenn auf dem Bildschirm links oben "Hallo Welt!" erscheinen soll, steht am Anfang des Bildschirmspeicher so was wie

48h, 61h, 6Ch, 6Ch, 6Fh, 20h, etc.

Für "das andere" habe ich einigermaßen konsequent den Begriff Character-RAM bzw. -ROM genutzt - dort steht eben, dass das Zeichen 48h (z.B.) so aussieht:

00000000b, 11000110b, 11000110b, 11111110b, 11000110b, 11000110b, 00000000b

Jetzt noch mal mein Satz von oben:

"Nein, nur die Adressen für die Zeichen(-codes) im Bildschirmspeicher. Die Adressen für die Zeichendarstellung (Character-RAM) kommen i.W. aus den Daten des Bildschirmspeichers."

Ich benutze zwar zwei mal den Begriff Bildschirmspeicher, aber einmal rede ich von dessen Adresse, und beim zweiten mal von seinen Daten:

CRTC liefert die Adressen für die Codes -> Bildschirmspeicher.
Bildschirmspeicher liefert Daten - diese dienen als Adressen für die Zeichendarstellung -> Character-RAM.

Hi,

da liegen wohl zwei ziemlich unterschiedliche Vorstellungen von der Funktion und den Fähigkeiten des 6845 vor, und ich fürchte, dass wir darüber das Ziel etwas aus den Augen verlieren.

Offensichtlich gibt es einen zentralen Punkt, an dem wir auseinander laufen:

Quote from dlchnr

eigentlich möchte der 6845 mit seinem Buszugriff eine Zelle im Hauptspeicher adressieren, indem er die nächste Adresse zum Adressieren des Character-RAMs/ROMs findet - diese Adresse befördert er über seine Datenleitungen an das Character-RAM/ROM.

Ich lese das so, dass der 6845 eine Adresse ausgibt, um das unter dieser Adresse befindliche Byte (mit Hilfe seines Datenports) zu lesen und in einem zweiten Schritt (wieder über seinen Datenport) an das Character-ROM/RAM zu schicken.

Das lese ich im Datenblatt anders. Dort steht z.B. in der Einleitung:
"The CRTC provides video timing and refresh memory adressing." (Mit refresh memory ist der Bildschirmspeicher gemeint.)

Und in der Beispielapplikation aus, die Du im Posting 6 angehängt hast, werden ebenfalls die Datenausgänge des Refresh RAM/Bildschirmspeichers direkt über ein Latch an das Character-ROM geliefert; der CRTC liefert nur 4 Rasterzeilenadressen dazu.

Immerhin scheinen wir uns (bis auf evtl. Begrifflichkeiten) einigermaßen einig darüber zu sein, wie der 6845 im Victor/Vicki eingesetzt wird. Ich denke, das sollte die Basis für die weitere Fehlersuche sein

Im Übrigen finde ich Deine Unterstützung großartig und freue mich immer wieder über neue Impulse von Dir.

Georg

Danke für Deine Gedanken und Deine Zeit. Leider bin ich nicht sicher, ob ich Dich 100% verstanden habe; an einigen Stellen kann ich Dir folgen, an einigen anderen habe ich inzwischen andere Eindrücke bekommen.

Ich versuche es mal Schritt für Schritt.

Quote from dlchnr

Soweit ich den 6845 bislang überblicke, ist er eigentlich dafür gedacht, Character mittels eines Character-RAMs/ROMs auf den CRT zu bringen.

Klar, aber nicht dass dadurch der Eindruck entsteht, der 6845 liefert diese Zeichen in irgendeiner Form selber aus. Er produziert nur das Timing. Das ist zunächst der äußere "Rahmen" in Form von HSYNC und VSYNC, und innerhalb dieses Rahmens liefert er zu jedem Zeitpunkt die Information: "Jetzt muss von dem Zeichen, dass an Adresse x im Bildschirmspeicher steht, die soundsovielte Rasterzeile ausgegeben werden."
(Abgesehen von Zusatzfunktionen wie Cursor, Lichtgriffeleingang etc.)

Quote from dlchnr

Victor hat den wohl etwas vergewaltigt, indem es ihn als Adress-Generator benutzt, dessen ausgegebene Adressen zum Teil mittels einer LUT (die beiden SRAMs) "übersetzt" werden, so dass nun die Character aus dem Hauptspeicher geholt werden können.

Funktional gesehen stimme ich Dir zu, würde das aber nicht als Vergewaltigung sehen. Das ist meiner Meinung nach seine ganz normale Aufgabe. Die Abweichung besteht im Wesentlichen darin, dass sich üblicherweise der Bildschirmspeicher eher im Hauptspeicher befindet und das Character-ROM (Zeichengenerator) außerhalb. Hier ist es umgedreht. Und ob man den Zeichengenerator als Lookup-Table bezeichnen kann mag ich nicht entscheiden: Tatsache ist bei alle Designs, die ich kenne, dass der 6845 die Adresse eines Zeichens (im Bildschirmspeicher) ausgibt; die Daten, die dort gefunden werden (in der Regel ein erweiterter 8-Bit-ASCII-Code, aber dann ist man auf 256 Zeichen beschränkt, und Victor wollte mehr), dienen dann wieder als (oberer Teil der) Adresse der "Zeichenmatrix" im Character-ROM.
Die fehlenden unteren Bits (nämlich genau die Information, welche Zeile der Zeichenmatrix uns gerade interessiert), liefert der 6845 parallel an seinen Row-Address-Ausgängen.
Der Zeichencode stellt also "im Wesentlichen" die Adresse für das Character-ROM, und die Ausgangsdaten des ROMs gehen zum Schieberegister zwecks Serialisierung.
Victor macht's im Grunde genauso; nur dass nicht der reine ASCII-Code zur Adressierung des Character-RAMs genutzt wird, sondern ein erweiterter Code (der sich aber für den "normalen" Zeichensatz aus dem ASCII-Code errechnen lässt) und der gleichzeitig berücksichtigt, dass die Adressen des Zeichengenerators - anders als bei einem eigenständigen ROM - quasi irgendwo mitten im Adressraum der CPU liegen.

Quote from dlchnr

Dazu müssen nun aber aus einem einzelnen 6845-Zugriff zwei Zugriffe für den Hauptspeicher generiert werden, damit aus zwei 8-Bit-Werten ein 16-Bit-Wert entsteht, von dem 11 Bit ins Schieberegister transferiert werden. Das" aus-ein-macht-zwei-Zugriffe" wird wohl von den Fujitsu-Bausteinen erledigt.

Das halte ich für ein grundlegendes Missverständnis, denn der 6845 greift überhaupt nicht auf den Hauptspeicher zu. Er adressiert zwar Positionen im Hauptspeicher (allgemein: im Bildschirmspeicher), aber die dort stehenden Informationen lässt er andere Teile der Logik bearbeiten - wie geschrieben, werden die gefundenen Daten (je nach System eben 8 oder 16 Bit breit oder auch nur Teile davon) einfach als Adresse an das Character-ROM/RAM angelegt.
Die Datenleitungen, die der 6845 durchaus hat, dienen nur dem Beschreiben und ggfs. Lesen der Register.

Quote from dlchnr

Mit diesem Konzept ist es dann möglich, einen Art Graphikmodus zu generieren - wenn in der LUT unter jeder Adresse die Adresse selbst eingetragen wird, fliegt diese quasi raus - der Bildspeicher kann dann als fast-Graphikspeicher dienen - fast deshalb, weil er wg. der nur genutzten 11bit etwas "löchrig" ist.

Da stimme ich halbwegs zu, allerdings sind die tatsächlich noch etwas geschickter drangegangen. Zunächst einmal wird wirklich das gleiche Konzept wie im Textmodus verwendet, allerdings wird im Grafikmodus der Bildschirmspeicher mit 1250 "Zeichen" gefüllt, die alle einen anderen Code haben (das ist vermutlich das, was Du mit "unter jeder Adresse die Adresse selbst" meinst). Im Wesentlichen zeigen dann diese 1250 Zeichen dauerhaft auf 1250 aufeinanderfolgende, voneinander unabhängige "Zeichenbeschreibungen" im Hauptspeicher. Dort wird dann die Grafik erzeugt. Also eine etwas ungewöhnliche Logik: Der Inhalt des Bildschirmspeichers bleibt konstant, dafür wird ständig der "Zeichengenerator" den Erfordernissen angepasst. Im Hauptspeicher liegt tatsächlich ein lineares Bild aller Pixel auf dem Bildschirm. Löcher entstehen deshalb nicht, weil im Grafikmodus alle 16 Bit des "Zeichengenerators" genutzt werden (das ist wohl der von Dir vermutete "Hack"). Deshalb kommen die auch mit 1250 "Zeichen" aus: Diese Zeichen habe 16 Pixel Höhe (wie immer), aber jetzt 16 Pixel Breite.
256 Pixel/"Zeichen" * 1250 Pixel sind genau die 320.000 Pixel, die im 800*400 Modus möglich sind.
U.A. muss aber deshalb das Schieberegister sowohl 10 Bit (Zeichenbreite im Textmodus) als auch 16 Bit ("Zeichen"breite im Grafikmodus) schieben können.

Quote from dlchnr

Das für das Problem aber entscheidende ist - die Adressen kommen letztlich immer vom 6845!

Nein, nur die Adressen für die Zeichen(-codes) im Bildschirmspeicher. Die Adressen für die Zeichendarstellung (Character-RAM) kommen i.W. aus den Daten des Bildschirmspeichers.
Und dazwischen und rundherum sind noch eine Menge Register und Bustreiber und Multiplexer und was weiß ich noch für Zeugs, die u.A. ja etwas Adressarithmetik, Entkoppelung von der CPU etc. machen müssen. In meinen Augen auch viele Kandidaten für einen Fehler.

Sorry für den Umfang; ich hoffe, es war noch lesber. Ich habe grundsätzlich Probleme, komplexe Sachverhalte mit wenigen Worten treffend zu beschreiben.

Nachtrag: Ich habe jetzt den Dump des Bildschirmspeichers während der Anzeige des Format-Befehls analysiert und zurückübersetzt, inklusive der Attribute (siehe Anhang).

Ganz offensichtlich bildet die Maschine den richtigen Speicherausschnitt ab (d.h. der CRTC gibt die richtigen Adressen aus), und die dort eingetragenen Werte stimmen.
Also kann eigentlich nur die nachfolgende Logik, die aus diesen Zeigern nun das Futter für das Schieberegister sucht, defekt sein.

Aus den 16 Bit einer Bildschirmzelle werden die 11 unteren Bits genommen, um 5 Positionen nach links verschoben, mit den 4 Bits RA0-RA3 des CRTC (mit dem er die Rasterzeilen durchzählt) sowie einer folgenden 0 ergänzt. Das ergibt dann das Wort aus der Zeichensatztabelle, dessen untere 10 Bits die Bildpunkte des Buchstabens für die aktuelle Rasterzeile liefern:

• ccccccccccc sind die 11 Bits aus dem Bildschirmspeicher, die das Zeichen definieren
• rrrr sind die 4 Bits des CRTC, mit denen eine von 16 Rasterzeilen ausgewählt wird
• 0000 cccc cccc ccc0 0000 ist dann die Basisadresse einer Zeichendefinition (ein 16 x 16 Bit großer Block) und
• 0000 cccc cccc cccr rrr0 ist die Wortadresse des Pixelmusters in der aktuellen Rasterzeile des aktuellen Buchstabens

Irgendwo auf diesem Weg scheint was schief zu gehen.

Auffallend ist, dass der Hintergrund beim Format-Programm, der ja auch nur aus Leerzeichen besteht, plötzlich anders aussieht, als sonst unter DOS (da ist alles schwarz, d.h. das Pixelmuster ist 0x0000). Da der Zeiger der Gleiche ist, wird sich vermutlich das Ziel verändert haben. Ich schließe daraus, dass die errechneten Adressen statt im Zeichengenerator irgendwo dort im Hauptspeicher landen, wohin die Programme geladen werden!

Ein neues Update und vielleicht noch was zum Grübeln.

Die Speicherdumps über die serielle Leitung haben mir einige wichtige Hinweise gegeben:

• Der Zeichensatz liegt vollständig, und soweit ich das aus der Doku entnehmen kann, an der richtigen Stelle im RAM. Einen Dump des Logos und des Zeichensatzes habe ich angehängt.
• Der Bildschirmspeicher (0xF000 - 0xF0F9F) enthält (nach dem Start von DOS) auf Anhieb seltsame Werte, die aber nach etwas Überlegung völlig korrekt sind und mit der nötigen Bitfriemelei (Berücksichtigung Basisadresse, Anhängen der Rasterzeilen-Adressbits) genau an die richtigen Stellen in der Zeichentabelle zeigen.
• Wenn man das Programm FORMAT startet, wird der Bildschirmspeicher direkt beschrieben. Auf dem Bildschirm erscheinen Muster, die den Eindruck vermitteln, dass hier evtl. tatsächlich der Bildschirmspeicher abgebildet wird (siehe Anhang).

Der letzte Punkt ist besonders interessant. Entweder werden im Bildschirmspeicher falsche Zeiger eingetragen (muss ich noch prüfen, habe ich bisher nur für den leeren DOS-Bildschirm gemacht), oder die Zeiger werden falsch verarbeitet und zeigen nicht auf die Zeichentabelle, oder die Daten der Zeichentabelle werden falsch verarbeitet.

Da aber im 132-Zeichen-Modus vieles wieder recht gut aussieht, weiß ich nicht, was ich glauben soll. Hier richtet sich mein Verdacht eher wieder auf den CRTC aufgrund seiner falschen Konfiguration (25 x 80 Zeichen á 10 x 16 Pixel statt 50 x 132 Zeichen á 6 x 8 Pixel).

Es bleibt rätselhaft ...

Great News!!

Sie redet mit mir!!

Also der Reihe nach:
Mit com1 hatte es ja nicht funktioniert, und dann hatte ich alles mögliche ausprobiert: tty, aux, porta, portb, ser usw. Da ich das alles im Blindflug mache, hatte ich natürlich keine Ahnung, was daran jetzt verkehrt war. Ich war ja schon der Meinung, die Vicky kennt den CTTY Befehl nicht.
Wobei aux ganz gut aussah (wenn ich etwas dahin kopiert habe, hat sie was gemacht und nicht nur versucht, auf Diskette zu schreiben - allerdings kam am seriellen Port nichts an).

Kurz und gut, ich habe nochmal alle für den Victor/Sirius verfügbaren Handbücher studiert. Dort sind an einer Stelle explizit die "benannten" Geräte aufgeführt: "AUXIN, AUXOUT, LST, PRN, CON". Die haben mir aber nicht geholfen. Und dann habe ich in einem Syntaxbeispiel ein Gerät SERIALA gefunden - und das wars dann.

CTTY SERIALA - und wir können es miteinander. Sozusagen headless

Jetzt habe ich meine Disketten untersucht, ob da was hilfreiches drauf ist, und habe zumindest ein MSBASIC (das komplett über DOS geht, und deshalb mit der Umleitung zurechtkommt) und vor allem einen SID gefunden.

Mit letzterem habe ich auch schon etwas im System rumgestochert - wenn ich den Bildschirmspeicher (der mit ganz komischen Sachen gefüllt ist ) mutwillig mit irgendeinem Mist beschreibe, passiert tatsächlich was auf dem Bildschirm. Allerdings erscheinen keine "Zeichen", sondern ich ändere zunächst mal nur die Attribute (invers in verschiedenen Helligkeiten). Aber immerhin ...

Momentan ziehe ich mir einen kompletten Speicherdump über die serielle Schnittstelle auf meinen Host - da kann ich dann in Ruhe und mit besserem Werkzeug weitersuchen.

Achja - ich wollte doch die Laufwerke singen hören. Das klappt noch nicht; der Format-Befehl arbeitet interaktiv und präsentiert ein Menü - allerdings schreibt er direkt in den Bildschirmspeicher, und somit konnte ich zunächst mal nichts mit anfangen.
Immerhin hat sich bei der Gelegenheit etwas auf dem Bildschirm getan - es sind zwar nur wilde Muster, aber es sind Muster. Nicht mehr nur schwarze oder grüne Blöcke. Ich denke, jetzt kann ich einigermaßen gezielt weitersuchen.

Leider habe ich jetzt wieder einen Termin, aber ich melde mich, wenn es weitergeht. Dann gibt's vielleicht auch ein paar Bilder.

Quote from retro64

Also ein Sirius hat 2 serielle Schnittstellen: PortA und PortB
und eine paralle Schnittstelle: PPORT

SIW ist für die Verwendung von PORTSET das Laden der Trieber (PORTA und/oder PORTB) notwendig.

Danke, aber die waren zum Glück schon in meinen Konfigurationsdateien (CONFIG.SYS und CONFIG.BAT) drin. Wobei der PORTSET gar nicht nötig ist; die Einstellungen kann man dem Treiber beim Laden mitgeben. Den braucht man wohl, wenn man die Einstellungen später ändern will.

Grüße und Danke in die Runde für die Unterstützung und Motivation
Georg

Quote from fritzeflink

Ich habe obigen Text aufmerksam gelesen und abgespeichert.

Nein, ich möchte nichts haben, außer.... Genie,Genie,Genie,Genie,Genie,Genie,Genie,Genie,Genie,Genie,Genie,Genie,Genie,Genie,.....

aber ich denke du gibst ja eh nur diese riesengroßen Kisten ab wo Mann einen Laster zum Transport braucht...

Lieber Fritz,

der zitierte Satz galt eindeutig Klaus und vielleicht einer IBM-Maschine ^^ . Ich bin noch nicht soweit, dass ich hier räumen muss

Und Genie, Genie, Genie, ... hab' ich nicht, das weißt Du doch

Georg

Quote from DerIBMSammler

Hallo Georg!
Hast du schon einmal geschaut, ob du dich von etwas trennen kannst?

Hallo Klaus,

entschuldige die verzögerten Antworten, ich habe im Augenblick einiges anderes im Kopf :

Ich war letztens kurz im Lager und habe einen schnellen Blick in die IBM-Ecke geworfen. Wenn ich mich nicht getäuscht habe standen da zwei ATs im Regal - also gute Chancen für Dich. Allerdings musst Du Dich noch etwas gedulden, bis ich die Zeit finde, das mal hervorzuholen und auszuprobieren.

Ist aber nicht vergessen!

Gruß
Georg

Quote from map

Ich weiss was Du meinst, bei unseren Versuchen spielte das aber keine Rolle. Die alten Folien taten es ausnahmslos, selbst die, die am Schlimmsten aussahen (siehe Space-Tasten-Pad bei den Fotos im anderen Posting).

Wenn ich mir Eure Bilder ansehe glaube ich Dir gerne.
Ich habe aber den Eindruck, das die Plättchen bei mir in deutlich schlechterem Zustand waren. Ich habe noch mal ein Bild angehängt - ist leider nicht superscharf, aber auf der rechten Folie kann man die fleckige Beschichtung erkennen, in der Mitte ist es schon schlechter, und links sieht es eigentlich wie durchsichtige Folie aus. Keine Ahnung, wohin die Beschichtung "verdampft" ist.
Dagegen sehen Eure deutlich besser (und irgendwie auch stabiler ) aus.

Georg

Ich habe noch mal in meinen Bildern und Unterlagen nachgeschaut. Hier ein Auszug aus meinen frühen Notizen:
"Ergebnis: Die Schaumstoffplättchen werden mürbe....

Dicke eines "guten" Plättchens: ca. 4 mm
Dicke eines "schlechten" Plättchens: ab 3 mm abwärts
Durchmesser: 11 mm

Die Folie, die den Kondensator bildet (d.h. die auf die Platine gedrückt wird) und die in den englischen Quellen mit Mylar bezeichnet wird, ist weich und dünner als die obere Folie, die das Plättchen in der Tastenkappe hält. Sie ist definitiv nicht leitend!

Bei weiteren Versuchen mit einem der freigelegten Mylarplättchen stellt sich heraus, dass das Problem nicht nur die Schaumstoffpolster sind, sondern vermutlich die metallische Beschichtung der Mylar-Folien, die verloren geht. Das kann man bei verschiedenen Tasten auch optisch erkennen. Der Verlust ist sehr unterschiedlich, von fast gar nicht über partiell bis völlig frei.

Bei Tests mit Ersatzmaterial stellt sich heraus, dass die Variante mit Tesa-kaschierter Alufolie durchaus funktioniert. Noch besser ist allerdings die Rettungsdecke (goldene Seite zur Platine; die silberne leitet!!).
Allerdings fehlt mir noch ein hinreichend weicher Schaumstoff - der vorhandene Isolierstreifen ist mit 5 mm nicht nur zu dick, sondern auch zu hart. Es funktioniert zwar, aber der Tastenweg ist zu kurz und das Gefühl sehr schwammig, weil kein mechanischer Anschlag wirksam wird.

Zwecks Reinigung wurden dann noch alle Tasten aus der Befestigungsplatte heraus gelöst. Das geht recht einfach, wenn die Taste gedrückt wird und gleichzeitig die Rastnasen eingedrückt werden (auch nacheinander). Insgesamt handelt es sich um 91 Tasten."

Vielleicht hilft es etwas. Leider habe ich mir nicht notiert, welchen Schaumstaff ich schließlich verwendet habe, und wie die andere Seite beschaffen war (dort muss auch eine Folie sein, die das Ganze im Tastenkörper festklemmt). Ich meine, ich hätte einen Dichtstreifen genommen, der auf der einen Seite mit doppelseitigem Klebeband und auf der anderen Seite mit einer passenden Schutzfolie kaschiert war. Damit hielt sich mein Aufwand in Grenzen.

Quote from retro64

1) Bei mir ist der Cursor im 132-Mode ein Block, der aber höher als eine Zeile ist (siehe Foto)
2) hab bisher seriell nur Kermit gearbeitet - da geht das direkt. DOS-pur gibt es das "PORTSET" Kommando. Daraus ableitend würde ich für den Device-Namen auf "porta" oder "portb" tippen (ist aber ein blinder Versuch...)

Danke für die Rückmeldung, und besonders für die Bilder. Da sieht man schon mal, worauf man sich freuen kann

Das mit dem Block und der Größe war mir wichtig, denn das bedeutet, dass bei der Umschaltung in den 132-Zeichen-Modus auf jeden Fall der Cursor umprogrammiert werden muss (Anfangs- und Endzeile) - und das ganz offenbar bei mir auch nicht passiert.

Für die serielle Schnittstelle habe ich momentan das Gerät "AUX" im Verdacht, aber das muss ich erst noch verifizieren. Bin jetzt zwei Tage nicht bei der Vicki gewesen.
Ich werde es auch mal mit PORTA oder PORTB versuchen (wobei die Vicki nur eine serielle hat) . Auf der Diskette sind mir zwei Programme PORTA.EXE und PORTB.EXE aufgefallen - PORTA.EXE liegt im Wurzelverzeichnis, PORTB.EXE im Unterverzeichnis DOS. Zusätzlich gibt es das Programm PPORT.EXE - mir ist noch nicht ganz klar, was ich davon halten soll. Umleitung der Druckerausgabe? Konfiguration geht wohl auch bei der Vicki mit PORTSET.COM.

Quote from dlchnr

Der Cursor befindet sich auf beiden Bilder in einer Zeile ohne Buchstaben mit Unterlänge, also ohne g, p, q, etc. - wenn ich davon ausgehe, dass die Buchstaben nicht die komplette Zeilenhöhe einnehmen (also z.B. die oberste und die unterste Pixelreihe schwarz ist), damit die Buchstaben verschiedener Zeilen nicht aneinander stossen, könnte der Cursor vielleicht doch genau die Höhe einer Zeile haben!?

Quote from dlchnr

Wenn man die neuen Bilder mit den Bild aus Beitrag 40 vergleicht, fällt auch auf, dass die Basis des Cursor an unterschiedlichen Stellen liegt - einmal eher auf der Unterlängenlinie, bei Georg auf der Grundlinie.

Da gebe ich Dir weitgehend recht, allerdings fangen die Buchstaben ganz offensichtlich am oberen Rand der "Zelle" an (bündig mit dem Cursor), darunter ist eine Zeile für eine angedeutete Unterlänge (sieh' Dir das y in byte an), und dann noch eine Rasterzeile als Abstand zur nächsten Bildschirmzeile.

Bei 132*50 ist alles ziemlich eng; in der Breite hat eine Zelle gerade mal 800/132=6 Pixel, in der Höhe 400/50=8 Pixel. Bleiben nach Abzug von "Luft" und Unterlänge eine Matrix von 5*6 für die Großbuchstaben. Ist knapp, geht aber.

Der Cursor füllt dagegen die ganze Zelle, ist also 6*8 groß.
Wichtig, auch wenn man es den Bildern nicht auf Anhieb ansieht: Mein Cursor ist viel größer, denn der hat noch das 80x25-Format von 10*14 Pixeln.

Noch eine kurze Aktualisierung: Mit Hilfe des 132-Zeichen-Modus und des konstanten Versatzes habe ich jetzt auch das DOS-Verzeichnis meiner Floppy "dekodiert":

.            <DIR>      8.04.91  13.15
..           <DIR>      8.04.91  13:15
PORTB    EXE     3584   7.02.84  14.12
FORMAT   DAT     1934  19.07.83  13.04
FORMAT   EXE    39377   9.01.84  14.37
CHKDSK   COM     6480  25.01.84  12.30
PRINT    COM     3808  25.01.84  11.17
RECOVER  COM     2304  25.01.84  12.46
MORE     COM     4368  25.01.84  12.45
DISKCOPY COM    16817  13.01.84   8.38
FIND     EXE     6331  25.01.84  12.41
MODCON   EXE    14738   7.02.84   9.12
MSBASIC  COM    31744   9.06.83  13.35
FILCOM   EXE     2585  25.01.84  11.17
EDLIN    COM     8080  25.01.84  12.36
PORTSET  COM     6144   3.02.84  13.34
MV       EXE    30936  23.11.83  11.30
FGREP    EXE    31080  23.11.83  11.30
SEARCH   EXE    53016   9.01.84  12.33
LS       EXE    31480  23.11.83  11.31
EXESIZE  EXE     1371  13.02.84  12.09
DISKID1          4096   5.03.84  13.10
SYS      EXE    20481  30.01.84  18.37
SORT     EXE     1632  25.01.84  12.48
132C     COM    47321  11.01.84  16.55
132ON    COM      273  10.01.83  13.25
132OFF   COM      273  10.10.83  13.27
CPM      EXE     5632  20.09.83  14.58
DISKID2          2065   1.01.80   0.36
RDCPM    COM    11214  21.11.83  11.33
CALC     COM     4917  23.08.82   1.03
CONCAT   EXE    26216  23.11.83  11.33
TAIL     EXE    30712  23.11.83  11.33
WC       EXE    28184  23.11.83  11.34
       34 File(s)    559104 bytes free

Und dann habe ich mich weiter im ROM umgesehen; und muss zumindest eine Fehleinschätzung :rotwerd: zugeben: Es befindet sich doch ein Zeichensatz drin, allerdings (bisher) nur ein rudimentärer.
Ich habe aufeinanderfolgend die Ziffern 0-9 und die Buchstaben A-F gefunden (ich schätze für Fehlermeldungen mit Adressangaben), dann kommen zwei Zeichen, die zusammen ein Diskettensymbol ergeben und nochmal zwei Zeichen, die einen Pfeil darstellen - also die Symbole, die beim Start ohne Diskette normalerweise angezeigt werden. Es folgen auch noch ein paar weitere Zeichen, aber die habe ich noch nicht analysiert. Liefere ich nach ....

Quote from dlchnr

Der Vorschlag, erst das ROM zu verifizieren mache ich nicht, weil ich den Fehler mit größerer Wahrscheinlichkeit im ROM erwarten würde, sondern weil es einfach viel einfacher ist als das Auslöten (vorausgesetzt, es steht eine Reference zur Verfügung).

Klar, ist ein triftiges Argument

Aber ich zweifle trotzdem dran. Einerseits habe ich nicht den Eindruck, dass viel Funktionalität in dem Eproms steckt - ich denke, es ist (anders als beim PC) eher eine Art IPL. Victor scheint mir vieles per nachladbarer Software gemacht zu haben, evtl. auch das BIOS. Offensichtlich ist noch nicht mal ein Zeichensatz vorgegeben.

Außerdem erwarte ich von einem "anständigen" Boot-ROM, dass es einen Selbsttest macht, und den habe ich offenbar auch gefunden:

ffd39:	b9 00 10     mov    $0x1000,%cx
   ffd3c:	b8 00 fe     mov    $0xfe00,%ax
   ffd3f:	8e c0        mov    %ax,%es
   ffd41:	33 f6        xor    %si,%si	
   ffd43:	33 c0        xor    %ax,%ax	


   ffd45:	26 03 04     add    %es:(%si),%ax
   ffd48:	46           inc    %si		
   ffd49:	46           inc    %si
   ffd4a:	e2 f9        loop   0xffd45		


   ffd4c:	3d 52 21     cmp    $0x2152,%ax	
   ffd4f:	74 03        je     0xffd54		


   ffd51:	e9 8e 00     jmp    0xffde2		


   ffd54:	b8 00 d0     mov    $0xd000,%ax
   ffd57:	8e d8        mov    %ax,%ds
....


   ffde2:	b0 02        mov    $0x2,%al
   ffde4:	ba ff ff     mov    $0xffff,%dx
   ffde7:	ee           out    %al,(%dx)
   ffde8:	eb fd        jmp    0xffde7

Wie gesagt, ich bin kein 8086-Fachmann, aber die Schleife ffd45-ffd4a bildet ganz offensichtlich eine Prüfsumme von fe000 bis fffff, die dann in ffd4c mit dem Sollwert verglichen wird. Im Fehlerfall geht's dann zur Endschlosschleife um ffde7.

Da die Kiste allerdings weiterläuft, scheint die Prüfsumme zu stimmen.

Und nein, so richtig vorstellen, was da los ist, kann ich mir auch nicht: einerseits stimmt die Startinitialisierung im Wesentlichen(Anzahl Zeilen, Anzahl Zeichen, Anzahl Pixel pro Zeile, Cursorgröße, Horizontalsync, Vertikalsync ...) und nur etwas marginales scheint schief zu laufen, und andererseits klappt später die Umprogrammierung irgendwie überhaupt nicht .... An sinnvolle Default-Werte glaube ich bei dem 6845 überhaupt nicht.
Es bleibt ein Rätsel ...

Danke übrigens für den Hinweis auf den 6845 in der Bucht. Ich hatte auch schon auf die Schnelle mal gesucht, aber zunächst nur die Chinesen, Bulgaren und völlig überteuerten Amerikaner gefunden ...

Quote from hexagon

Die Tastatur verwendet Schaumstoffpads. Diese sind mit Alufolie(?) beklebt. Offenbar ist das ganze schon ein wenig abgewetzt, daher vermute ich das die Tastenprobleme einzelner Tasten daher kommen:

Im Bild zu sehen: In der Mitte und unten links: gute Tasten, die Anderen schlecht

Hallo Andreas,

das erinnert mich an eine Terminaltastatur, die ich auch schon mal reparieren musste. Bei mir war auch eher der Schaumstoff das Problem, aber die Folie habe ich bei der Gelegenheit direkt auch getauscht, weil die bei vielen Tasten auch schon ziemlich "verbraucht" aussah.

Ich habe mich an dieser Anleitung orientiert; für den Schaumstoff habe ich afair einen Dichtstreifen genommen; als Folie eine Rettungsdecke (diese gold/silberfarbigen aus dem Verbandskasten). Die ist billig, hat funktioniert und Du kannst mit einer Decke eine Menge Tastaturen flicken

Hier noch zwei Bilder von meiner Tastatur vorher/nacher:

Gruß
Georg

Quote from x1541

PS. wenn wir dieses jahr eine Vicki und einen Victor aufstellen, steigen die Chancen, dass die Besitzer sich wieder melden

Das war wohl ein Wink mit dem Zaunpfahl

h&e ist Hobby & Elektronik in Stuttgart?
Ist mir etwas weit, und außerdem wollt Ihr doch eigentlich nur lauffähige Systeme dabei haben

Quote from retro64

Du könntest, wenn Dein Rechner sich ähnlich wie ein Sirius1 verhält, mal folgendes probieren, wenn er gebootet hat:

prompt $e($ep$p_

Das führt beim Sirius dazu, dass alles weitere in "hell" und "revers" ausgegeben wird...

Ja, damit wird es auch bei mir "hell" und "revers" - vorher war alles schwarz, jetzt ist alles grün (Siehe Anhang).
Also große Teile der Bildschirmsteuerung funktionieren, aber das Wesentliche irgendwie nicht ...

Quote from dlchnr

Da der Cursor vom 6845 gemacht wird, wird er nicht mehr richtig bedient oder hat selbst einen Knacks, falls der sich die Größe des Cursors dem gewählten Mode anpassen müsste. Auch der konstante Versatz deutet an, dass hier kein Bit klemmt, 'ne Leitung 'nen Kurzschluss hat oder ähnliches sondern sondern ein Rechehwerk eine falsche Konstante oder falsche Basisadresse geliefert bekommt. Das könnte man durchaus damit erklären, dass der 6845 nicht mehr vollkommen ok ist, denkbar wäre aber auch, dass im ROM nicht mehr alle Bits ok sind. Da der 6845 wohl nicht gesockelt ist, würde ich vor einem Tausch des CRT versuchen, erst den ROM-Inhalt zu verifizieren.

Es ist ja nicht nur der Cursor, sondern auch das Zeichenraster - der CRTC generiert offenbar pro Textzeile immer noch 16 Rasterzeilen statt 8, und es sind auch immer noch nur 80 Zeichen pro Zeile.

Vor dem Auslöten des 6845 habe ich auch Respekt, aber die ROMs habe ich weniger im Verdacht. Immerhin wird der 80*25-Modus (zumindest vom Raster, Cursor etc.) offenbar korrekt programmiert. Umgekehrt wird der 132-Zeichen-Modus, der ja ganz offensichtlich nicht korrekt initialisiert wird, per Software (über das Tool 132c.exe) eingestellt. Das hieße, dass eher dieses Tool kaputt ist.
Wegen der fehlenden Zeichen im 80-Zeichen-Modus muss es aber auch außerhalb des 132c.exe einen Fehler geben. Ich denke also, dass es eher an einem zentralen Teil der Video-Hardware liegt.

BTW, die Maschinen sind offenbar so selten, dass es wohl wenig Chancen gibt, das ROM zu verifizieren

Quote from kpanic

Ich könnte mir also durchaus vorstellen, dass der 6845 nen Hau hat und den Zeichensatz falsch adressiert.

Ja, ich habe auch schon mit dem Gedanken gespielt, einfach mal testweise den 6845 zu tauschen. Muss mal sehen, ob ich den woanders noch gesockelt habe.

Ich würde eigentlich gerne verstehen, wie es zu diesem Problem kommt, d.h. was eigentlich kaputt ist, so dass solche Phänomene auftreten. Im Fall eines defekten CRTC ist das natürlich aussichtslos, der ist einfach zu komplex.

Ich habe übrigens die DIR-Ausgabe jetzt relativ schnell entziffert, dort steht i.W.:

COMMAND  COM    19456  11.01.84  18.01  @86      COM     4096  11.04.91  16.31CONFIG   BAK       44   1.01.80   0.14CONFIG   SYS      171   9.04.91  13.16CONFIG   BAT       57  16.04.91  18.44PPORT    EXE     1536  17.01.84  11.45PORTA    EXE     3584   7.01.84  13.48BASIC        <DIR>      8.04.91  13.15DOS          <DIR>      8.04.91  13.15	        9 File(s)    559104 bytes free

(Die 1 und 2 sind in der Darstellung so gut wie nicht unterscheidbar (Doppelpunkt und Semikolon), deshalb kann fast überall, wo eine 1 steht, auch eine 2 stehen)

Statt einer autoexec.bat gibts es hier also eine config.bat; das für mich interessanteste steckt natürlich im Unterverzeichnis DOS. Da darf ich dann noch mal ran.
Und ich frage mich natürlich, was es mit der @86.com (wenn ich das richtig übersetzt habe) auf sich hat, die offensichtlich 3 Tage nach Erstellung der Diskette verändert/angefasst wurde.

Quote from retro64

hänge immer noch meiner Idee mit dem Kontrast nach...:

Bei meinem Sirius1 kann ich Phänomen prima "nachstellen", wenn ich den Kontrast nur weit genug "hochdrehe" (via Tastatur).

Du könntest, wenn Dein Rechner sich ähnlich wie ein Sirius1 verhält, mal folgendes probieren, wenn er gebootet hat:

prompt $e($ep$p_

Das führt beim Sirius dazu, dass alles weitere in "hell" und "revers" ausgegeben wird...

Display More

Danke für den Tipp, werde ich auf jeden Fall ausprobieren, wenn ich wieder im Keller bei dem Schätzchen bin. Aber noch mal wegen der Kontrastregelung: Ich nehme mal an, dass der Sirius keinen Drehregler hat? Denn den hat die Vicky, aber über die Tastatur habe ich meiner Meinung nach nur eine Regelungsmöglichkeit.
Und im Übrigen zeigt ja das seltsame Bild im 132-Zeichen-Modus, dass da etwas grundlegendes nicht stimmt...

Die Umschaltung der Konsole auf die serielle hat wieder nicht funktioniert; den Befehl SETIO habe ich offenbar nicht auf der Diskette. Und als Zielgerät für z.b. COPY geht TTY auch nicht

Dafür habe ich aber mal die Darstellung im 132-Zeichen-Modus untersucht. im Anhang sind ein zwei Beispiele - zum einen ein "leerer" Bildschirm, und dann die Ausgabe des DIR-Befehls. Durch gezielte Tests habe ich herausgefunden, dass ich einen konstanten Versatz von 9 Zeichen habe, d.h. aus einem A wird ein J, aus der Ziffer 0 eine 9, und aus dem Größer-Zeichen > (0x3E) wird ein G (0x47). So wird z.B. aus dem Prompt A> die Kombination JG, die man auf beiden Bildern vor dem Cursor erkennen kann.

Das scheint sich durch den gesamten Zeichensatz durchzuziehen; es ist einfach nur dieser konstante Versatz, der sich meiner Meinung nach nicht durch einen Bitfehler o.ä. erklären lässt. Massiv irritiert mich auch die Auflösung 80 Zeichen * 25 Zeilen nach der Umschaltung und der nach wie vor sichtbare 10*16 Pixel große Cursor.

retro64: Kannst Du mir noch zwei weitere Fragen beantworten?
1. Welcher Cursor ist im 132-Zeichen-Modus zu sehen? Ist das auch ein Block, und wie groß ist der?
2. Weißt Du, wie man die serielle Schnittstelle ansprechen muss, wenn man z.B. eine Datei dorthin kopieren will?

Ich werde jetzt mal versuchen, die Ausgabe des DIR-Befehls zu "übersetzen", damit ich weiß, was ich überhaupt auf den Disketten habe. Sind keine Originaldisketten; ich habe insgesamt nur drei Stück, und ich habe keine Ahnung mehr, was ich da drauf habe ...

Danke und Gruß
Georg

Eigentlich wollte ich die Kiste frustriert zusammenschrauben und wieder für einige Zeit ins Regal verbannen..

Auch der Versuch, mit der Maschine über die serielle Schnittstelle zu sprechen, ist komplett gescheitert. Obwohl es eigentlich normale DOS-Konstrukte sind, scheint der Rechner das CTTY nicht zu kennen, und ich habe sogar den Eindruck, dass er die serielle Schnittstelle nicht mit COM1 anspricht.

Jedenfalls hat jede Kombination von ctty (bzw. cttz, weil ich nicht sicher bin, ob ein Tastaturtreiber geladen ist), com1 (oder com2) zu keinem Ergebnis geführt (die Konsole müsste danach ja "tot" sein - passierte aber nicht). Beim Versuch, irgendwas nach COM1 (oder COM1: oder COM2 etc) zu kopieren, versuchte er offenbar, auf die Diskette zu schreiben, was wegen des Schreibschutzes zu einem Fehler führte.

Kann ich natürlich alles nicht sehen, außer an den Cursorbewegungen und den Reaktionen auf meine Tastendrücke ...

Ich habe auch immer wieder die vorhandenen Unterlagen studiert, und irgendwann habe ich von dem 132-Zeichen Modus gelesen: Die Victors können neben der 80x25 auch eine 132x50 Auflösung darstellen. Die Umschaltung erfolgt durch ein Programm 132c.exe - und siehe da, wenn ich das eingebe erscheint etwas auf dem Bildschirm. Nichts sinnvolles, aber es kommt etwas. Statt mit Leerzeichen ist der Bildschirm mit geöffneten Klammern gefüllt; auch alle anderen Zeichen werden durch falsche Zeichen ersetzt, und das auch noch "versetzt", d.h. in der obersten Rasterzeile erscheinen die Punkte, die eigentlich unten sein sollten, dann kommen ein paar leere Zeilen und dann kommt das eigentliche Zeichen, allerdings nur bis zur vorletzten Rasterzeile.

Irgendwie kommt die Videologik mit ihrer gesamten Adressierung durcheinander. Besonders auffällig: Die Zeichen sind zwar so klein, wie man sie erwartet (bei 800px * 400px und 132*50 Zeichen kommt man auf eine Zeichenmatrix von 6*8), aber es werden nur 80 * 25 davon dargestellt, und auch der Cursor hat seine ursprüngliche Größe von 10*16! Offenbar wird der 6845 nicht richtig umprogrammiert - da wundert man sich eigentlich, dass er beim Start mit immerhin halbwegs vernünftigen Werten programmiert wird, so dass er das normale Raster und den Cursor richtig hinbekommt ...

Und dann habe ich jetzt bei den weitere Nachforschungen doch noch den Befehl gefunden, mit dem ich die Konsole auf die serielle Schnittstelle umleite - das scheint eher wie bei CP/M zu gehen, nämlich durch Zuordnung von logischen Gerät zu physikalischem:

SETIO CON=TTY

und statt des MODE-Befehls gibt es dort wohl ein interaktives Tools namens PORTSET

Sieht so aus, als würde ich die Vicki wieder aus dem Regal rausholen und noch ein paar weitere Versuche machen müssen.

Bei der Suche nach Informationen, die mir bei dem Problem mit meiner Vicki helfen, bin ich noch auf folgende Datensammlung gestoßen, die zwar auch manches Bekannte wiederholt, wo aber auch ein paar neue/erweiterte Unterlagen zu finden sind (ganz abgesehen davon, dass man dort auch Unmengen Material zu andern Systemen finden kann

http://maben.homeip.net/static/S100/victor/

Hallo Jonas,

das deckt sich ja weitgehend mit dem, wie ich diese Doku gelesen und verstanden habe.

Quote from stynx

Leider keine Schaltpläne in der technischen Doku.

Auf der inzwischen bekannten Seite Home of the ACT Sirius 1 and VictorComputers finden sich durchaus einige Schaltpläne, auch wenn die sicher nicht 1:1 auf die Vicki übertragbar sind (andere Speicherausstattungen, 8088 vs. 8086 etc.).
Schlimmer ist aber, dass die Pläne meiner Meinung nach sehr unvollständig sind. Den Videoteil habe ich jedenfalls nicht gefunden

Georg

So, es hat zwar lange gedauert und ich hatte mir schon Sorgen gemacht, dass die Maschine mangels Interesse entsorgt werden könnte, aber jetzt hat sich doch noch ein Interessent gemeldet, und ich kann nunmehr abschließend mitteilen, dass die Anlage in gute Hände vermittelt wurde.

Es freut mich, dass wieder eine WANG gerettet wurde und Chancen auf eine Weiterbeschäftigung hat

Georg

Danke, das meinte ich. Ich hatte nur noch n ersten Teil im Kopf.
Mal sehen, ob ich das blind hinbekomme Im Zweifelsfall spare ich mir die Einstellung der Schnittstelle und arbeite mit den Default-Werten.

Hallo,

kurzes (hust, doch etwas länger geworden ) Update:

Die Sache mit Helligkeit/Kontrast habe ich ausprobiert: Auf der Tastatur sind nur Symbole für Lautstärke und Helligkeit vorhanden; damit regele ich aktuell die Cursorhelligkeit
Für den Kontrast (Unterschied Hell/Halbhell) gibt's wohl den Drehregler. Also die einfache Lösung war's nicht.

Beim Reset mit warmer Bildröhre wird einmal kurzfristig der gesamte Bildschirm hell - theoretisch kann er das also noch...

Der böse Verdacht, dass wesentlichte Teile der Bilderzeugung in einem der beiden geheimnisvollen Fujitsu-ICs passiert, scheint sich zu bestätigen: Das Pixeltaktsignal (Pin 21 des 6845) kommt direkt aus diesem Chip, und das Cursor-Signal (Pin 19) verschwindet offenbar auch schnurstracks dorthin. Ich fürchte, das wird eine Sackgasse.

Der Scan von der Löstseite ist auch erstaunlich schlecht geworden - da das Board größer ist als meine Scannerflache liegt es auf der Umrandung auf und damit dort ein paar Millimeter höher - ausreichend, dass die eng aneinander liegenden Leiterbahnen auf dem Bild völlig ineinander verlaufen. Ich hänge es mal an, aber helfen wird es wohl wenig. Evtl. kann ich auch die andere Seite mal scharf abbilden und dann die beiden Hälften zusammenbauen ... Wird aber eh kein Spaß werden, so wie das dort aussieht.

Ich schätze, als nächstes werde ich versuchen, mich von "hinten" aus vorzuarbeiten, d.h. vom fertigen Videosignal. Leider wird das auf der (relativ kleinen) Backplane abgegriffen, und um da vernünftig arbeiten zu können, muss ich die Kiste schon ziemlich gründlich zerlegen.

Ansonsten habe ich mir noch etwas die Technik des Victor 9000 durchgelesen, um einige der Fragen hier evtl. in den Griff zu bekommen.
Der Bildschirmspeicher ist 4K groß und enthält 80*25 = 2000 Worte(!), die den einzelnen Bildschirmstellen im Textmodus entsprechen. Diese 16 Bit pro "Zeichen" teilen sich auf in einen 11-bit Zeiger auf den Zeichensatz (womit max. 2048 verschiedene Zeichen dargestellt werden können) plus 5 Bit für diverse Attribute (unterstrichen, halbhell, invers, unsichtbar - eins ist ungenutzt)
Diese Zeiger zeigen in den unteren Bereich des normalen RAM, wo der aktuelle Zeichensatz abgelegt wird - je nach Zeichensatz zwischen 128 und 2048 verschiedene Zeichen. Jedes Zeichen wird aus eine 10x16 Matrix gebildet; zum Speichern werden aber 16 Worte verwendet. Von jedem Wort werden 10 Bits zur Darstellung der Rasterzeile genutzt, ein Bit hat noch einmal eine Attributbedeutung (etwas unkar, warum es das einerseits an zwei Stellen und dann hier auch noch separat für jede Rasterzeile gibt). Macht bei 32 Byte pro Zeichen mindestens 4K Zeichengenerator bei dem kleinstmöglichen Zeichensatz von 128 Zeichen bis zu theoretisch 64K bei der vollen Ausnutzung (das Handbuch schreibt 4K bis 40K).
(Im Hires-Modus werden im Bildschirmspeicher 2000 komplett verschiedene "Zeichen" abgelegt, jedes dieser "Zeichen" verweist auf einen eigenen 16x16 Bit großen Bereich im Hauptspeicher, der dann die hochauflösende Grafik enthält - nur so nebenbei...)
Die Schieberegister müssen also (je nach Modus) 10 bis 16 Bit breite Worte serialisieren - sowas gibt es auf den beiden Platinen definitiv nicht.

Das sind jetzt alles Informationen zum Victor 9000 - vieles davon passt aber ganz gut zu dem Bild, das wir inzwischen von der Vicki haben. Die beiden SRAMs halte ich demnach (auch wenn es reizvoll ist, die als Ersatz für ein Zeichensatz-ROM anzusehen) doch für den Bildschirmspeicher.

Ob und wieweit mir das bei der Analyse hilft, wird sich zeigen. Diese Fujitsu-Käfer machen das Leben schon ziemlich schwer ...

Ach ja, der Vollständigkeit halber: Die beiden Platinenanschlüsse links oben führen nirgendwo hin und hängen im Rechner einfach in der Luft. Debugging, Produktions-Abschlusskontrolle, ???
Und meine Irritationen bzgl. der EPROM-Inhalte rührt von meiner mangelnden Erfahrung mit dem 8086 her: Der springt (wie ich mittlerweile weiß) beim Reset an die Adresse 0xFFFF0 - wenn man davon ausgeht, dass die EPROMs am oberen Ende des Speicherbereichs angesiedelt sind, steht dort direkt ein Sprungbefehl (falls ich nicht irre):

EA 00 00 D0 FF - Sprung nach FFD00

An dieser Stelle fängt gerade ein neuer Codeblock an (erkennbar daran, dass sich davor ein größerer ungenutzter, d.h mit 0x00 gefüllter Bereich des EPROMs befindet); dieser Code scheint auch auf den ersten Blick was Sinnvolles zu machen.
Leider fehlt mir sowohl Werkzeug als auch Erfahrung mit dem i8086, um der Boot-Sequenz weitere Geheimnisse zu entlocken.

Soviel zum Stand der Dinge. Wenig erfreulich, und frustrierend, da die Kiste gut aussieht, ein superscharfes Bild hat (beim Booten wird wohl ein Logo angezeigt - das resultiert bei mir in einem hellen Rechteck mitten auf dem Schirm) und sonst alles macht, was man von ihm verlangt - man sieht nur nichts ...

Da fällt mir ein - wir haben doch früher gerne mal die Konsole auf die serielle Schnittstelle umgeleitet!? Frage an die DOS-Experten: Wie ging das noch - irgendwas mit dem mode-Befehl? Und Frage an die Sirius-Fraktion: Gibt's den Befehl auch im MS-DOS 2.1 des Sirius?
Dann könnte ich die Kiste vielleicht mal über die serielle Schnittstelle betreiben. Ich würde zu gerne noch mal den Laufwerken beim Formatieren zuhören - die Sirius-Kenner wissen, was ich meine

Gruß
Georg

Quote from dlchnr

Ah - da haben wir wohl gleichzeitig an 'nem Beitrag geschrieben - also kein Schieberegister!
Wenn Du das Board ausbaust, leg' die Lötseite doch gleich mal auf den Scanner.

Yepp, kein Schieberegister, nur ein Haufen Bustreiber, Multiplexer und ein paar Gatter. Achja, unten rechts ein doppelter 4-Bit-Binärzähler ...

Das mit dem Sacnner werde ich noch mal versuchen - die Unterseite benötigt ja nicht so viel Tiefenschärfe

Quote from retro64

Da trau' ich mich fast nicht, eine andere Idee einzuwerfen:

Ich selber habe einen fast funktionstüchtigen Sirius1, kenne dafür aber leider den Vicki nicht...
Trotzdem:
Beim Sirius kann man nicht nur die Helligkeit (via Tastatur) einstellen, sondern auch den Kontrast. Wenn der sehr weit runter ist, könnte die normale Schrift quasi verschwinden, und nur der hellere Cursor ist sichtbar.

Ups, das wäre natürlich extrem peinlich
Ich habe an den Tasten etwas rumgespielt, aber vermutlich habe ich nur die Helligkeit gefunden, denn der Cursor wurde eben dunkler.
Zusätzlich habe ich ja noch den ordinären Drehknopf dran (für eine Grundeinstellung?) Mal sehen, ob die Kiste mich morgen noch mag, dann werde ich das mit dem Kontrast auf jeden Fall prüfen. Wobei ich bei einer Einstellung per Software eigentllich erwarte, dass bei Systemstart ein "sinnvoller" Kontrast voreingestellt wird - was im Gegensatz zu einer Hardware-Einstellung ja möglich ist.

Quote from retro64

Und zur Frage nach dem Boot ohne Floppy;
Wen beim Sirius kein Boot-Medium gefunden wird, wird ein Disketten-Sybol, etwa in der Mitte der letzten Bildschrimzeile, angezeigt. Zusätzlich blinkt noch eine nach unten zeigender Pfeil als Aufforderung eine Floppy einzulegen.

Danke, dass ist eine wichtige Information. Das würde nämlich bedeuten, dass der Zeichensatz doch nicht im ROM liegen *muss*. Wobei der Pfeil bei der Vicki zur Seite zeigen müsste, weil die Laufwerke rechts liegen
Ich habe eben versucht, in den Innereien der EPROMs was Sinnvolles zu finden. Irgendwie stelle ich mich aber wohl was blöd an; wenn ich die beiden Teile (Even/Odd) zusammenmische (In der Reihenfolge Even/Odd, oder?) startet der Code zwar halbwegs sinnvoll mit einem kurzen Sprung, aber dort passieren dann Dinge, die mir nicht ganz logisch erscheinen. Und sinnvolle Muster für einen Zeichensatz habe ich auch nicht gefunden (wobei ich überhaupt keine Ahnung habe, wie groß ein Zeichen sein soll - wenn's z.B. eine 10x10 Matrix ist, erkennt sowas kein Mensch in einem Hexdump).
Vielleicht habe ich aber auch einen Fehler beim Zusammensetzen gemacht. Ist ja schon was spät...
Wenn ich das geprüft habe, poste ich mal die ersten Bytes. Dann können die x86-Cracks ja mal ihre Meinung abgeben.

Morgen geht's weiter. Herzlichen Dank auf jeden Fall schon mal in die Runde!

Hallo Jungs,

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

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

Georg

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

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.

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

Quote from 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.

Quote from 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.

Quote from 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

Quote from 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
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.

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

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.

Quote from 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

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:
[Blocked Image: 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