Jetzt hast Du zwar immer noch nicht gesagt, welcher Harddisk-Treiber benutzt wird (das wäre schon wichtig), aber es ist auch so klar.
Ich habe an mehreren Stellen erwähnt, daß ich am liebsten mit SCSI-Tools/HuSHi arbeite - an das Paket habe ich mich gewöhnt, seit ich eine erste HDD dauerhafter am Atari nutzen konnte und der ist zudem mW von den Autoren freigegeben! Auch habe ich immer, wenn es um verschiedene Treiber geht, dieses Paket mit Namen bezeichnet und die Anderen eher beiläufig erwähnt - das sollte doch genug erklären - und für Deinen weiteren Text: Laut Beschreibung kommt es sehr wohl mit TOS- und DOS-kompatiblen HDD Konstellatienen und Byteswap zurecht!
Also hier ist die Seite mit dem Treiber, wo für das Interface benutzt wird: http://atari.8bitchip.info/astams.php
Man kann auch ein normals IDE Kabel anschließen ohne die gedrehten Datenleitungen. Dann muß aber auch der Treiber für das normale IDE verwendet werden. Im Anhang sind beide Treiber plus Installationsprogramm enthalten. Dieser ist auch auf der verlinkten Seite zu finden. Zusätzlich noch ACSI Treiber. Wenn ich das so richtig verstehe, ist es mit dem ACSI Treiber auch möglich Partitionen größer als 32MB zu nutzen (z. B. Ultrasan) mit dem BigDOS Treiber. Ich werde das mal ausprobieren.
Burkhard, tausche das gedrehte IDE Kabel gegen ein Normales aus. Partitioniere deine CF Karte dann wie du es kennst mal mit SCSI Tools. Der Datendurchsatz wird aber dann nur noch die Hälfte der Geschwindigkeit gegebenüber Twisted IDE betragen. Gestern hatte ich es mal probiert und AHDI Treiber hat auch das IDE Interface erkannt, konnte aber anhand der Dos Partitionen nichts damit anfangen und wolte die SD Karte formatieren.
Für mich selbst wäre das sowieso unnötig ACSI Laufwerke zusätzlich mit dem IDE Interface zu betreiben.
JETZT haben wirs - das ist genau die Info, die ich von Anfang an, wo ich meine Probleme äußerte, brauche! Pera beschreibt dort (wenn ich das beim kurzen Überflug richtig erfaßte) in englisch, daß sein Treiber mit IDE und ACSI zurechtkommt - also muiß ich mich mal mit den Seiten dort befassen! Den Zugriff auf ACSI benötige ich dann ja auch nur am Anfang, um meine Daten zu übertragen!
Ich denke, dann komme ich ach weiter! Den Einsatz eines normalen IDE-Kabels werde ich mir nur unter Vorbehalt als LETZTE Möglichkeit einplanen
Ich denke, die nächsten Fragen werden bezüglich GOTEK kommen ...! Aber nicht jetzt! Wenn ich den Mega ST soweit nutzbar habe, kommt vor dem GOTEK Einbau erstmal MagiC an die Reihe! Ich denke, ich kann Dir dann auch schnell Tipps für die Anwendung geben!
Hallo Burkhard,
auch wenn meine Antwort schon ein wenig her ist. Warum verwendest Du keinen Bootmanager, wie XBOOT? Damit kann man auch DESKTOP.INFs für verschiedene Boot-KOmbis voneinander separieren. Klappt prima (hatte ich damals bei meinem MegaSTE mit Native TOS, MagiX/Gemini auch so gemacht).
Gruß
Johannes
Hallo Johannes!
Da wirst Du irgendwo was mißverstanden haben! Ich vetrwende einen Bootselektor, der mehrere Desktops verwalten kann (
STARTUP.PRG von einer PD aus der ST-Computer Schiene von MAXON) - diese werden in Dateien mit dem Namen
*.STD auf dem Bootlaufwerk abgelegt und die für die jeweilige Arbeitsumgebung zu verwendeten
ACC's und
PRG's des AUTO-Ordners kann man unter gleichem Namen abspeichern - dazu wird dann
*.STP verwendet. Bis zu 10 lassen sich dann per Funktionstaste direkt aufrufen und die betreffende
*.STD-Datei wird dann nach
DESKTOP.INF kopiert!
Es hat sich aber auch herausgestellt, daß ich bei meinen Tests mit dem EmuTOS was falsch gemacht habe ...!
Nein - jedem TOS sein eigenes Bootdrive zu geben, ist schon sinnvoll, da ich sonst drei unterschiedliche Bootselektoren auf einem Bootlaufwerk nutzen müßte nämlich einen, der die Desktops nach
DESKTOP.INF speichert (TOS 1.(0)4), einen für
NEWDESK.INF (TOS 2.(0)6) und einen fürs EmuTOS, für den ein eigenes Bootdrive zudem sinnvoll ist, da hier wohl trotz eigener Namensverwaltung auch ein Schreibzugriff auf
DESKTOP.INF zu erfolgen scheint!
Wie bereits anderswo geschrieben: EmuTOS ist DESKTOP.INF (und was drin steht) genauso wurscht wie TOS das entsprechende EMUDESK.INF
Das kann ich durch meine Tests mit EmuTOS nicht bestätigen - siehe vorhergehenden Absatz!
Ansonsten hätte ich unter TOS 1.(0)4 ohne Bomben wieder starten können müssen!
