Slave-IDE an Thunder wird nicht gefunden

[CDAR-504]

Endlich komm ich mal dazu an meinen TT  die Thunder mit IDE-Devices anzuschließen.
Ein CF-Adapter mit CF-Karte als Master und eine HDD als Slave sind nun dran.
Mit aktuellem HDDRIVER finde ich jedoch immer nur den Master. Bei einem Wechsel wird als Gerät mal die HDD mal die CF-Karte angezeigt.  Aber beide gemeinsam sind nicht zu finden, obwohl ein BUS-Scan beide Geräte zeigt.  Warum ist das so? Was mache ich falsch?

[Lukas Frank]

Schaue dir mal das HDDRIVER.SYS oder PRG mit dem Util an unter "Geräte und Partitionen" ob beim IDE Bus auch die ID1 neben der ID0 aktiviert ist.

[czietz]

Alternativ wählt ein Klick auf "Autokonfigurierung" im Menü die tatsächlich vorhandenen Geräte im Dialog  "Geräte und Partitionen" aus. Details siehe Handbuch.

[CDAR-504]

Also auch mit der Autokonfigurierung wird das Slave-Gerät kurz angezeigt. Ähnlich wie beim Bus-Scan.
Im Fenster "Verfügbare Geräte" taucht jedoch weiterhin nur das Mastergerät auf.
Auch eine Aktualisierung des Fensters bringt das Slave-Gerät auf den Schirm.

Womit kann ich die HDDRIVER.SYS-Datei untersuchen?

[czietz]

Hast Du denn wie von @Lukas Frank geschrieben das Slave-Gerät im Menü Einstellungen -> Geräte und Partitionen aktiviert? Eigentlich ist es ja alles im Handbuch beschrieben.

HDDRUTIL starten, Datei -> HDDRIVER lokalisieren, C:\HDDRIVER.SYS auswählen (vorausgesetzt Du bootest von C:). Datei -> Einstellungen, dort sicherstellen, dass das Kreuz bei "Einstellungen beim Beenden sichern" gesetzt ist. Dir im Fenster "Verfügbare Busse" die Nummer des IDE-Bus merken, z.B. "Bus 2". Den Dialog Einstellungen -> Geräte und Partitionen öffnen, dort das Slave-Device 2.1 (Annahme: Bus 2) aktivieren. HDDRUTIL beenden. Neu booten.

[CDAR-504]

Ah.- Vielen Dank. Erst nach dem Sichern und Neu-Booten taucht das Slave-Gerät endlich auf.
Merkwürdig nur, daß es nicht vorher durch aktualisieren der Anzeige erscheint.
Jetzt muß ich partitionieren. Unter TOS sind max. 500MB-Partitionen möglich.  Mit BIGDOS dann max. 2GB wenn man die Partition mit $0b typisiert?

[ari.tao]

Um den Verschnitt klein zu halten, emphehle ich 7 x 255,9MB FAT16er (BGM) & der große Rest auf eine FAT32er sowie die Inst. von MiNT. (BigDOS kann kein FAT32.)

[Lukas Frank]

Erst nach dem Sichern und Neu-Booten taucht das Slave-Gerät endlich auf.

Erst das aktuelle hddriver.sys von C:\ über lokalisieren selektieren damit die Änderungen auch dort gemacht werden ...

[CDAR-504]

Um den Verschnitt klein zu halten, emphehle ich 7 x 255,9MB FAT16er (BGM) & der große Rest auf eine FAT32er sowie die Inst. von MiNT. (BigDOS kann kein FAT32.)

Da es im TT steckt, sollten auch 7 Partitionen bis max. 500 MB (BGM) möglich sein. Der Rest wie Du schon beschrieben hast auf eine große bis max. 2GB.

Tatsächlich hab ich mir für eine 4GB CF-Karte (als Slave) folgendes gedacht: 4 x 500GB und 1 x 2GB

Für die HDD (als Master) hab ich noch eine 32GB SSD mit IDE-Schnittstelle übrig.
Die bekäme dann auch 4 x 500MB (BGM). Ich überlege aber noch, was ich mit dem Rest mache.
Eventuell 2 x 2GB für BIGDOS und weiter ...?
Wie sollte man das in der HDDRIVER-Util am besten vorbereiten?

