HDDriver mit MonSTer ST

[Atari99]

Hallo,

endlich habe ich auch den HDD Treiber für meine Monster , HDDriver 9. Jetzt habe ich schon alles ausprobiert nur das richtige nicht. Ich möchte gerne weil die SD Karte 4GB groß ist mit mehreren Laufwerken arbeiten (aber wer braucht den Platz schon). Das wäre jetzt nicht das Problem, funktioniert ja auch. Aber ich kann mit meinem Mac (der ja eigentlich alle Laufwerke dann sehen würde lauf Anleitung) keine Partition anwählen da er die Karte nicht richtig erkennt. Eingestellt habe ich auch alles richtig , glaube ich mal. Einzeln kann man ja die Partition nicht TOS oder WIN , sondern alle. Also ist bei mir alles "TOS & WIN" , Byte Swapping ist aus da mit aktiven Byte Swapping der Atari nicht autoamtisch hoch fährt aber dafür der Mac die Laufwerke sieht  . Ich habe 7 Partitionen mit unter 500 MB erstellt.
Meine Frage, was mache ich da falsch oder habe ich einen Denkfehler ?

Danke

[Arthur]

Bis TOS 1.02 sollte die Bootpartition max 256MB groß sein. Ab TOS 1.04 bis 512MB groß und ab TOS 2.0x 1024MB. Welches TOS hat dein ST?

Ich möchte gerne weil die SD Karte 4GB groß ist mit mehreren Laufwerken arbeiten (aber wer braucht den Platz schon).

Meinst Du mit mehreren Laufwerken oder Partitionen?

[Atari99]

Mit der MonSTer TOS 2.06 und ja ich habe die Partitionen gemeint weil ich immer wieder Laufwerk oder Partition geschrieben habe. Wie schon geschrieben, das hoch fahren ohne "Swap" funktioniert bestens. Nur eben wenn ich "Swap" aktiviere dann nicht mehr. Natürlich hätte ich noch die Möglichkeit eine weiter SD anzuschließen aber ich habe gerade keinen zweiten Adapter auf SD momentan zur Hand. Die Adapter auf CF funktionieren scheinbar nicht oder nicht meine Karte. Den original TOS muss man ja ausbauen wenn man die MonSTer benutzen möchte. Die "Swap" Funktion wäre halt gut, dann könnte ich die Karte in meinen Mac stecken und die Files übertragen.

[Lukas Frank]

Frage mal im Forum von Uwe Seimet ...

Ich meine so eine TOS/Windows Partition mit HDDriver darf nur eine sein und bei TOS 2.06 sind das 512MB maximal. Ich habe einen Dual CF Adapter an meiner MonSTer und nutze die erste CF Karte aufgeteilt in mehrere Partitionen für den Atari und die zweite CF Karte mit 256MB TOS/Windows und ByteSwap und einer einzelnen Partition mit HDDriver eingerichtet zum Datenaustausch mit meinem Macintosh ...

[Lukas Frank]

Dieses ByteSwap ist wichtig damit der PC das Medium nutzen kann. Nachteil ist das man nur Datenraten wie bei einer Floppy erreicht.

[1ST1]

Das Byteswapping ist das Problem. Der ST kann von der Karte nur booten, wenn Byteswapping aus ist, der Mac bzw. PC kann die Karte nur lesen wenn Byteswapping an ist. Mit einer einzelnen CF-Karte ist das nicht zu lösen. Du brauchst eine zweite CF-Karte, die aber nicht größer sein darf als 512 MB (TOS 2.06 Limit), die muss dann am ST TOS+WIN-kompatibel mit Byteswapping eingerichtet werden. Außerdem empfehle ich noch, BIGDOS auf dem ST in den Autoordner zu legen.

[towabe]

Das sehe ich anders. Ich habe eine 4GB-CF-Karte schon mit mehreren Partitionen am Atari TT und Falcon betrieben (über SCSI-CF-cardreader). Die sind genauso eingerichtet wie  Atari99 es beschrieben hat. Die wurden und werden auf den MAC alle erkannt. Es müsste also eigentlich so funktionieren.

[1ST1]

SCSI ist eine andere Sache, da gibts im Gegensatz zu IDE kein Byteswap, da SCSI-1/2 nicht 16 Bit (little versus big endian !!!) sondern nur 8 Bit überträgt. Die Umsetzung von 8 auf 16 Bit macht dann der SCSI zu CF Adapter.

[Lukas Frank]

Zauberei ...

[1ST1]

Zauberrei

