Victor Vicki - Fehlerhafte Bildschirmausgabe

Zitat von Georg

Danke, Hans.
Wenn ich das richtig verstanden habe, gab's dabei auch Turbo Pascal für den Victor - das fände ich prima, denn das war meine Sprache der Wahl. Erst unter CP/M und dann auch unter DOS. Käme auf der Vicki großartig. Ich versuche, am Ball zu bleiben, und kläre das mit retro64.

Dann mal viel Spaß damit

retro64 hat nicht nur das Turbo-Pascal (3.01 wenn ich mich nicht täusche) sondern meine komplette Entwicklungsumgebung. Dazu gehörte auch eine erweiterte Oberfläche, ein Formatter für Pascal-Source und ein Full-Screen-Maskeneditor/Generator.

Ich hätte das ja gerne alles nochmal getestet als ich die sachen abgegeben habe - aber leider bootete der Rechner nicht mehr sauber

Übrigens ... ich hab da - neben anderen Spielen - auch ein StarTrek mit Sprachausgabe ... heute ganz normal, damals echt die Krönung !

Hans

Zitat von Georg

Da fehlt es mir leider an allem: Erfahrung, Ehrgeiz und Zeit.

Wie Du gemerkt hast, kann ich "sinnvolle" Zusammenhänge oft nicht erkennen, weil ich nicht die nötige Übung/Erfahrung/Praxis habe. Ich dilettiere ein bisschen bei der Suche nach Fehlern; ich habe noch nie so eine Architektur selber entworfen und weiß deshalb nicht, worauf es ankommt.

Na das würd' ich so jetzt nicht stehen lassen - Du bist doch bei dieser Fehlersuche recht systematisch vorgegangen. Und für das Blockschaltbild wäre es ja primär von Nöten, die Busabschnitte zu detektieren. Das schöne dabei, man braucht immer nur eine Leitung/Verbindung zu finden, die anderen sieben fallen einem fast in den Schoss.

Zitat von Georg

Mal sehen, ob mir für diese Fülle an Material die Zeit reicht. Aber interessant hört sich das schon an.

Wenn Ihr das zum starten bekommt und Fragen habt meldet Euch gerne - eine Doku zu den Sachen gibt es halt nicht - Ich hab schon damals ungern Dosku geschrieben - und im Lauf der Jahre ist es nicht besser geworden

Hans

Zitat von Georg

Das kann ich mir gut vorstellen, aber ich fürchte, das ist einer der wenigen Punkte, wo die Vicki nicht mithalten kann. Der Victor hatte irgend so eine Einheit zur Sprachaufnahme/wiedergabe - das hat die Vicki afaik nicht.

Stimmt - die Coddec fehlt der Vicki .... gut ... bis auf dieses Startrek-Spiel hatte ich auch nie SW gesehen die die nutzt. Und wir hingen damals fast jeden Tag in der Geschäftsstelle von Victor in Hamburg rum.

Hans

Hallo,

erstmal herzlichen Glückwunsch zum wiederbelebten Vicki. Leider bin ich erst kürzlich (zu spät) auf dieses Forum gestoßen, ansonsten hätte ich bei dem ein oder anderen Rätsel sicher helfen können.

Vielleicht ist es für den ein oder anderen trotzdem noch hilfreich, wenn ich die Funktion der Bildschirmausgabe des Sirius hier zusammenfasse:

Der Sirius befindet sich im Prinzip dauerhaft in einem Character-Grafik-Modus mit 800x400 Pixeln. Der einzige Unterschied zwischen dem "Textmodus" und dem "Grafikmodus" ist, dass der 6845 umprogrammiert wird, so dass statt eines 16x10 Rasters ein 16x16 Raster verwendet wird. Mit anderen Worten ist der Grafikmodus eigentlich ein 50x25 Zeichen Textmodus. Das Video-RAM selbst dient in beiden Fällen als eine Art Vektortabelle, die aus 2048 16-Bit Einträgen besteht, die auf einen Speicherbereich in den unteren 64k des RAM zeigen. Im Prinzip ein Shared Memory, auch wenn das damals noch nicht so genannt wurde. Die eigentlichen Informationen, die dargestellt werden, stehen also vollständig im RAM.