Auf interne SCSI-Platten will ich dann ganz verzichten und die andere Seite des SCSI-Strangs dann mit einer zusätzlichen Buchse nach außen führen. Hab da noch diverse andere Geräte wie DAT-Streamer, Syquest und CD/DVD-Laufwerke dafür. 
Am ASCI-Port habe ich derzeit ein CDAR-504 und abschließend eine Ultrasatan.
Möglich wäre auch noch ein Drucker am ASCI-Port, aber der scheint defekt zu sein.
Der TT wird ganz ordentlich mit Peripherie versehen.
Neben Storm, Thunder und Lightning sitzt im internen VME-Port bald eine Crazy-Dots ET4000-Karte und am ROM-Port eine NETUSBEE. Als letztes wird ein Grafiktabett angeschlossen. Ob das alles zusammen funktionieren wird? Jednfalls noch eine Menge Arbeit und ich hab soooo wenig Zeit.

[Lukas Frank]

Den Rest einfach ungenutzt und frei lassen. So mache ich das bei großen Platten. Die ext2 Partitionen für MiNT mache ich nicht größer als 2GB da eine Überprüfung ansonsten viel zu lange braucht. FAT32 ist am Atari viel zu langsam ...

[1ST1]

Ich mache auf dem TT eine C: mit rund 500 MB, und dann X Partitionen mit 1 GB, z.B. bis zum Laufwerk L:, so dass MNOP noch für ZIP, Syquest, CosmosEx usw. zur Verfügung steht (cd/dvd-lw auf Z:, Midicom auf Y:), und dann den Rest mit Ext2 für MiNT. Die 1 GB BGM Partitionen gehen natürlich nur, wenn man BIGDOS in den Auto-Ordner packt. 2 GB für MiNT halte ich nicht für ausreichend groß. Filechecks vermeidet man durch sauberes Runterfahren von Mint und gelegentliches Benutzen. Da es für den Atari kein PartitionMagic gibt, mit dem man umpartitionieren könnte, halte ich eine korrekte Partitonsplanung von Anfang an für wichtig, und kleine Partitionen sind einfach nur bäh.

[ari.tao]

... sitzt im internen VME-Port bald eine Crazy-Dots ET4000-Karte ...

Dann warst Du also derjenige, der kürzlich 388 Eumel für nur eine antike GK bezahlte? Weiß wirklich nicht, ob ich Dir dazu gratulieren oder kondolieren soll...   

-------

BGM braucht man, wenn die Partitionen Boot-fähig sein sollen.
Aber mit einer Größe von 500MB für solche kann es mit einer Atari-typischen Files-Mischung schnell mal 50% Verschnitt geben... Darum diese klein halten und den Bulk anderweitig verteilen.

Edit.: Eine kleine Statistik angehängt.

[CDAR-504]

... sitzt im internen VME-Port bald eine Crazy-Dots ET4000-Karte ...

Dann warst Du also derjenige, der kürzlich 388 Eumel für nur eine antike GK bezahlte? Weiß wirklich nicht, ob ich Dir dazu gratulieren oder kondolieren soll...   

Nein, das war ich nicht.
Meine Karte liegt schon etwas länger in der Schublade und wartet auf Einsatz,

BGM braucht man, wenn die Partitionen Boot-fähig sein sollen.
Aber mit einer Größe von 500MB für solche kann es mit einer Atari-typischen Files-Mischung schnell mal 50% Verschnitt geben... Darum diese klein halten und den Bulk anderweitig verteilen.

500MB ist schon richtig um kompatibel booten zu können.
Das reicht eigentlich auch für die meisten Anwendungen komplett aus.
Ansonsten haben die heutigen Datenträger mehr als genug Kapazität um einiges zu archivieren.

[ari.tao]

