Posts by sirius1victor9000

    OT, aber trotzdem interessant:


    Die Story zu der Festplattenunterstützung in MS-DOS kommt übrigens von Chuck Peddle selbst. Interessantes Podcast Interview abrufbar unter:
    http://www.theamphour.com/241-…ic-chipmaking-coryphaeus/
    bzw.
    http://traffic.libsyn.com/thea…cChipmakingCoryphaeus.mp3




    Quote

    "When Sirius included a 5 MB hard drive, Gates said he couldn’t do MS DOS on the new machine. Sirius did it and added it as a contribution to DOS (Dave thought it was v2). "

    Hallo,
    grundsätzlich funktioniert das Erstellen einer Systemdiskette wie bei jedem anderen MS-DOS Rechner. Allerdings leicht unterschiedlich je nach Version. Mit FORMAT und dann SYS (bzw. manchmal auch SYSCOPY genannt) oder bei neueren Versionen geht teilweise auch FORMAT mit /S als Parameter. Oder auch DISCCOPY und dann den unnötigen Ballast löschen. Voraussetzung ist natürlich, dass man die entsprechenden Tools auch auf der Diskette zur Verfügung hat.


    Zum Versionswirrwarr:
    MS-DOS 1.25 war die erste OEM-Version von MS-DOS für nicht IBM-Rechner. Die Bezeichnung 2.61 auf der Diskette bezieht sich nicht auf MS-DOS sondern auf die BIOS-Version. Beim Sirius ist das BIOS per Software implementiert und Bestandteil des Betriebssystems. Die Version 1.25 wurde meines Wissens mit BIOS-Versionen von 2.5 bis 2.71 ausgeliefert. Meistens wurde das dann als auf den Disketten mit Version "1.25/2.61" bezeichnet. Ab DOS Version 2.11 wurde 2.9x als BIOS verwendet (2.8 habe ich noch nie gesehen), ab DOS 3.1 dann BIOS 3.0x.


    Kleine Info am Rande. Die erste MS-DOS Version, die Festplatten unterstützte war nicht wie landläufig angenommen DOS 2.x sondern Sirius MS-DOS 1.25, allerdings nicht von Microsoft programmiert sondern von Sirius selbst. Die Festplattenversion des Sirius kam vor dem XT mit Festplatte auf den Markt und da MS-DOS damals keine Festplatten unterstützt hat, musste Sirius das Problem selbst lösen und hat die notwendigen Treiber und Erweiterungen selbst programmiert und eingebunden. Teile des Codes sind dann später von Microsoft in Version 2.0 integriert worden, die dann Festplatten unterstützt hat. Da DOS 1.x keine Unterverzeichnisse unterstützt, wurden die Platten damals meistens in diverse kleine Partitionen à 1 oder 2 MB aufgeteilt. Entsprechend gab es Config-Dateien, die mittels AUTOSET.EXE die Partitionierung vorgenommen haben: z.B. 2AND8X1.CFG = 1 x 2MB Sytem + 8 x 1MB Daten mit Laufwerksbuchstaben bis J... Durch die Festplattentreiber ist das System+BIOS auf >64kB angewachsen, weshalb diese Versionen nicht auf alten Floppy-Maschinen mit P1 Bootrom laufen. Die HD-Rechner wurden mit einem angepassten Bootrom ausgeliefert (noch kein Universal Bootrom, das kam erst später).


    Zum Format:
    Wie schon geschrieben gibt es SS und DS Versionen des Sirius mit 600 bzw. 1200 kB. Single Sided Disketten können von beiden gelesen werden, Double Sided nur in den DS Laufwerken. Im Gergensatz zum IBM-Format werden die Seiten nacheinander beschrieben und nicht Spur für Spur abwechselnd. Aufgezeichnet wird mit GCR und unterschiedlichen Rotationsgeschwindigkeiten, dadurch sind auf DD Disketten so hohe Kapazitäten möglich (Offizielles Format ist DD 96 TPI). IBM hat 1,2MB dann später mit dem AT bei konstanter Rotation und HD Disketten erreicht. Die Zonenaufteilung beim Sirius ist auf Ober-und Unterseite der DS Disketten auch noch unterschiedlich... Alles in allem ein sehr komplexes Format. Einzige Chance da etwas mit anderen Laufwerken zu lesen ist mit spezieller Hardware. Mit Kryoflux und PC klappt Raw-Auslesen ganz gut, es gibt aber (bisher?) keinen Konverter. Theoretisch wäre also auch das Schreiben von Sirius Disketten mit Kryoflux möglich. Discferret habe ich leider nicht, dort steht in der Doku, dass es einen Sirius Konverter dafür gibt.


    Systemdisketten kann ich gerne auch zur Verfügung stellen. Sobald man eine inkl. SYS.EXE (am Besten 2.11) hat und Daten vom PC auf den Sirius übertragen kann, sollten auch das Erstellen anderer Versionen kein Problem sein.


    Viele Grüße,
    Axel

    Irgendwo habe ich glaube ich auch eine Beschreibung der Slots. Werde demnächst mal wühlen...


    Mein "Produktivsystem" läuft übrigens mit Vollausbau 896 kB, voll nutzbar (256 kB on board + 512k + 128k + DMA + Xebec HD Controller)! :)


    Womit auch hoffentlich das weit verbreitete Gerücht der 640 kB-Grenze von DOS widerlegt wäre. Das liegt am Aufbau des IBM-PC und nicht an MS-DOS. IBM hat halt schon ab A0000 Mapping betrieben, im Sirius wird der Adressbereich ab E0000 für Hardwaremapping verwendet. In der vollen Ausbaustufe kann man damit sogar recht weitreichende IBM-Kompatibilität mit Emulatoren erreichen, die dann den Speicherbereich ab B0000 bzw. B8000 für Video reservieren und per TSR an F0000 übersetzen. IBM BIOS wird dann ebenfalls per Software emuliert, einzig direkte Hardwarezugriffe per IN/OUT funktionieren nicht. Dafür gab es meines Wissens aber Erweiterungskarten, die alle I/O Port Zugriffe abgefangen haben und per Interrupt an eine Software-Routine weitergereicht haben.



    Ich werde sicher noch viele Fragen hier haben - mein Background ist eben das ich den Sirius nicht von früher kenne, sondern die Maschine für mich neu ist. Hat mich aber schon lange interessiert, daher freue ich mich jetzt mal damit beschäftigen zu können.

    Immer her mit den Fragen. Ich freue mich über jede Diskussion zu dem Thema :)
    Vielleicht sollten wir demnächst auch mal einen Thread zum Softwaretausch starten, damit die vielen funktionsfähigen Sirius/Vicki auch ordentlich genutzt werden können...

    Hallo,
    die Wahl des Erweiterungsslot ist normalerweise unwichtig. Ich hatte zumindest noch nie Schwierigkeiten, egal wo ich Karten platziert habe. Bei deiner Karte deutet tatsächlich vieles auf einen RAM-Fehler hin. Es gibt beim Sirius ja keine CMOS-Einstellung, DIPs oder Ähnliches bezüglich der RAM-Größe. Das wird alles durch testweises Schreiben pro 64kB Speicherblock vom Boot ROM ermittelt. Bei defekten RAM-Bausteinen kann das dazu führen, dass ein Bereich einfach nicht als RAM erkannt wird.


    Unwahrscheinlich, aber doch möglich wäre natürlich auch, dass an den DIP-Schaltern etwas verstellt wurde.


    Gruß,
    Axel

    Super! Einen Sirius haut so einfach eben nichts um :-)


    Also technisch müsste der Rechner auch mit F3F7 laufen. Wenn der Chip im anderen Rechner bootet, kann es eigentlich nur an den Jumpern liegen. Evtl. muss man sich den Schaltplan auch nochmal genau anschauen, ob die Einstellungen mit dem 64kBit ROM wirklich passen. Kann man auf dem anderen Board dazu etwas erkennen?


    Gruß,
    Axel

    Hallo,
    man müsste prüfen an welcher Adresse das ROM in einen Loop geht, bzw. falls es ein Universal ROM ist, welcher Wert auf den I/O Bus gesendet wird (mit OUT DX=0FFFFh,AL). Wenn der Rechner in einer solchen Schleife hängt, müssten regelmäßige Muster auf A0-A19 bzw. D0-D7 zu erkennen sein, die man dann auswerten kann. Da du selber ROMs brennst, wäre natürlich auch eine Möglichkeit sich schnell ein eigenes Diagnose ROM zusammenzubasteln, das z.B. über die LEDs an den Diskdrives (als eine Art Morsecode o.ä :-) ) eine Statusmeldung gibt, falls kein Signal auf dem Monitor erzeugt werden kann. Allzu aufwendig sollte das im ersten Schritt nicht sein.
    Leuchten die LEDs mit dem neuen ROM eigentlich immer noch nach dem Einschalten? Welche ROM Version verwendest du im Moment?


    Gruß,
    Axel

    Habe mir das mit dem Jumper gerade nochmal angeschaut. Bist du dir sicher, dass das so richtig ist? Wenn ich das richtig interpretiere, hast du anstatt der zwei 2732 a 4KB jetzt einen 8KB. Die alternativen Jumper auf dem Schaltplan sprechen aber von 64K. Könnte es sein, dass das ROM dann bei Adresse F0000 platziert wird? Dann kann es eigentlich nicht funktionieren. Oder bin ich gerade komplett auf dem falschen Dampfer?

    Die vielen Interessierten hier im Forum haben mich motiviert endlich einen schon lange geplanten Blog über den Sirius zu starten.


    http://sirius1victor9000.blogspot.de/



    Dort habe ich unter anderem ein paar Schematics hinterlegt. Ich bin mir nicht sicher, ob die schon alle bekannt bzw. vorhanden sind. Aber in jedem Fall sollten sie hilfreich sein. Seite 16 enthält auch den 8088.


    Im Falle eines Universal ROM Fatal Error Loop, wird übrigens immer mit DX=FFFF auf den I/O Port geschrieben. AL enthält dann den Fehlercode.

    Denke auch,dass irgendwas noch nicht stimmt. Die Dips regeln einerseits die startadresse und andererseits die Bestückung. Wenn mehr ram auf der Karte ist, könnte die Bestückung noch nicht richtig eingestellt sein. Wenn es wirklich die Karte ist wäre das pin 5 bis 7. Bzw. 4 bis 6 wenn man wie ein Informatiker von null los zählt ;)

    Der Vollständigkeit halber auch noch Sirius Keyboard bzw. Floppy ROMs.


    Ergänzende Info zu den obigen Boot ROMs:
    P1 ist bei den Sirius 1 am weitesten verbreitet und das einzige ROM, das nur Betriebssysteme <64k laden kann
    Die HD Version hat diese Einschränkung schon nicht mehr.


    Die Universal ROMs können so ziemlich alles booten: Floppy, HD, Netzwerk, Serial Port (!)


    Versionskennzeichen befindet sich bei den Universals immer an FFFF:000A bis FFFF:000B als little endian 16-bit Eintrag (bzw. 1FFFA in den Dateien).
    FxF3=Sirius 1/ Victor 9000
    FxF2=Vicki
    Fx ist jeweils die Versionsnummer. Bisher dachte ich, dass 3.7 die letzte Version war (erzeugt F3F7 und F2F7). Da Georgs Vicki ein F2F8 hat, müsste es eigentlich auch ein F3F8 für den Sirius geben.


    Laut Doku gibt es auch noch folgende Versionskennzeichen:


    AAAA--for floppy-only ROMs (So ein ROM habe ich nie gesehen)
    01FF--for floppy/hard disk ROMs (Das P1 Floppy ROM hat diese Kennzeichnung, insofern stimmt das nicht mit der Doku überein)
    F1F1--for the diskless NetWork Station (habe ich ebenfalls nie gesehen und wusste auch nicht, dass es so eine Maschine gab. Eventuell nur im Entwicklungsstadium?)


    Ansonsten gibt es noch verschiedene ISSUE ROM Versionen, die auf dem Universal ROM aufbauen.
    Für den Victor Sirius VI müssen ebenfalls verschiedene ROMs existieren.

    Wenn es hilft, kann ich auch den kommentierten Original-Source Code vom 3.6 Universal Boot-ROM zur Verfügung stellen. P1-ROM liegt mir nur Binary vor, das ist deutlich simpler und weniger aussagekräftig was Fehlermeldungen angeht gestrickt. Den groben Ablauf findet man hier
    http://www.actsirius1.co.uk/pages/rom.htm


    http://www.actsirius1.co.uk/pages/tech/appo.htm



    Im Universal werden zuerst BT1INIT.ASM (ganz hinten ist "jmp far ptr reset_code" an FFFF:0) und dann BT1BASE.ASM ausgeführt (beim Vicki VCKINIT.ASM). Code ist relativ gut dokumentiert.



    Ich bin übrigens an allen Boot-ROMS für den Sirius bzw. Vicki interessiert. Ich selbst habe Univ. 3.6 (Source+Bin), Univ. 3.7 (Bin), P1 Floppy, P1 HD. Ich würde mich über weitere Binaries freuen (z.B. ISSUE ROMs, oder auch ROMs vom Victor/Sirius VI).


    Edit:


    Zu den LEDs: die LEDs werden über einen der drei 6522 gesteuert. Der muss dafür nicht initialisiert werden, die LEDs sind direkt mit je einem Pin des 6522 verbunden, also muss zumindest ein Zugriff auf einen der 6522 erfolgreich gewesen sein.

    Edit2:
    Die Suche nach ROM-Erweiterungen dient zur Identifizierung von Diagnose-Karten, die früher vom Field Service genutzt wurden. Die haben sich auf D0000 gemappt und dann bei der Fehlerbehebung/-suche geholfen. Sobald an D0000 ein ROM gefunden wird verzweigt das BootROM sofort dorthin.



    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