Von den 16 Bit jedes Eintrags im Video RAM dienen die unteren 11 Bit (0 bis 10) dabei als Vektor, der jeweils auf ein 32 Byte großen Bereich des RAMs verweist (16x16 Pixel x 1 Bit = 256 Bit bzw. 32 Byte). Ein Wert von 5 in den unteren 11 Bit würde z.B. bedeuten, dass das Zeichen an RAM-Adresse 160 ausgegeben wird (5x32). Bit 11 war von Anfang an reserviert, vermutlich um bei zukünftigen Varianten den Shared Memory-Bereich auf bis zu 128k erhöhen zu können. Bits 12-15 sind Attribut-Bits, die die Funktionen Hidden, Underline, Reverse, High Intensity abbilden (Reihenfolge habe ich gerade nicht im Kopf). Underline spiegelt dabei alle Bits die in der letzten Spalte des jeweiligen 32-Byte Blocks im RAM gesetzt sind auf die 15 vorherigen Spalten (bzw. 9 vorherigen Spalten im Text Mode). Grundsätzlich funktionieren die Attribute aber auch im Grafikmodus.

Mit dem Konstrukt der Vektoren, kann der Sirius theoretisch bis zu 2048 verschiedene Zeichen darstellen (2^11). In einigen Systemvarianten wurde diese Eigenschaft genutzt und es waren von Anfang an zwei Zeichensätze à 256 Zeichen hinterlegt.

Da der Addressraum beim 8088 mit dem Interrupt-Table beginnt, konnte der Zeichensatz grundsätzlich nicht direkt bei Adresse 0 im RAM platziert werden. Effektiv wurde bei allen mir bekannten Systemen die Adresse 0C80h verwendet. Das führt zu dem zunächst merkwürdig erscheinenden Effekt, dass man im Video-RAM nicht die ASCII Werte der Zeichen erkennt, sondern immer einen Versatz von 100 (dezimal!) hat (0C80h = 3200; 3200 / 32 Bytes = 100). Damit ist das Leerzeichen (ASCII 20h, 32) im RAM als 84h zu sehen.

Der Grafikmodus, der wie gesagt im Prinzip auch ein Textmodus ist, wird dann dadurch realisiert, dass ein 40k großer Bereich im unteren RAM reserviert wird und anschließend im Video RAM eine durchgehende Folge von Vektoren, die auf jedes einzelne Zeichen in diesem Bereich verweist, angelegt wird. Im Prinzip wird damit also der Zeichensatz auf 1.250 Zeichen erweitert, wobei jedes Zeichen nur genau einmal verwendet wird. Das Video-RAM wird danach überhaupt nicht mehr verändert. Theoretisch ist es durch das Intensity Attribut sogar möglich Grafik in 2 verschiedenen Helligkeitsstufen darzustellen, allerdings mit der Einschränkung, dass das Attribut natürlich nur je 16x16 Pixel Block verändert werden kann. Die Vektoren wurden im Grafikmodus übrigens meistens spaltenweise angelegt. Dadurch ist der Grafikbereich im RAM in Schnipsel von 16x400 Pixeln unterteilt. Eine zeilenweise Anordnung der Vektoren wäre deutlich umständlicher zu handhaben, dann wären es tatsächlich Schnipsel von 16x16.

Um das Ganze noch komplizierter zu machen: Man kann sich beim Sirius nicht darauf verlassen, dass der erste Eintrag im Videoram sich auch auf das erste Zeichen auf dem Bildschirm links oben bezieht. Das liegt daran, dass Victor beim Scrolling auf eine Umprogrammierung des 6845 gesetzt hat anstatt per memcpy die Inhalte des Video RAMs zu verschieben. Bei jedem Scrollen wird dabei einfach ein Offset im 6845 programmiert, der dazu führt, dass die gleichen Inhalte des Video RAMs sich auf eine andere Bildschirmposition beziehen. Das geht zwar schneller als 4k hin- und herzuschieben, hat aber einige Nachteile bei der Programmierung. Insbesondere für TSR-Programme ist es nicht ohne Weiteres möglich zu ermitteln, welcher Offset gerade programmiert ist, da die Register des 6845 sich nicht auslesen lassen. Wenn also ein TSR Programm einfach an Adress F0000h schreibt, ist es reiner Zufall wo das auf dem Bildschirm auftaucht. Der Offset wird bei jedem Clearscreen zurückgesetzt, daher wird vor dem Umschalten in den Grafikmodus auch jedesmal eine ESC-"E" Sequenz abgesetzt. Durch das Scrolling-Verfahren werden übrigens auch die letzten 96 Bytes aus dem Video-RAM genutzt, die im Prinzip ja unnötig wären, da ja nur 2000x2 Bytes relevant sind.

