Posts by sirius1victor9000

    Die meisten Sirius haben ein P1 Boot-ROM. Dann müsste meiner Meinung nach auch ohne (funktionierenden) Diskettencontroller ein Diskettensymbol auf dem Schirm zu sehen sein wenn sonst alles funktioniert. Beim Universal Boot ROM müsste zumindest das "M" mit der erkannten Speichergröße zu sehen sein. Siehe Screenshots.
    Die ROMs halten den Rechner bei schwerwiegenden Fehlern aber schon vor einer Bildschirmausgabe an. Dazu gehören: Checksum Fehler im Bootrom, VRAM Fehler, RAM Fehler. (Oder der 8088 selbst ist defekt...)Im Falle eines solchen Fehlers halten die P1 mit unendlichem JMP auf die Adresse des JMP Befehls an, Universal sendet in einer unendlichen Schleife per OUT einen Fehlercode auf den I/O Bus.
    Erst nach dem Test auf schwerwiegende Fehler wird der Bildschirm angeschaltet und ein Mini-Zeichensatz ins RAM geladen, so dass Fehler angezeigt werden können. Ein fehlender Diskettencontroller dürfte das System eigentlich nicht aus der Ruhe bringen und müsste wie gesagt zumindest irgendeine Meldung auf dem Schirm hervorrufen. Die Tatsache, dass die LEDs leuchten zeigt auch, dass das Boot-ROM zumindest soweit kommt, dass es die 6522 Chips auf dem Floppy Controller anspricht. Also gehe ich davon aus, dass es zumindest keiner der erwähnten schwerwiegenden Fehler ist und der 8088 vermutlich auch ok ist.
    Was passiert beim Schließen der Laufwerksverriegelungen? Springt einer der Motoren an? Bezüglich der nicht vorhandenen Bildschirmausgabe: ich würde prüfen, ob der 6845 ein Signal erzeugt, außerdem ist die Frage, ob auf dem Monitoranschluss des Mainboards auch Spannung anliegt, da der Monitor seine Spannung ja vom Computer aus erhält.

    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

    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.

    Kopieren von komplettem Diskettenimage:
    ich habe vor ca. 10 Jahren einen Gerätetreiber für den Sirius programmiert, der das Diskettenimage als virtuelles Alufwerk auf dem Sirius zur Verfügung stellt. Damit wir dann z.B. ein virtuelles Laufwerk C: erzeugt, auf dem 2 Dateien liegen "DISKA.IMG" und "DISKB.IMG". Diese können dann per Kermit direkt zwischen PC und Sirius hin- und hergeschoben werden. Es ist sogar möglich ein Image direkt auf eine Diskette zurückzuschreiben. Damit habe ich alle meine Daten gesichert. Bei Interesse PN.

    Grundsätzlich kann man den Sirius mit MS-DOS 3.1 booten. Das war die letzte Version, die von Victor für den Sirius angepasst wurde. Die offizielle Version hat eine Größe von 78.016 Bytes, damit ist sie >64k und die älteren MOdelle des Sirius können diese Version nicht ohne Weiteres booten. Das dort enthaltene Boot-ROM (Version "P1"), war nur für Betriebssysteme <64k ausgelegt. Bei den (meisten) Festplattenmodellen bzw. neuere Varianten, die mit dem sogenannten Universal-Boot-ROM ausgestattet sind, gibt es diese Beschränkung nicht mehr.


    Auch wenn das Booten grundsätzlich funktioniert, ist ein sinnvoller Betrieb von 3.1 mit 128k RAM nicht möglich, bzw. es stürzt beim Laden von COMMAND.COM ab. Zumindest ist es mir nicht gelungen 3.1 auf 128k zum Laufen zu bringen. Ab 256k läuft das System problemlos, ich setze es auf meinem "Produktivsystem" ein...


    Bezüglich der 64k Boot-ROM Grenze gibt es mehrere Möglichkeiten das zu umgehen:
    1. Austausch des Boot-ROMS gegen Universal-Boot-ROM bzw. ISSUE Boot-ROM
    2. Start des Systems über einen Bootloader (habe ich vor vielen Jahren quick & dirty programmiert, funktioniert aber. Prinzip ist, dass ein Mini DOS 1.25 geladen wird, dass als einzige Aufgabe einen Bootloader ausführt,
    der dann 3.1 in den Hauptspeicher lädt und startet. Man kann mit dem Tool auch aus dem laufenden Betrieb jedes beliebige Betriebssystem booten)
    3. Vor ein paar Jahren habe ich eine komprimierte Version von DOS 3.1 für den Sirius erstellt, die auf einem simplen Runtime-Entpacker basiert. Damit konnte ich die Größe des Systems auf unter 64k schrumpfen. Die Speicheranforderungen ändern sich damit natürlich nicht, nach dem Booten ist das System exakt so groß wie die ursprüngliche Variante.
    Die Dateien für 2. und 3. kann ich per PN verschicken.