BackUps macht man mit SektorCopy (weil bei gut gefüllten Partitionen FileCopy viel zu langsam ist). Das dauert dann bei hohem Verschnitt entsprechend länger.
Abgesehen davon, daß bei FAT auch der Verschnitt als ´belegt´ markiert ist und dem WearLevelling nicht als Ersatz zur Verfügung stünde: Hier geht es um CFs (-> EingangsPosting, 1. Satz) und für diese ist bis dato die Behauptung von WearLevelling schlicht unbewiesen und höchstwahrscheinlich falsch (zumindest für die inzwischen auch schon antiken CFs bis ca. 8GB, die für Ataris in Frage kommen). Das wurde ja hier im Forum früher schon ausgiebig diskutiert (aber im Alter läßt das Gedächtnis nach, nicht bloß bei CFs).

[1ST1]

Nach Backup hat niemand gefragt. Sektorbasiertes Backup macht beim Atari nur Sinn, wenn man den Restore auf eine exakt gleich große Platte zurückspielen kann. Ein 32 Gb Laufwerk muss nicht exakt gleich viele Sektoren haben wie ein anderes 32 Gb Laufwerk, und schon fehlt mit ein bischen Pech am Ende was. Solange es keinen Restore mit dynamischer Anpassung der Partitionsgröße an das Zielmedium gibt, würde ich immer Dateiweise backuppen. Das hat auch den Vorteil, dass man an einzelne Dateien dran kommt, ohne gleich ein ganzes Image rückschreiben zu müssen.

Was Wearlevelling betrifft, du stellst das in Frage. Das ist dein Recht. Beweisen kannst du aber nichts. Entsprechende Techniken sind bei Flash-Medien schon ziemlich alt, und nicht jeder Hersteller hat einst seine geheimen, lebensverlängerten (Qualitäts-steigernden!) Techniken publik gemacht, damit die Konkurrenz nicht auch auf die famose Idee kommt. Hier ist ein Patent zu Wearlevelling für EEPROMs aus dem Jahre 1991: https://patents.google.com/patent/US6850443 Manch einer der Forenkollegen hier hatte zu dem Zeitpunkt noch nicht mal einen Atari ST.

[CDAR-504]

Hier geht es um CFs (-> EingangsPosting, 1. Satz) und für diese ist bis dato die Behauptung von WearLevelling schlicht unbewiesen und höchstwahrscheinlich falsch (zumindest für die inzwischen auch schon antiken CFs bis ca. 8GB, die für Ataris in Frage kommen). Das wurde ja hier im Forum früher schon ausgiebig diskutiert (aber im Alter läßt das Gedächtnis nach, nicht bloß bei CFs).

Nein. Es geht hier nicht um CFs. Es ging mir darum, daß eine Slave-Komponente am IDE-Bus nicht erkannt wird. Das war eine HDD. Nur zufälligerweise war dabei die Master-Komponente eine CF-Karte.
Trotzdem Danke für den Tipp zur Datensicherung mit SektorCopy

[ari.tao]

^^-- Gerne doch.
-------

Sektorbasiertes Backup macht beim Atari nur Sinn, wenn man den Restore auf eine exakt gleich große Platte zurückspielen kann.

Auch da liegst Du mal wieder daneben. Dir fehlt einfach die diesbezgl. Praxis. Nötig ist allein eine geschickte Partitionierung. Ich kopiere schon seit langem meine 4GB-CFs immer per SektorCopy, auch zw. verschiedenen Marken (also leicht unterschiedlicher Größe) und habe bisher keine Probleme damit.

...  würde ich immer Dateiweise backuppen.

Nur zu. Dauert dann für 4GB ca. ein Wochenende. 32GB sind für Ataris sowieso zu groß.

Was WearLevelling angeht: _DU_ hast behauptet, das gebe es bei real existierenden  CFs - und bleibst den Beweis schuldig... Aber so ist das ja immer bei Dir.

[CDAR-504]

Wenn ich das richtig im HDDRIVER-Handbuch gelesen habe, dann wäre die Sicherung einer Partition einfach durch "Drag and Drop" auf ein anderes Gerät möglich. Das erscheint mir am besten geeignet.

[ari.tao]

Damit habe ich bisher keine Erfahrung. Wird da nicht die Partition ´als Image´ abgelegt? Also müßte auf dem anderen Plättle eine Partition mit genügend Platz schon vorhanden sein?
Bei SektorCopy kommt alles (einschl. Part.-Struktur) in 1:1.

[Johannes]

Off topic gelöscht ...