Wie aus den Ausführungen hervorgeht, ist die Grafikprogrammierung des Sirius nicht gerade trivial, daher gab es ein TSR-Program von Victor ("Grafix"), dass sich in den CON-Treiber einklinkt, über dass per Escape-Sequenzen die Grafik gesteuert werden konnte. Damit war der Zugriff aus allen Programmiersprachen relativ einfach, aber auch extrem langsam. GWBASIC hatte eigene Grafikroutinen eingebaut und war entsprechend zu dem Grafix TSR inkompatibel. Wer richtig flotte Grafik programmieren wollte, musste seine eigenen Routinen schreiben.

Ein grundlegendes Problem war die Notwendigkeit von 40k Speicher in den unteren 64k. Um zu gewährleisten, dass hier überhaupt Speicher frei ist, waren die MS-DOS Versionen für den Sirius alle sogenannt "H"-Versionen ("H=Highmem, nicht zu verwechseln mit dem später beim PC gebräuchlichen HIMEM.SYS). Diese Versionen hatten im Gegensatz zum PC eine umgekehrte Speicherorganisation. BIOS, Betriebssystem, COMMAND.COM, wurden alle an die höchstmögliche freie Speicheradresse geladen, damit eben nicht von Anfang an die unteren 64k schon blockiert waren. In den alten Versionen von DOS finden sich im Source Code an diversen Stellen bedingte Assembleranweisungen ("IFDEF HIGHMEM..."), die dieser Anforderung Rechnung tragen. Ich habe irgendwann mal DOS 3.3 auf Basis geleakter Source Codes experimentell auf den Sirius portiert. Hier gab es zwar noch einige HIGHMEM-Überbleibsel, aber an den relevanten Stellen wurden diese Anweisungen aus dem Source Code entfernt. Vermutlich hat Microsoft den Code nach 3.1 bereinigt, da nach dem Ende des Srius 1 keine Notwendigkeit mehr dafür bestand. Die 3.3 Version funktioniert übrigens, ist aber daher nicht grafikfähig.

Mit Version 3.1 (zumindest kenne ich es erst seit 3.1) hat Victor einen Standard eingeführt, der die Reservierung und die Adressierung des Grafikspeichers regelt. Mit dem GETSCRN-Tool kann vor dem Start von Anwendungen ein 40k großer Bereich reserviert werden, dessen Adresse dann über einen Eintrag im Interrupt-Table abgefragt werden kann. Die späteren GWBASIC Versionen hatten das als Voraussetzung. Diese Vorgehensweise vereinfacht das Speichermanagement wenn man von Hochsprachen aus direkt die Grafik programmieren will. Ansonsten besteht nämlich das Problem, dass die Anwendung selbst in den unteren Speicherbereich geladen wird und damit zunächst den Grafikspeicher blockiert. Dann müsste das Programm sich zunächst selbst an einen anderen Speicherort verschieben, um anschließend den Grafikspeicher zu reservieren. Das ist z.B. aus Turbo Pascal heraus ziemlich kompliziert. Daher ist die Variante mit GETSCRN deutlich praktikabler.

Aus einem mir nicht bekannten Grund ist übrigens das Grafix TSR-Programm nicht mit DOS 3.1 kompatibel. Hat jemand eventuell eine spätere Version, die auch unter 3.1 läuft?

Ich hoffe, dass ich damit so ziemlich alle Aspekte des Sirius Grafiksystems erschlagen habe.

Für Interessierte kann ich gerne ein paar simple Assembler-Routinen zur Grafikprogrammierung auf dem Sirius zur Verfügung stellen (samt Einbindung in Turbo Pascal). Wer bis hier durchgehalten hat ist möglicherweise tatsächlich interessiert

Ich habe selbst 2 Vicki, von denen einer nicht mehr bootet. Leider bin ich eher ein Experte für Systemprogrammierung und weniger was Hardware-Reparaturen angeht. Im Moment ist auch die Zeit recht knapp bemessen. Vielleicht kann mich ja zukünftig jemand aus dem Darmstädter Raum bei der Wiederbelebung unterstützen.

Zitat

Eine Ergänzung möchte ich aber noch machen - zumindest habe ich das aus den Referenzen so rausgelesen: Die "Pixeldarstellungen" können nicht nur in den unteren 64 KB untergebracht werden, sondern wohl auch im nächsten 64KB Block. Die gesamten ersten 128 KB sind als dual ported RAM (Du nennst es shared memory) ausgelegt. Die Auswahl der Bank erfolgt über ein freies Adressbit des 6845 (MA12). Der benötigte Speicherbereich darf allerdings die 64KB-Grenze zwischen Bank1 und Bank 2 nicht überschreiten.

Vollkommen richtig. Man kann über Bit 4 im R12 Register MA12 umprogrammieren. Das ist aber mit den Systemroutinen im BIOS nicht kompatibel. Spätestens beim Scrollen erscheint dann nur Müll auf dem Schirm. Wenn man nur im eigenen Programm bleibt und kein BIOS dazwischen funkt ist es aber tatsächlich möglich die zweite 64k Bank anzusprechen. In der Praxis wurden auf jeden Fall immer die unteren 64k genutzt.

Das von mir erwähnte Bit 11 in den VRAM Vektoren hat aber nichts mit MA12 zu tun. Meine Vermutung ging eher dahin, dass dieses Bit genutzt werden sollte, falls ein zukünftiger Sirius 2 eine so hohen Grafikspeicherbedarf hat, dass 64k nicht ausreichen und ohne Bank Switching 128k angesprochen werden müssen. Ist aber nur Spekulation.

Zitat

Was mich allerdings noch beschäftigt (ich könnte es mit dem lauffähigen Gerät vermutlich rausbekommen, aber ich schätze, Du kennst die Antwort schon): Wie machen die das mit dem 132-Zeichen Modus? Dafür wird ein eigener Zeichensatz geladen, und angesichts der Strukturen wäre es eigentlich sinnvoll, den CRTC entsprechend auf 50 Zeilen á 132 Zeichen zu programmieren - aber dann bräuchten wir 50*132=6600 Vektoren im Videospeicher - der fasst aber nur 2048 Worte. Ich kann mir also nur vorstellen, dass dieser Modus im Grafikmodus läuft - dann frage ich mich nur, warum der Zeichensatz (den das System natürlich immer noch benötigt), immer noch in dem platzraubenden 16*16-Raster abgelegt wird (benötigt werden pro Zeichen 8*6 Pixel). Weißt Du mehr?

Richtige Schlussfolgerung. Ein direkter 8x6 Modus wäre nur mit einem deutlich größeren VRAM zu realisieren. 132x50 ist auf dem Sirius daher eine reine Softwarelösung, die auf dem 16x16 Grafikmodus läuft. Ähnlich wie beim Grafix-Tool wird auch hier ein TSR (132C.EXE oder .COM) gestartet, dass sich in den CON-Treiber einklinkt und dadurch alle Bildschirmausgaben abfängt. Das TSR reserviert 40k Speicher, setzt die Vektoren im VRAM und hat einen eigenen 8x6 Zeichensatz, der ebenfalls im RAM abgelegt wird. 132C also ein reines Grafiktool.
Bei jedem Zeichen, das dann über CON ausgegeben wird, kopiert das Tool dann das Bitmap des entsprechenden Zeichens an die aktuelle Position im 40k Grafikspeicher. Vertikal passen jeweils zwei 8x6 Zeichen in ein 16x16 Raster, horizontal überschneiden sich die Raster, so das teilweise das 8x6 Zeichen gesplittet wird und der Rest in den benachbarten 16x16 Block kommt.

Das funktioniert natürlich nur, wenn die Programme auch über DOS Zeichen ausgeben. Wenn direkt ins VRAM geschrieben wird, werden die Vektoren zerstört und es erscheint 16x16 Müll auf dem Bildschirm (dann sieht man bei allen Zeichen übrigens sehr schön den Punkt unten in der 16. Spalte, der für den Underline-Modus verwendet wird). Außerdem ist das Tool auch nicht zu Grafix kompatibel, da die beiden Programme keine Kenntnis voneinander haben (das jeweils zuletzt gestartete TSR weigert sich, da keine 40k im unteren Bereich mehr frei sind). Ganz konsequent war Victor hier nicht, da das Tool auch nicht zu dem oben erwähnten GETSCRN Standard kompatibel ist, obwohl beide Programme mit 3.1 ausgeliefert wurden. Grundsätzlich wäre es natürlich möglich, dass sich die Tools die 40k teilen, solange nur jeweils eins von ihnen darin aktiv ist.

Der ursprüngliche Zeichensatz wird von dem Tool nicht angefasst, er bleibt bei 0C80h. Theoretisch könnte man - solange man im 132 Modus ist - den 8kb großen Bereich anderweitig nutzen. Es ist aber eher unwahrscheinlich, dass man dort einen zusammenhängenden Speicherbereich erhält, den man sinnvoll nutzen kann. Und man müsste bei jedem Zurückschalten in 80x25 den Zeichensatz wieder von Diskette/Festplatte laden. Da nach dem Laden von 132C ständig beide Zeichensätze im RAM sind ist es sogar möglich zwischen den Modi per Escape-Sequenz aus jedem Programm heraus umzuschalten (nichts anderes machen dann die Tools 132ON bzw. 132OFF, die nach Laden von 132C den Modus tatsächlich ein-und ausschalten).

Durch die hohe Auflösung des Sirius kann man die Schrift bei 132x50 noch gut lesen. Durch die beschriebene Umsetzung ist die Bildschirmausgabe dabei aber extrem langsam. Es lohnt sich also nur bei Anwendungen, die nicht ständig große Teile des Bildschirms aktualisieren. Selbst wenn das auszugebende 8x6 Zeichen in das aktuelle Raster passt, müssen pro Zeichen 8 Bytes gelesen werden und im Idealfall 8 Bytes geschrieben werden. In den meisten Fällen sogar 16 Bytes, an nicht direkt aufeinanderfolgenden Speicheradressen. Zusätzlich muss je nach Position meistens noch die Bitmap um einige Bits geshiftet werden, was auf dem 8088 ziemlich langsam ist. Und es muss vor der Ausgabe auch noch Zeichen für Zeichen auf Steuersequenzen oder CRLF, etc. geprüft werden. Alles in allem viele Gründe warum der Modus so langsam ist, dennoch ist für einige Anwendungen sinnvoll und technisch in jedem Fall interessant.

Gruß,
Axel

Zitat von sirius1victor9000

...
Durch die hohe Auflösung des Sirius kann man die Schrift bei 132x50 noch gut lesen. Durch die beschriebene Umsetzung ist die Bildschirmausgabe dabei aber extrem langsam. Es lohnt sich also nur bei Anwendungen, die nicht ständig große Teile des Bildschirms aktualisieren. Selbst wenn das auszugebende 8x6 Zeichen in das aktuelle Raster passt, müssen pro Zeichen 8 Bytes gelesen werden und im Idealfall 8 Bytes geschrieben werden. In den meisten Fällen sogar 16 Bytes, an nicht direkt aufeinanderfolgenden Speicheradressen. Zusätzlich muss je nach Position meistens noch die Bitmap um einige Bits geshiftet werden, was auf dem 8088 ziemlich langsam ist. Und es muss vor der Ausgabe auch noch Zeichen für Zeichen auf Steuersequenzen oder CRLF, etc. geprüft werden. Alles in allem viele Gründe warum der Modus so langsam ist, dennoch ist für einige Anwendungen sinnvoll und technisch in jedem Fall interessant.

Hallo Georg, Hallo Axel,

ich bin auf den Thread jetzt erst gestossen, auf der Suche nach Infos über das Victor Vicki Portable. Ich habe zwei Stück, davon eines funktionsfähig. Das Problem bei dem nicht funktionsfähigen: er bootet nicht von Diskette. Daraufhin habe ich die Floppy-I/O-Platine gegengetauscht. Mit der funktionsfähigen Platine laufen beide Rechner. Der Fehler hängt also mit der Platine zusammen. Leider sind keinerlei Schaltpläne über das Portable aufzutreiben. Kann mir da trotzdem geholfen werden? Das Victor Vicki Portable ist ein seltener Computer, wäre schön, wenn beide erhalten blieben.

Gruß Wolfgang

PS: wenn hierfür ein neuer Thread eröffnet werden soll, möge mich der Admin darauf hinweisen.