Das IDE/CF-Interface ist nunmal ganz eng an den 16-Bit-ISA-Bus des IBM AT angelehnt. Und das wiederum ist an die Wort-Darstellung der X86-Prozessoren angepasst, und da werden nunmal 16-Bit-Worte im Little Endian Format dargestellt. Little Endian bedeutet, das ein 16-Bit Wort aus einem führenden Low-Byte und einem folgenden High-Byte gebildet wird. Also genau umgekehrt wie es wir z.B. bei unserem Stellwertsystem im 10er-System gewohnt sind, die Zahl "Zehn" wäre bei Little Endian da nicht 10, sondern 01... Der Motorola 68000 verwendet dagegen Big-Endian, also genau umgekehrt (und für uns westlich orientierte Menschen einfacher lesbar) mit High-Byte zuerst und dann Low-Byte. Wenn nun ein 68000 auf eine Little-Endian-Hardware zugreifen will, muss er eben den Byteswap machen*. Ihr habt ja schon genug IDE:Interfaces gebastelt, dass ihr sehen konntet, dass da die im Prinzip die Adress- und Datenbussignale (mit ein bischen Adressdecoderlogik) im Primzip 1:1 miteinander verbunden werden (bzw. bei den Daten der Byteswap hardwareseitig gemacht wird).

Bei SCSI spiewlt das keine Rolle, denn da gibtgs keine direkte Verbindung zwischen dem Prozessorbus und dem CF/IDE-Interface, sondern da sitzen 2 SCSI-Controller dazwischen, ein Initiator am Rechner, ein Targetdevice im SCSI-zu-CF/IDE-Adapter. Das SCSI-Interface ist entweder 8 Bit (SCSI 1/2) breit, oder Big Endian 16 Bit (neuere SCSI-Versionen). Der 68000er schreibt Big Endian auf den SCSI-Controller, der SCSI-Controller schickt zwei Bytes oder ein Big-Endian Wort auf den SCSI-Bus und das SCSI-Target wandelt entweder 2 nacheinander empfangene Bytes oder (bei Wide SCSI) Big Endian auf Little Endian um und schickt das auf das IDE/CF-Interface.

Wo ist da die Zauberrei???

* Es ist aber noch etwas komplizierter...: So ein CF/IDE-Interface überträgt ja zweierlei:
1. Befehle
2. Daten
Die Befehle für das IDE/CF-Laufwerk müssen grundsätzlich immer als Litte Endian übertragen werden, denn sonst versteht sie der IDE/CF-Controller im Laufwerk bzw. der Karte nicht.
2. Dem IDE/CF-Laufwerk ist aber egal, ob es Daten im Big oder Little Endian Format in seinen Sektoren speichern soll.

Das bedeutet:
1. Ein PC, der grundsätzlich immer in Little Endian arbeitet, da muss nichts gemacht werden.
2. Ein 68000 System, welches Big Endian arbeitet, muss ein IDE/CF-Laufwerk mit Little-Endian Befehlen steuern, kann aber wahlweise Little/Big Endian Daten darauf speichern. So hat es ATARI beim Falcon und ST-Book gemacht, die Ataris speichern normalerweise Big Endian auf IDE-Laufwerken.Will man PC beschriebene Laufwerke damit lesen und schreiben, muss der Byteswap auch bei Daten durchgeführt werden, was die Sache langsam macht.  Dazu im Gegensatz das IDE-Interface nach P.Putnik, der die Big/Little-Endian-Konvertierung durch Vertausch der Datenleitungen auf dem IDE-Bus realisiert hat, da darf dann der Plattentreiber nicht noch zusätzlich einen Byteswap bei den Befehlen durchführen.

Immer noch keine Zauberrei, wenn man die Hintergründe kennt!

[tuxie]

Das IDE Interface hat zwei Modis wie du beschriebenb hast 1. Control 2. Daten.. wenn man jetzt im Controllmodus ist könnte man ja nach Big Endian Arbeiten und wenn man im Datenmodus ist im Little Endian. Damit sollte doch eigentlich der ST auch das Interface erkennen ohne das man ein TOS patch braucht, oder denke ich jetzt einfach falsch ?

[1ST1]

Genau so ist es, und genau so machen es die meisten IDE-Interfaces für den ST, Falcon und ST-Book sowieso. Nur erwartet TOS dann auch die Daten im Big Endian Format, weswegen dann schon Little Endian Partitionsdaten nicht gelesen werden können, sprich davon auch nicht gebootet werden kann. Das Putnik-Interface mit gedrehtem Datenbus ist die Ausnahme, das ist deswegen aber auch nicht bootfähig, weil dort die Befehle von TOS zum Booten verkehrt herum ankommen (Big statt Little Endian) würden. Vielleicht kann man das aber verbessern, in dem man in einer Schaltung heraus findet, ob sich das IDE-Interface sich gerade im Control oder Data-Modus befindet, und dann die beiden Bytes des Datenbusses miteinander tauscht, oder nicht? Dann wären vom PC Little Endian formatierte Laufwerke voll AHDI-kompatibel...

[Arthur]

Das Putnik-Interface mit gedrehtem Datenbus ist die Ausnahme, das ist deswegen aber auch nicht bootfähig, weil dort die Befehle von TOS zum Booten verkehrt herum ankommen (Big statt Little Endian) würden.

Es ist bootfaehig wenn sein Patch im jeweiligem TOS ist. Ich verstehe aber das Du das alles in Hardwae gießen möchtest und so eine unabhängigkeit vom Treiber bzw TOS zu erreichen. Die Idee hört sich gut an aber ob dafür ein bis zwei GALs ausreichen? Vielleicht läßt es sich mit einem Pic realisieren?

[1ST1]

Man bräuchte dafür einen Chip, der mindestens 32 Pins für Datenleitungen und zwei Steuereingänge (kreuzen/nicht kreuzen und Richtung (Lesen/schreiben) hat.

Ja, TOS patchen... Schade, dass ATARI das nicht von Anfang an so gemacht hat. Das wäre sicher das Beste gewesen. Die Frage ist z.B. auch, warum nicht schon die STacy und der Mega STE nicht serienmäßig ein IDE-Interface bekommen haben, statt der teureren SCSI-Platten und ACSI nur noch für externe Platten... IDE war schon bei Erscheinen der STacy (88/89) fest etabliert.

[tuxie]

Also, wenn man es dreht ist es nicht nur nicht bootfähig sondern die Platte wird gar nicht erkannt da für den HDDriver nur müll ankommt. Erst mit dem Tospatch kann man etwas sehen (selbst getestet).

Theoretisch würden 4mal 74LS245 gehen, jeweils zwei für umgedreht und zwei für gedreht.

[1ST1]

Ja mit den 245ern das wäre eine Möglichkeit, siehst ja aber was Frank L schon mit einem solchen Chip in den Leitungen für Timing-Probleme hat.

Und ja, ein IDE-Laufwerk mit gedrehten Datenleitung muss man mit einem spezielln Treiber aus dem Autoordner starten, oder den HDDRiver nehmen, der aber von einem AHDI-kompatiblen Laufwerk booten muss.

[tuxie]

Also ich hab mein IDE Interface im 1040STE stabil am laufen, hab da eine 4Gb CF Karte drin, hab 1,3MB Datentransfer, will den STE jetzt auf 16MHz umbauen mal schauen wie viel es dann macht, hoffe es bringt mir keine neuen Timingproblem.

[Lukas Frank]

Ich habe das mal aus Spaß mit einer 1GB IBM SCSI Festplatte mit drei Atari BGM Partitionen getestet. Windows 7 erkennt über den Adaptec 29160 SCSI Controller zwar die Festplatte aber keinerlei Partitionen.

Ohne die spezielle Linux Unterstütztung für das Atari Filesystem kann Ubuntu mit der SCSI Platte auch gar nichts anfangen. Gparted meldet ebenfalls das Laufwerk als unpartitioniert.

[tuxie]

Scsi Selbst glaube ich nicht das dies Funktioniert da jeder Controller anders die Platte ansteuert. Gab sogar schon Probleme wenn man verschiedene SCSI Controller verwendet hat.

[1ST1]

Ich habe das mal aus Spaß mit einer 1GB IBM SCSI Festplatte mit drei Atari BGM Partitionen getestet. Windows 7 erkennt über den Adaptec 29160 SCSI Controller zwar die Festplatte aber keinerlei Partitionen.

Ohne die spezielle Linux Unterstütztung für das Atari Filesystem kann Ubuntu mit der SCSI Platte auch gar nichts anfangen. Gparted meldet ebenfalls das Laufwerk als unpartitioniert.

Das ist richtig, AHDI (und Kompatible) verwenden auch nicht das PC-übliche Partitionsschema mit 1 primären und bis zu 3 sekundären Partitionen, und alle weiteren (erweiterten) Partitionen als Container in einer sekundären Partition. Sondern beim Atari sind alle Partitionen vom Aufbau gleich und es gibt auch keinen Unterschied zwischen primär/sekundär/erweitert. Beim ATARI muss man auch die Bootpartition nicht "aktiv" setzen und keinen MBR schreiben. Nur das Dateisystem innerhalb der Partitionen ist gleich. Deswegen kann eine DOSe diese Partitionen nicht lesen, obwohl es FAT ist. Hier hilft aber das TOS/DOS.kompatible Partitionsschema von HDDRIVER, welches die für den PC benötigten Informationen anlegt.