Reset ein Ctrl-Alt-Shift-Del
Auch das funktioniert bei mir nicht. Gibt es dafür ein spezielles Timing? RESET und dann die vier Tasten gleichzeitig finden in 3 Millisekunden?
Bootet der Atari generell nicht mit eingestecktem, aber ausgeschalteten Ultrasatan?
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 ...
Der Taster hinten bedient schon das /Reset, fängt dann auch aus dem TOS an zu booten und checkt sehr früh verschiedene Magic-Numbers im RAM und verhält sich dementsprechend. So gab' es z.B. resetfeste RAM-Disks. (das war u.a. grossartig für eigene Software-Entwicklung)
Auch das funktioniert bei mir nicht. Gibt es dafür ein spezielles Timing? RESET und dann die vier Tasten gleichzeitig finden in 3 Millisekunden?
das ist schwierig einzuschätzen 
Es muss schon recht flott gehen
Bootet der Atari generell nicht mit eingestecktem, aber ausgeschalteten Ultrasatan?
das kann ich leider nicht beantworten, ich habe noch klassisch einen ACSI Hostadapter (ICD) angeschlossen und diesen vor etwa einem Jahr mit einem SCSI2SD bestückt. In diesem Fall ist egal, ob dieses externe Gespann an oder aus, die Kiste bootet immer.
Achso
Danke für den Hinweis, da werde ich meinem Atari 1040STF doch einen echten Resettaster gönnen. Irgendwannmal ...
Der Taster hinten bedient schon das /Reset, fängt dann auch aus dem TOS an zu booten und checkt sehr früh verschiedene Magic-Numbers im RAM und verhält sich dementsprechend. So gab' es z.B. resetfeste RAM-Disks. (das war u.a. grossartig für eigene Software-Entwicklung)
Das betrachte ich auch im OS-9-Kontext als normal. Es war dagegen die Rede davon, daß das Drücken der "Reset"-Taste eben gerade nicht zum Neustart führt, sondern nur ein Aus-Ein-Schalten.
daß das Drücken der "Reset"-Taste eben gerade nicht zum Neustart führt,
Doch, neu starten tut er, findet aber nichts ins TOS sondern wirft vier Bomben.
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
Danke für den Hinweis, da werde ich meinem Atari 1040STF doch einen echten Resettaster gönnen. Irgendwannmal ...
Frei nach Gertrude Stein: "Ein /RESET ist ein /RESET ist ein /RESET.
Tatsächlich springt der ST beim Drücken der Resettaste (und damit Ziehen der /RESET-Leitung) über die Vektoren im RAM. Wer auch immer die gesetzt hat. Nur beim Einschalten (Also wirklich "Netz an") wird über die ersten paar Bytes des RAMs ROM drübergeblendet, um an die hohen Adressen im ROM zu hüpfen. OS-9 überschreibt die Vektortabelle und springt damit in die eigene Reset-Routine.
Tatsächlich springt der ST beim Drücken der Resettaste (und damit Ziehen der /RESET-Leitung) über die Vektoren im RAM. Wer auch immer die gesetzt hat. Nur beim Einschalten (Also wirklich "Netz an") wird über die ersten paar Bytes des RAMs ROM drübergeblendet, um an die hohen Adressen im ROM zu hüpfen. OS-9 überschreibt die Vektortabelle und springt damit in die eigene Reset-Routine.
Eine Aufgabe für das nächste OS-9-Update
Das könnte man verbessern.
Tatsächlich springt der ST beim Drücken der Resettaste (und damit Ziehen der /RESET-Leitung) über die Vektoren im RAM. Wer auch immer die gesetzt hat. Nur beim Einschalten (Also wirklich "Netz an") wird über die ersten paar Bytes des RAMs ROM drübergeblendet, um an die hohen Adressen im ROM zu hüpfen. OS-9 überschreibt die Vektortabelle und springt damit in die eigene Reset-Routine.
Eine Aufgabe für das nächste OS-9-Update
Das könnte man verbessern.
Ist das eine Verbesserung? Ich würde eigentlich erwarten, dass ich, wenn ich im OS-9 bin und RESET drücke auch wieder im OS-9 rauskomme?
Ist das eine Verbesserung? Ich würde eigentlich erwarten, dass ich, wenn ich im OS-9 bin und RESET drücke auch wieder im OS-9 rauskomme?
Das ist offensichtlich Ansichtssache. Für mich ist der ST eine TOS-Maschine, auf der "zufällig" auch OS-9 läuft.
Alternativ kann ich mir vorstellen im OS-9 ein kleines Umschaltprogramm zu haben, das den Resetvektor nach Ansicht des Nutzers einstellt. Das ist ein geringer Aufwad, denn der Atari hat keinen Speicherschutz. Dort kann jeder die Vektoren überschreiben. Eine weitergehende Idee wäre aus dem ST eine reine OS-9-Maschine zu machen, indem die ROMs gegen welche mit OS-9-Inhalten getauscht werden. Umschaltbar wäre auch 'ne Option.
Moin!
nun doch noch ein Erfolg
man braucht beides, das Floppy- und HD-Image für ein erfolgreiches Booten:
auf einem 1040 STe mit 4 MB....
Schön
Was hast Du genau gemacht? Atari einschalten, und dann?
Gruß, Ralf
Was hast Du genau gemacht? Atari einschalten, und dann?
Das AtariHD.img wird nicht wirklich gebraucht. Ich habe mir da nur das bootosk.prg aus dem auto-Ordner geklaubt und auf eine Standard-Diskette gepackt. Das OS9-Image auf eine passende Platte geschoben (diskimager, oder was immer jeder dafür benutzt 
Dann die richtige Festplatten-ID im config-File eingestellt; bootosk.prg gestartet, Die "spezial"-Diskette eingelegt und boot from hd 'h' gestartet. Nach einiger Zeit ist man im prompt..
Eine Frage dazu: kann man irgendwo sehen, wie gross die Platte im OS9 partitioniert ist? Der 4GB File ist etwas sperrig und ich glaube auch nicht dass der wirklich so gross sein muss (mit den ersten 100MB auf einer ZIP-Disk geht es nämlich auch soweit)
Hast Du das Disketten Image irgendwie unter Linux geschrieben?
Nein, das hat bei mir auf dem PC nicht geklappt.
Ich habe nun auch IMD (auf einem schönen DOS Rechner) genutzt:
hier mein options-file für BIN2IMD
0 /u /v1 N=80 DM=5 SS=256 SM=0-17 /2Anschliessend den erzeugten .imd-File mit imd (ohne Sondereinstellungen) auf eine DD-Disk geschrieben.
Eine Frage dazu: kann man irgendwo sehen, wie gross die Platte im OS9 partitioniert ist? Der 4GB File ist etwas sperrig und ich glaube auch nicht dass der wirklich so gross sein muss (mit den ersten 100MB auf einer ZIP-Disk geht es nämlich auch soweit)
Mit "free /h0" bekommt man die wichtigsten Daten angezeigt. Mit "dcheck /h0" kann man das Dateisystem prüfen.
4GB braucht man zunächst sicher nicht. Das ist die maximale Größe vom Dateisystem, und das war vor ein paar Jahren die übliche Größe von SDHC-Karten. Partitionen gibt es nicht, zumindestens nicht damals mit diesem V2.3 für den Atari.
Hallo,
mit dem free Befehl bekomme 1953124 gesamte Sektoren und knapp 500 MB Speicherplatz. Interessant, anscheinend wird hier auch mit 256 Byte Sektoren hantiert. Dann wird wohl in dieser Implementierung immer die Hälfte eines physikalischen Sektors nicht genutzt 
mit dem free Befehl bekomme 1953124 gesamte Sektoren und knapp 500 MB Speicherplatz. Interessant, anscheinend wird hier auch mit 256 Byte Sektoren hantiert. Dann wird wohl in dieser Implementierung immer die Hälfte eines physikalischen Sektors nicht genutzt
Ok, Du hast die kleinere Datei aus dem Archiv genommen. Nehme ich an
Der Befehl "free /h0" sagt Dir die Sektorgröße, die Anzahl der freien Sektoren, den Name des Mediums, das Erstelldatum, usw.
Eine Sektorgröße von 256Byte sagt nichts über die tatsächliche Nutzung der SD-Karte. Es gab seinerzeit unter V2.3 Treiber, die 256Byte-Sektoren auf einer Festplatte mit 512-Byte-Sektoren emulierten. Glaub mir, ich weiß das
Eine Sektorgröße von 256Byte sagt nichts über die tatsächliche Nutzung der SD-Karte. Es gab seinerzeit unter V2.3 Treiber, die 256Byte-Sektoren auf einer Festplatte mit 512-Byte-Sektoren emulierten. Glaub mir, ich weiß das
so in etwa hatte ich das gedacht. Ich war nur etwas verwundert, da die Rechnung nicht "aufging"
Nein ich habe schon das grössere (~4GB) genommen, da ist das OS-9 System drin. Das andere ist ein native-Atari Image mit 1 Partition und ca. 500 MB Platz.
die 256Byte-Sektoren auf einer Festplatte mit 512-Byte-Sektoren emulierten
Etwas in der Art gab es auch bei CP/M. Ich hatte zwar keine Festplatte an meinem Apple II, aber zwei 8" Floppy-Laufwerke. CP/M nutzt ja logisch immer 128 Byte Records. Der Floppy Controller verwendet - Präsenz, tut er immer noch - die beiden standard IBM Format single-density mit 128 Byte Sektoren und double-density mit 256 Byte Sektoren, jeweils SS und DS. Ich habe mir damals für meine Konfiguration mit ALS CP/M Card ein BIOS dafür geschrieben, das damit völlig transparent umgehen kann. Da wird auch kein Platz verschwendet, sondern mit blocking / deblocking ggfs. zwei 128 Byte CP/M Records in einem 256 Byte Sektor abgelegt. So kann man z.B. eine SS/SD Diskette in A: und eine DS/DD in B: verwenden und Files hin und her kopieren.
Bei UCSD ist es umgekehrt, auf der oberen Ebene 512 Byte Blöcke, auf der Diskette verwaltet unter o.g. Formatierungen. Damit hatte ich aber nichts am Hut. UCSD war auf einem normalen Apple II einfach zu langsam.
So, jetzt aber weiter mit OS-9
hier mein options-file für BIN2IMD
Tja, klappt bei mir nicht, habs doppelt überprüft. Allerdings bekomme ich jetzt einen anderen Fehler:
Was könnte der wohl bedeuten?
Hmm.....
die Fehlermeldung hatte ich bei meinen Experimenten nicht.
Sind denn die HD-Images eingebunden und die IDs korrekt?
z.B.:
AtariHD.img mit win32diskimager auf SD Karte => linker Slot => ACSI ID 0 konfiguriert
Image.img mit win32diskimager auf 2. SD Karte => rechter Slot => ACSI ID 1 konfiguriert
Der Atari bootet und zeigt das Menu (das tut ja, wie oben schon gesehen) Im Menu 'c' configure nun die ID auf 1 stellen und speichern.
Jetzt würde ich sicherheitshalber nochmal booten, keine Ahnung wann diese Einstellung aktiv wird.
nun mit 'h' booten..
Das erklärt vermutlich die neue Fehlermeldung; das wirkliche OS9-Image wird nicht gefunden.. Offenbar steht da noch die ID falsch (im OS9 config)
Nein, die Meldungen kommen alle aus dem AtariHD-Image. Der Satan selbst gibt keine Meldungen aus.
Das mit den IDs hängt mit dem SCSI/ACSI-Bus zusammen, jedes Gerät (in diesem Fall Festplatten bzw. SD-Karten) bekommen eine eindeutige ID. Wie ich gesehen habe gibt es ein Config-Programm für den Satan, mit dem diese IDs den Slots zugewiesen werden können. Defaultmässig stehen die aber vermutlich auf 0 und 1
Der Bootstrapper vom OS9 muss natürlich wissen, wo er sein Image findet. (s.o.)
In der linken SD-Card stehen vier Partitions, die ich auf dem PC auch besichtigen kann. Es sind alles FAT Partitions:
In der rechten Karte ist eine Partion mit für den PC unbekanntem Typ:
Beim Booten wird nach meinem Verständnis aus der linken SD-Card die erste Partiton gebootet. Da steht das hier drin:
In deren AUTO Order finde ich:
Das ist das BOOTOSK.PRG, das Du dir auf eine normale ST Diskette ausgelagert hast. Korrekt?
Wenn ich beim Booten diese config Option wähle, erscheinen folgende Fragen:
Wie muss ich diese denn genau beantworten, damit es klappt?
Ist die Diskette anschließend immer noch Pflicht oder kann man auch komplett mit den SD-Cards leben?
Hallo,
Beim Booten wird nach meinem Verständnis aus der linken SD-Card die erste Partiton gebootet. Da steht das hier drin:
genau, auf den 3 anderen Partitionen ist im Prinzip nichts weiter drauf.
Das ist das BOOTOSK.PRG, das Du dir auf eine normale ST Diskette ausgelagert hast. Korrekt?
stimmt
Wie muss ich diese denn genau beantworten, damit es klappt?
DMA Address muss ziemlich sicher auf 1, alles andere muss so bleiben.
Ist die Diskette anschließend immer noch Pflicht oder kann man auch komplett mit den SD-Cards leben?
die ist leider trotzdem Pflicht.
wie gesagt, ich habe mir das bootosk auf eine Diskette kopiert, dann brauche ich das eine Image nicht, dann nur einmal von der Diskette booten, auf die andere wechseln und mit 'h' das OS9 durchstarten.
Tataaa!!!
Es bootet 
Keine Ahnung woran es gestern lag, aber ich habe die spezielle Diskette nochmal neu erzeugt auf einem anderen PC mit einem anderen Floppy Laufwerk. Ich habe jetzt nur noch die SD-Card mit dem OS-9 Image in der linken Ultrasatan Schublade. Es geht los mit einer normalen Atari Diskette mit dem BOOTOSK.PRG drauf. Dann "boot from floppy" und die spezielle Diskette rein und es bootet.
Das Filesystem auf der SD-Card ist okay.
Das auf der speziellen Diskette ist ebenfalls okay, aber dcheck meldet wie folgt:
Die Belegungs-Bitmap ist also nicht in Ordnung. Keine Ahnung, ob und wie man das reparieren kann.
Herzlichen Glückwunsch!
Zunächst zum OS-9: Kommandos ruft man einfach auf. Vollständige Pfade tippt man nicht. Das ist ja kein MS-DOS
Es gibt immer ein Execution Directory. Das kann man mit "chx" ändern. Typischerweise ergänzt man in der Environment die Suchpfadliste, um mehrere Unterverzeichnisse als "Execution Directory" zu nutzen.
Das nächste grundlegende Prinzip: normale, gute OS-9-Programme kennen immer die Option "-?". Dort werden die "arguments" und "options" erklärt. Bei dcheck ist das für den Reparaturmodus "-ry".
Danke. Ich gebe allen Helfern einen aus 
Die Kommandos muss ich natürlich lernen. printenv und setenv habe ich schon gefunden. Wie trennt man die Pfade im PATH? Auch mit ";"? Im Moment steht da nur
PATH=.:/dd/CMDS
Und gibt es einen für normale Menschen bedienbaren Editor?
Wie sage ich der Kiste, dass ich eine deutsche Tastatur habe?
Wie startet man diesen MGR?
Fragen über Fragen. Jedenfalls ist auf den ersten Blick reichlich Zeug in dieser Installation enthalten, das es zu entdecken gilt.
Nicht auszudenken, wenn ich so ein feines OS auf einer meiner flotten VME Karten hätte
