Victor Vicki - Fehlerhafte Bildschirmausgabe

  • Würde an Deiner Stelle da jetzt nicht aufhören und die erzielten Erkenntnisse und weitere Untersuchungen zumindest soweit fortführen, bis ein Blockschaltbilod für die Vicki gewonnen ist
    (der Aufwand für ein Blockschaltbild sollte sich in Grenzen halten verglichen mit dem Aufwand, 'nen kompletten Schaltplan zu generieren)!


    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.


    Meine Vorgehensweise folgt einer Art "Minimalprinzip" (auch wenn manche hier die Erfahrung haben, dass forsches Ausprobieren oft schneller zum Erfolg führt als meine nächtelangen Analysen ;) ) - ich werde aktiv, wenn ich einen Fehler habe, und versuche dann das konkrete Umfeld zu analysieren und den Fehler zu lokalisieren. Was dabei an Informationen anfällt - prima, aber ich fange in der Regel nicht an, darüber hinaus zu forschen, wenn es für das aktuelle Problem nicht hilfreich ist. Wenn alles klappt, habe ich nach einer Weile Beobachten, Messen, Nachdenken und Ausprobieren dann den defekten Baustein isoliert und kann den gezielt austauschen. Klappt nicht immer, aber oft.


    Und schließlich gibt es noch eine Menge anderer Rechner neben der Vicki. Und davon leider auch immer wieder welche mit Defekten. Die Wangs z.B. kommen hier durchweg kaputt an - von dem knappen Dutzend Maschinen haben höchstens zwei bei ihrem Eintreffen auf Anhieb gearbeitet. Und das Thema "Auslaufende Kondensatoren in den CBM-Floppys" macht mir auch schon Sorgen.

    Von daher: Ich bin froh, dass die Vicki läuft, ich werde sie jetzt noch etwas von der Anwenderseite aus untersuchen (ist über 20Jahre her, dass ich zuletzt was mit ihr gemacht habe); ich werde prüfen, inwieweit ich mit ihrer Untertützung bei dem Victor von Andreas helfen kann - und dann kommt vermutlich schon wieder der nächste Patient dran.


    Wobei die Schlepptops (Osborne, Kaypro, TRS-80 4p, Compaq Portable usw.) ja einen Riesenvorteil haben: Man kann sie jederzeit aus dem Regal holen und aktivieren - ohne einen passenden Bildschirm und Tastatur zu suchen, ohne großen Kabelverhau etc.


    Sie hat also gute Chancen, immer mal wieder an die frische Luft zu kommen ....


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


    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.

  • 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

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


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


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


    Na dann - schließe Dich doch an! Andreas macht auch mit seihnem Victor weiter ;)


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


    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.

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

  • 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

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

  • Hallo s1v9,


    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.


    Ja, nachdem ich Deinen Beitrag durchgelesen habe (ich habe wirklich bis zum Ende durchgehalten ;) ) denke ich das auch. Eine Menge der Fragen, die uns in den letzten Tagen beschäftigt haben, kannst Du offensichtlich so aus dem Handgelenk beantworten. Zusätzlich stand aber auch noch eine Menge weitere Informationen drin, z.B. zum Thema Grafik (mit der wir uns angesichts der Problematik nur am Rande beschäftigt haben) und insbesondere zu den Besonderheiten der Speicherorganisation.


    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.


    Deine Ausführungen zur Grafik sind sehr interessant; ich hatte bisher nur vage Vorstellungen davon. Allerdings sehe ich bei mir in absehbarer Zukunft auch nicht die nötige Freizeit, mich intensiver mit diesem Thema beschäftigen zu können. Eher interessieren mich die Themen, die Du in dem anderen Thread zum Datenaustausch angesprochen hast => PN.


    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?


    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.


    Du kannst es natürlich versuchen wie ich - mit Fernunterstützung hier durch das Forum. Das größte Problem dabei könnte der Zeitbedarf sein.
    Den "klassischen Fehler" laut Home of the ACT ... hast Du schon geprüft? Scheint eher was für Maschinen zu sein, die intensiv genutzt wurden - könnte also bei Dir passen ;) . Allerdings hatte ich damals (tm), als ich die Vicki bekam, ja auch zunächst ein ganz anderes Problem, irgendwo im Netztteil ...


    Gruß
    Georg

  • Quote

    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.


    Quote

    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

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

  • Hallo Wolfgang,


    ich denke, dass dafür ein neuer Thread sinnvoll ist.


    Unterlagen für die Vicki scheinen nicht verfügbar zu sein, aber in vielen Bereichen helfen die Unterlagen vom Victor/Sirius auch weiter.


    Gruß
    Georg


    PS. Wolfgang aus Grasbrunn? Kann doch eigentlich nur einer sein :grübel: