Atari ST - OS-9/68K - Boot Failure

    I'm stuck :(


    Ohne die Hilfe erfahrener Atarianer (oder Ataristen :/) komme ich nicht weiter. Wie in RE: Atari 1040 STE Platine Rev 5.1 beschrieben habe ich jetzt einen Atari STE mit 4MB RAM, TOS 2.06 und Ultrasatan Laufwerk am Start. Gerüchteweise gibt es dafür ja Cumana OS-9/68K 2.3 in den Untiefen des Internets und tatsächlich habe ich nach ausgiebiger Suche auch ein paar Images mit für mich zu knappen "Quick Instructions" gefunden.


    Achtung: Ich habe noch keinen HD Driver für das Ultrasatan Laufwerk gekauft und hoffe auf Empfehlungen, damit ich auch den richtigen nehme.


    Wie beschrieben habe ich das OS9AtariHD.img mit Win32 Disk Images in eine 4GB SD-Card geschrieben. Die steckt in der linken Ultrasatan Schublade. Das OS9Image.img habe ich ebenso in eine 8GB SD-Card gepackt. Die steckt in der rechten Schublade, aber mit oder ohne der Karte ergibt sich kein Unterschied.


    Wenn ich damit den STE einschalte kommen nach dem Speichertest diese Ausgaben:


    Mein Problem ist nun die Diskette. Diese OS-9 Version verwendet ausschließlich 256 Byte Sektoren, was sonst weder auf dem PC noch auf den Atari üblich ist. Die Floppy Hardware kann es, aber die Software unterstützt es nicht. Die Empfehlung "fdutils on Linux" scheint mir nicht zielführend zu sein. Ich habe die Doku von fdutils studiert und an diversen Stellen gefunden, dass nur Sektoren >= 512 Byte damit unterstützt werden.


    Also habe ich versucht das OS9Boot.dsk Image mit der ImageDisk auf eine 3.5" Diskette zu bekommen. Anhand von OS-9 Literaur und HxD Besichtigung der Image Datei muss das Diskettenformat zweiseitig, 80 Tracks, 18 Sektoren á 256 Byte pro Track mit Interleave=3 sein. Ich konnte zwar mit IMD eine Diskette in der Geometrie formatieren und mit BIN2IMD das vorliegende Image in ein IMD verdauliches Format umwandeln, aber das Ergebnis funktioniert nicht. Es dauert eine Weilchen und dann kommt im Abstand mehrerer Sekunden:



    Was mach ich falsch? Was kann ich tun? Hat irgendwer OS-9/68K auf dem Atari in Benutzung und kann mir ein paar Tipps geben?


    VG Albert

    Zitat von as58

    Also habe ich versucht das OS9Boot.dsk Image mit der ImageDisk auf eine 3.5" Diskette zu bekommen. Anhand von OS-9 Literaur und HxD Besichtigung der Image Datei muss das Diskettenformat zweiseitig, 80 Tracks, 18 Sektoren á 256 Byte pro Track mit Interleave=3 sein.

    Fehler $f7 = 247 ist Seek Error.


    Im Normalfall: Befehl geht an Treiber und dann ans Laufwerk eine bestimmte Spur anzufahren. Dann wird gelesen. Wenn keine geeignete Spurnummer oder nicht die gewünschte Sektornummer vorbeikommt, gibt's solch einen Fehler. Möglicherweise auch bei noch anderen Ursachen. Wenn gar keine Daten gekommen wären, wäre eine andere Fehlernummer erzeugt worden. Vermutlich. Ein Seek Error könnte auch kommen, wenn Sektor 0 gelesen werden soll, aber die Sektornumerierung bei 1 beginnt.

    Ich kenne den Treiber nicht, und es wird eher keine Doku dazu geben, unter welchen Umständen welche Fehlernummer kommt. Das war damals eher
    unüblich.


    BTW der Interleave spielt keine lebenswichtige Rolle. Was anderes als 3 wird lediglich die Leserate spürbar herabsetzen.


    Gruß, Ralf

    • Offizieller Beitrag

    Zu den fdutils-Geschichten: Ich hatte Dir ja SuSE 9.3 empfohlen. Jetzt sehe ich gerade, dass die fdutils Version dort ziemlich alt ist und die Einträge für /etc/mediaprm nicht verdaut. Dort müsste ja ua. stehen:


    Code
    "COCO40DS":
DS DD sect=18 cyl=40 ssize=256 tpi=48
"COCO80DS":
DS DD sect=18 cyl=80 ssize=256 tpi=96

    Ich schaue jetzt mal, ob sich fdutils nicht updaten lässt und melde mich wieder.


    Alternativ wäre ein neueres Linux eine gute Idee, dann aber an einem Rechner mit echter Floppy. Mit USB Floppy geht das alles nicht.

    Denn Feindschaft wird durch Feindschaft nimmermehr gestillt; Versöhnlichkeit schafft Ruh’ – ein Satz, der immer gilt. Man denkt oft nicht daran, sich selbst zurückzuhalten; Wer aber daran denkt, der lässt den Zorn erkalten. Sprüche von Buddha, aus dem ‹Dhammapada›.


    Mein Netz: Acorn | Atari | Milan | Amiga | Apple //e und IIGS | Macintosh | SUN Sparc | NeXT |SGI | IBM RS/6000 | DEC Vaxstation und Decstation| Raspberry Pi | PCs mit OS/2, BeOS, Linux, AROS, Windows, BSD | Stand-alone: Apple //c und III | Commodore 128D | Sinclair QL | Amstrad | PDAs

    Zitat von yalsi

    Ich schaue jetzt mal, ob sich fdutils nicht updaten lässt und melde mich wieder.

    Danke für Deine Hilfe. Ich verstehe das offengestanden maximal ansatzweise, habe mich mit Linux nie befasst. Ja, ich habe ein Board mit echter Floppy und onboard FDC und ImageDisk unter DOS bescheingt dem die Fähigkeit 256 Byte MFM Sektoren schreiben zu können.


    In dem installiertern SUSE 5.3 finde ich eine Datei /etc/fdprm, die wohl die Diskettenformate beschreibt, die aber m.E. alle von 512 Byte Sektoren ausgehen. Das benötigte OS-9 Format geht also nicht ab Werk. Wie würde ich herausfinden, ob in SUSE 5.3 eine Version von fdutils enthalten ist und wenn ja welche? Ich finde da nichts dergleichen, inbesondere keine Datei /etc/mediaprm.


    Du hattest mir auch einen Link auf fdutils-5.6 geschickt. Darin finde ich eine Datei mediaprm. In der ist als drittletzter Eintrag enthalten:


    "COCO720":

    DS DD sect=18 cyl=80 ssize=256 tpi=96 zero-based


    Das müsste doch eigentlich passen, wobei ich mir beim "zero-based" nicht sicher bin. Ich bin mir auch nicht sicher, ob ein NEC 765 FDC überhaupt Sektornummer null schreiben kann. Das wird in keinem mir bekannten Datenblatt explizit angesprochen. Beschrieben werden immer die IBM FM und MFM Formate, deren Track Layouts immer mit Sektor eins beginnen. Dasselbe gilt übrigens für die WD FDCs, die im Atari verwendet werden. Die Datenblätter schweigen sich ebenfalls darüber aus, ob Sektornummer null überhaupt schreib- und lesbar ist.


    Könnte ich diese fdutils-5.6 denn einfach unter SUSE 5.3 nutzen? Was müsste ich dafür tun?

    • Offizieller Beitrag

    Gestern abend habe ich herumexperimentiert, aber mit wenig Erfolg.


    Die fdutils zu kompilieren, war kein Problem, zumindest mit SuSE 9.3. Den gcc usw. hatte ich sowieso schin installiert, mit ./configure , make und make install (als root) aus dem Quellcodeverzeichnis war die Sache schnell erledigt.


    Das Problem kommt bei der Benutzung. Mit setfdprm kann ich zwar das Format einstellen, superformat wirft dann aber Fehlermeldungen beim Beschreiben von Spur 0 aus. Das bestätigt wahrscheinlich Deinen Verdacht- meine Floppy kann darauf nicht zugreifen.


    Das alte fdformat ignoriert die Einstellungen von setfdprm und schreibt 9 Sektoren mit 512 Bytes.


    Ich gucke nächstes Jahr mal, ob eines meiner Notebooks mit echter Floppy da eher klar kommt. Vielleicht habe ich auch mit dem Milan unter MiNT Glück, der hat auch eine Floppy.

    Denn Feindschaft wird durch Feindschaft nimmermehr gestillt; Versöhnlichkeit schafft Ruh’ – ein Satz, der immer gilt. Man denkt oft nicht daran, sich selbst zurückzuhalten; Wer aber daran denkt, der lässt den Zorn erkalten. Sprüche von Buddha, aus dem ‹Dhammapada›.


    Mein Netz: Acorn | Atari | Milan | Amiga | Apple //e und IIGS | Macintosh | SUN Sparc | NeXT |SGI | IBM RS/6000 | DEC Vaxstation und Decstation| Raspberry Pi | PCs mit OS/2, BeOS, Linux, AROS, Windows, BSD | Stand-alone: Apple //c und III | Commodore 128D | Sinclair QL | Amstrad | PDAs

    sollte das nicht eigentlich auch mit SAMDisk funktionieren? Ich konnte damit zumindest auch Disks mit 128 und 256 Byte Sektoren lesen - dann sollte Schreiben doch auch machbar sein. Und mit irgendeinem der "raw-Tools" sollte auch eine Konvertierung des vorliegenden Images zu etwas mit SAMDisk Verdaubarem möglich sein?

    Zitat von schufti

    sollte das nicht eigentlich auch mit SAMDisk funktionieren?

    Das kenne ich nicht, ist aber anhand des Namens leicht zu finden. Danke, schaue ich mir an.


    Früher - so vor rund 30 Jahren - hätte ich mir das an einem verregneten Nachmittag mit Turbo-Pascal unter DOS wohl selbst programmiert. Man vergiss doch verdammt viel in so langer Zeit ohne Programmierpraxis :(


    Macht man es selbst, ist man flexibler und kann ausprobieren und anpassen. Oder weiß vielleicht jemand verbindlich zu, welches Betriebssystem - insbesonderer OS-9/68K - oder welches Zusatzprogramm eine zweiseitige Diskette wie mit einem Image beschreibt? Zuerst beide Seiten der Spur 0 bevor es zur nächsten Spur geht oder zuerst die ganz Seite 0 Spur 0 .. 79 bevor die Seite 1 an die Reihe kommt?

    • Offizieller Beitrag

    Im Versuch oben hat superformat immer je Spur erst Kopf 0 und dann Kopf 1 angesprochen.

    Denn Feindschaft wird durch Feindschaft nimmermehr gestillt; Versöhnlichkeit schafft Ruh’ – ein Satz, der immer gilt. Man denkt oft nicht daran, sich selbst zurückzuhalten; Wer aber daran denkt, der lässt den Zorn erkalten. Sprüche von Buddha, aus dem ‹Dhammapada›.


    Mein Netz: Acorn | Atari | Milan | Amiga | Apple //e und IIGS | Macintosh | SUN Sparc | NeXT |SGI | IBM RS/6000 | DEC Vaxstation und Decstation| Raspberry Pi | PCs mit OS/2, BeOS, Linux, AROS, Windows, BSD | Stand-alone: Apple //c und III | Commodore 128D | Sinclair QL | Amstrad | PDAs

    Genauso macht es die ImageDisk Software unter DOS sowohl beim Formatieren einer Diskette als auch beim Schreiben eines Image, das ja in einem Zug formatiert und schreibt. Theoretisch ist es natürlich denkbar, dass dabei das Image nicht linear hintereinander weg verbraucht wird, sondern die Seite 0 ab Image Anfang und Seite 1 ab Image Mitte geschrieben wird.


    Optimal wäre es, wenn sich jemand finden würde, der OS-9/68K auf dem Atari laufen hat und von seiner Boot-Diskette unter DOS damit ein .IMD erzeugen könnte. Das würde alle Unklarheiten beseitigen.

    Ein Test mit einem Teac FC-1, also Diskettenlaufwerk am SCSI-Bus, an der MVME177: Seek Error gibt's hier in allen Lebenslagen, wenn das Diskettenformat nicht paßt, also insbesondere auch mit einer neuen, unformatierten Diskette. Seek Error ebenfalls beim Zugriffsversuch mit falscher Sektorgröße. Jedoch ein $241 (Bad disk sector number) beim Zugriff auf das /d0-Format mit dem /d0u-Deskriptor.


    AFAIK kann das FC-1-Laufwerk bei DD nur bis zu 16Sektoren je 256Byte pro Spur und kein 18-Sektor-Format. 18 Sektoren waren bei 3,5" sehr speziell.


    Ansonsten sagt mir das Step-Geräusch beim Formatieren sowie ein Programm, das alle Sektornummern mit aufsteigender Nummer liest, daß die Spuren offensichtlich nach diesem Schema benutzt werden: 0-unten, 0-oben, 1-unten, 1-oben, ...


    Dieses d0-Format sollte dasselbe sein wie seinerzeit beim Atari.


    Gruß, Ralf

    Wenn unterschiedliche Sektorgrößen möglich sind, läuft auf der MVME177 aber eine neuere OS-9/68K Version als die 2.3 vom Atari, nicht wahr? Kann man die Erkenntnisse trotzdem übertragen? 2.3 nutzte ja m.W. ausschließlich 256 Byte Sektoren.


    Die 18 Sektoren hat mir die ImageDisk Software problemlos formatiert, ebenfalls mit einem TEAC Floppy, aber natürlich nicht die SCSI Version. Ist die Laufwerksmechanik beim FC-1 identisch mit der der PC Version? Die Begrenzung auf 16 Sektoren könnte dann vielleicht durch die SCSI Platine bedingt sein.


    Besteht die Möglichkeit herauszufinden, ob die Sektornummern ab null oder eins gezählt werden?

    Das OS-9-Dateisystem auf Disketten hat üblicherweise ausschließlich 256-Byte-Sektoren. Aber bei Benutzung vom PCF (MS-DOS File Manager) werden selbstverständlich 512-Byte-Sektoren genommen. Geht ja nicht anders, wenn man eine FAT12-Diskette ins Laufwerk am OS-9-Rechner steckt. Genau das hatte ich probiert.


    Das Format-Programm sagt: "Sector Offset 1" bei d0 und d0u. Aber das hattest Du bereits im OS-9 Insights gelesen.

    Zitat von yalsi

    Das Problem kommt bei der Benutzung. Mit setfdprm kann ich zwar das Format einstellen, superformat wirft dann aber Fehlermeldungen beim Beschreiben von Spur 0 aus. Das bestätigt wahrscheinlich Deinen Verdacht- meine Floppy kann darauf nicht zugreifen.


    Das alte fdformat ignoriert die Einstellungen von setfdprm und schreibt 9 Sektoren mit 512 Bytes.

    Hat bei mir einwandfrei funktioniert.

    (SuSE Linux 13.2 / fdutils-5.5)

    entscheidend ist der Parameter zerobased (Sektoren starten bei 0) !

    Diskette bootet einwandfrei auf Atari 1040STFM.

    Moin,


    ich habe die Images mal im hatari-Emulator (STE mit 4MB) probiert:



    man kommt bis zu einem Prompt, dann bin ich mit meinem Latein am Ende :fp:



    die Diskette ist damit aber auch nicht zu booten. Der Emulator ist recht fixiert auf 512 Bytes/Sektor. Ich habe zwar mal ein paar Modifikationen gemacht, das hilft aber nix. Ich nehme mal an, dass der Zugriff direkt durch die FDC-Register läuft und damit ein Stück weit am Emulator vorbei.

    Zitat von lost-bit

    man kommt bis zu einem Prompt, dann bin ich mit meinem Latein am Ende :fp:

    Das ist das Prompt der ganz normalen Shell bei diesem OS-9. Herzlichen Glückwunsch! Geschafft. Z.B. mit "mdir" könntest Du die Liste der geladenen Module anzeigen lassen, mit "dir -e /h0" den Inhalt vom Root-Verzeichnis der "Festplatte".


    Zitat von lost-bit

    Ich habe zwar mal ein paar Modifikationen gemacht, das hilft aber nix. Ich nehme mal an, dass der Zugriff direkt durch die FDC-Register läuft und damit ein Stück weit am Emulator vorbei.

    Selbstverständlich braucht das OS-9 einen eigenen Diskettenlaufwerkstreiber, um 18Sektoren und 256Byte-Sektoren ansprechen zu können. Das geht ausschließlich über einen eigenen Treiber, der sich mit dem Chip unterhält. Die WD17xx- und WD27xx-Controller waren seinerzeit Standard-Controller und in diversen anderen Rechnern eingebaut.


    Gruß, Ralf


    Nachtrag zum 2. Bildschirmfoto: interessant wäre die letzte Meldung vor der "Can't install trap handler"-Meldung.

    Zitat von lost-bit

    Moin,


    ich habe die Images mal im hatari-Emulator (STE mit 4MB) probiert:


    die Diskette ist damit aber auch nicht zu booten. Der Emulator ist recht fixiert auf 512 Bytes/Sektor. Ich habe zwar mal ein paar Modifikationen gemacht, das hilft aber nix. Ich nehme mal an, dass der Zugriff direkt durch die FDC-Register läuft und damit ein Stück weit am Emulator vorbei.

    Auf einer richtigen Hardware funktioniert das natürlich perfekt. :)

    Da kommen keine Fehlermeldungen.

    das mit dem FDC habe ich mir schon gedacht, das ist mit anderen "fremden" OS genauso..



    so sieht es beim Start aus



    da fehlt wohl was elementares :roll:

    Zitat von lost-bit

    da fehlt wohl was elementares :roll:

    Ja. Möglicherweise der Zugriff auf die "Festplatte", also das Dateisystem "/h0" auf der SDHC-Karte.


    Wenn das Modul "cio" nicht da ist, funktionieren die Standardbefehle vom damaligen OS-9 nicht, da sie alle gegen diese Bibliothek gelinkt sind. D.h. die Fehlermeldung ist echt und ernst zu nehmen. Aber das "dir" scheint loslaufen zu wollen. Eigentlich dürfte die shell genausowenig laufen, weil auch die die Bibliothek "cio" braucht. Hm. Vertrackt, wenn man den Rest nicht kennt, also insbesondere nicht den Inhalt vom allerersten Code-Modul nach dem Kernel, dem sysgo oder systs. Und auch nicht die Skriptdatei "startup".

    Zitat von RalfK
    Zitat von lost-bit

    da fehlt wohl was elementares :roll:

    Ja. Möglicherweise der Zugriff auf die "Festplatte", also das Dateisystem "/h0" auf der SDHC-Karte.

    Zum Booten wird keine Festplatte benötigt. Mein ATARI ST hat (leider) auch keine Festplatte.

    Deshalb kann ich die komplette Software derzeit auch nicht installieren.

    Aber ein paar Kommandos kann man eingeben, und es kommen keinerlei Fehlermeldungen.

    Ich wollte eigentlich nur beweisen, daß man mit Linux diese OS-9 Disketten erstellen kann.

    Zitat von RalfK

    Wenn das Modul "cio" nicht da ist, funktionieren die Standardbefehle vom damaligen OS-9 nicht, da sie alle gegen diese Bibliothek gelinkt sind. D.h. die Fehlermeldung ist echt und ernst zu nehmen. Aber das "dir" scheint loslaufen zu wollen. Eigentlich dürfte die shell genausowenig laufen, weil auch die die Bibliothek "cio" braucht. Hm. Vertrackt, wenn man den Rest nicht kennt, also insbesondere nicht den Inhalt vom allerersten Code-Modul nach dem Kernel, dem sysgo oder systs. Und auch nicht die Skriptdatei "startup".


    naja, alles halb so wild, ist eben nicht die reale Hardware, mir ging es zunächst darum, zu sehen, ob es mit einem Emulator startbar ist, bzw. die HD-Diskimages soweit ok sind. Um eine Fehlerquelle auszuschliessen, da as58 ja im BootFailure hängengeblieben ist. Wenn ich das für mich jetzt weiterverfolge, würde ich auch auf den echten STE wechseln ;)

    Trotzdem vielen Dank!

    Nach meinem Kenntnisstand zum Cumana-OS-9 für den ST bootet das von Festplatte oder (XOR!) von Diskette. Damit das eingeleitet werden kann, wird der OS-9-Bootloader unter TOS wie ein Anwenderprogramm gestartet, das dann allerdings die Hardware vollständig übernimmt und die Relikte vom TOS im RAM plattmacht. Also "no return".

    Und auf der Bootdiskette ist u.A. ein 'setup' Programm drauf, mit der man die Festplatte formatieren

    und die Disketten auf die Festplatte kopieren kann.

    Ich weiß allerdings nicht, ob Cumana OS-9 mit Ultrasatan und SD Cards zurecht kommt ?

    Einmal editiert, zuletzt von ngc224 ()

    Zitat von ngc224

    Und auf der Bootdiskette ist u.A. ein 'setup' Programm drauf, mit der man die Festplatte formatieren

    und die Disketten auf die Festplatte kopieren kann.

    Ich weiß allerdings nicht, ob Cumana OS-9 mit Ultrasatan und SD Cards zurecht kommt ?

    Der Frager, mit dem ich auch einiges per Mail geklärt habe, hat ein lauffähiges Image für die SD-Karte "irgendwoher" bekommen. Genau in diesem Bereich scheint es bei dem Installationszeug vom alten Cumana-OS-9 etwas zu haken, vielleicht auch nur im Zusammenspiel mit einer neuen Ersatzlösung wie dem Ultrasatan-Laufwerk.


    Ich hatte beispielsweise mit meinem ST eine alte SH204-Festplatte geerbt, auf der ich Relikte von einem ehemals installierten OS-9 fand. Da war dieser Bootloader drauf, aber keine OS-9-Partition (mehr).


    Mir hatte vor etlichen jahren ein Atarianer mehr als geholfen solch eine OS-9-Installation einzurichten. Ich kenne mich allerdings überhaupt kein bißchen mit den Ataris und TOS aus, so daß ich an dieser Stelle nur auf meine OS-9-Kenntnisse zurückgreifen kann.

    Zitat von as58
    Zitat von RalfK

    Also "no return".

    Das kann ich bestätigen. Wenn ich wie eingangs beschrieben vorgehe, kann man auch per RESET den Atari nicht mehr zurückholen. Es hilft nur aus- und wieder einschalten, damit er sein TOS wieder mag.

    Das sollte so nicht sein, IMHO.

    Zitat von RalfK
    Zitat von as58
    Zitat von RalfK

    Also "no return".

    Das kann ich bestätigen. Wenn ich wie eingangs beschrieben vorgehe, kann man auch per RESET den Atari nicht mehr zurückholen. Es hilft nur aus- und wieder einschalten, damit er sein TOS wieder mag.

    Das sollte so nicht sein, IMHO.


    Das ist nicht so ungewöhnlich, wenn da entsprechende Vektoren und Variablen verbogen sind kommt der mit einem Warmstart (auch die RESET Taste) nicht wieder aus dem Sumpf. Da hilft nach dem Reset ein Ctrl-Alt-Shift-Del (das beschreibt den Speicher wieder sauber) und der Atari bootet einen richtigen Kaltstart (wie Aus/Anschalten ;)

    Habe es gerade nochmal ausprobiert. Wenn ich in dem eingangs beschrieben Zustand das Ultrasatan ausschalte, die nicht lesbare OS-9 Diskette auswerfe und RESET drücke, zeigt der Atari vier Bomben. Das hat glaube ich irgendwas mit 68K Exceptions zu tun. Mangels Atari Kenntnissen weiß ich aber nicht, ob man das Minenfeld ohne power down räumen kann.

    Zitat von lost-bit

    Das ist nicht so ungewöhnlich, wenn da entsprechende Vektoren und Variablen verbogen sind kommt der mit einem Warmstart (auch die RESET Taste) nicht wieder aus dem Sumpf.

    Achso :) Unter Reset verstehe ich, daß die /RESET-Leitung aktiv wird (sorry, bin in diesem Punkt etwas hardware-lastig). Wenn das nur ein Warmstart ist, ist klar, daß das OS-9 die Vektortabelle ab $0000.0000 im RAM anders genutzt hatte als TOS.


    Danke für den Hinweis, da werde ich meinem Atari 1040STF doch einen echten Resettaster gönnen. Irgendwannmal ...