CF-zu-SD-Adapter im Falcon?

[Arthur]

Kobold kann nur die 8.3 Dateinamen lesen, aber zusammen mit BigDOS macht es zumindestens eine Korrektur bei komischen Dateinamen (Umlaute, Leerzeichen) beim Lesen des vom PC beschriebenen Datenträgers beim Kopieren auf die ATARAI-Partition. Wenn man nur über die Desktopfunktionen kopiert, bekommt man mit ein bischen Pech Dateien und Ordner die man nicht mehr löschen kann.

Kobold 3.5 unterstützt lange Dateinamen.

[1ST1]

Ah, cool, ich hatte Kobold 3.5 bisher nur unter Single-TOS laufen, wird Zeit dass ich mal EasyMiNT installiere...

[ari.tao]

Ich präzisiere:
Kobold 3.51 regrediert bei F32 in den "GEMDOS-Modus". Wohl _unabhängig_ von vollFett. Da kann man dann genauso gut die normalen Desktop-Funktionen nutzen (ie. genauso lahm); ggü. SektorCopy ca. ein Faktor vier mindestens!

-----

Ist vielleicht dieses Teil hier geeignet, um Atari-CFs & -SDs unter W8 zu clonen?:

http://www.osforensics.com/tools/write-usb-images.html

[ari.tao]

Bevor dieser Thread in´s Nirvana entschwindet, möchte ich noch eine Beobachtung anfügen:
Ich war jüngst total geschockt, als ich feststellen mußte, daß eine CF-Card (CnMemory, 4GB), die ich erst vor weniger als zwei Jahren komplett neu beschrieben hatte und die seither unbenutzt war, soviel von ihrem Inhalt verloren hatte, daß sie total unbrauchbar war! Jetzt mache ich mir Sorgen um mein Archiv im Banktresor...
Weiß jmd. genaueres über die Haltbarkeit des Inhalts von CF, SD & Sticks?
Sind die als ´Industrie-Ware´ angebotenen Teile sicherer?
Muß ich doch besser auf CD oa. sichern?

[czietz]

Dass Flash-Speicher stromlos gelagert Ladung und damit irgendwann Daten verliert, ist lange bekannt.

Vor einiger Zeit ging die Meldung in den Medien herum, dass flash-basierte Medien (wie SSDs) schon nach Wochen Daten verlieren. Das war allerdings eine etwas übertriebene Interpretation; Heise fasst es besser zusammen: http://www.heise.de/newsticker/meldung/SSD-Lagerung-und-Temperaturen-2639898.html. Doch auch dieser Artikel schließt mit: "Dennoch, als Archiv-Medien sind SSDs definitiv unbrauchbar, möglichst also gar nicht stromlos lagern"

[1ST1]

Bei SSDs für PCs sollte man auf jeden Fall vermeiden, diese länger als ein halbes Jahr nicht zu benutzen. Von Compactflashkarten weiß ich von einem Fotografen dass der erst nach über 12 Jahren nicht mehr lesbare Daten hatte. Allerdings dürfte das dem Alter nach recht kleine CFs gewesen sein. WIe es mit CFs der Gigabyte-Klasse aussieht, weiß ich nicht. Also besser, die Dinger ab und zu mal mit Strom tanken. Für Jahrelanges Lagern, egal ob daheim ober im Bankschließfach, ist das jedenfalls nichts.

Aber auch Festplatten sind nichts für die Ewigkeit, aber bei regelmäßig alle paar Jahre umkopieren auf ein neues Laufwerk wahrscheinlich noch der beste Kompromiss. CD/DVDs halten auch nicht ewig, ich hatte schon ein paar Originale und auch selbstgebrannte, wo sich die Reflektionsschicht vom Plastik gelöst hat. (Lagerung bei Zimmertemperatur in der CD/DVD-Schublade)

[ari.tao]

Jetzt bin ich noch viel mehr geschockt  ! Nach Lektüre des Heise-Artikels muß ich wohl darauf gefaßt sein, daß im Bankschließfach nur noch DatenMüll liegt. Gut,daß ich die alten HDs noch nicht entsorgt habe; allerdings dürften auch bei so mancher von denen mittlerweile die Leseköpfe festkleben... 
Unerwartet auch, daß die ´Enterprise´-Ware noch schlechtere Sicherheit bietet als die ´Consumer´-Ware  !
Muß man min. einen Lese-Zyklus alle paar Wochen durchführen? Auf dem gesamten Plättle? Oder reicht es, CFs & Co. regelmäßig unter Strom zu setzen? Dann sähe ich da einen lukrativen Markt für Batterie-betriebene Refresher, sagen wir mal für je zwei Dutzend CF-Cards &c. im Kühlschrank... Wir sollten eine Fa. gründen  !
Ist die Cloud ein Ausweg? imho nicht.
Daß CDs etc. nicht ewig halten, war mir auch klar - nicht aber, daß es mit denen auch _so_ schnell vorbei ist. Alte Schellack-Platten haben schon mehr als ein halbes Jhdt. überstanden.

PS.: Kennt ihr einen billigen Steinmetz, der mir meine Daten in Granit hauen kann? Darf aber nicht mehr kosten als, na sagen wir mal, 20 Eumel pro GB  !

[Nervengift]

PS.: Kennt ihr einen billigen Steinmetz, der mir meine Daten in Granit hauen kann? Darf aber nicht mehr kosten als, na sagen wir mal, 20 Eumel pro GB  !

  Demnach wäre für uns wohl die Keramiktafel die erste Wahl?

https://de.wikipedia.org/wiki/Langzeitarchivierung

Ich habe seit sechs Jahren eine CF-Karte (hama, 4 GB) in meinen Falcon030, den ich inzwischen nur noch zwei bis drei Mal im Jahr einschalte. Bislang ist auf dem Falcon noch nichts "verreckt". Wenn die Daten futsch wären, wäre das auch nicht so schlimm. Sicherungen habe ich auf dem G5 und davon gibt es noch ein regelmäßiges Backup auf USB-Festplatte. Aber man sollte wohl schon mehr oder minder abwägen welches Medium man für einen Rechner verwendet, wenn man diesen nur sehr, sehr selten nutzt. Alles hat seine Vor- und Nachteile. Die eierlegende Wollmilchsau gibt's in dem Bereich wohl auch noch nicht.

[czietz]

Unerwartet auch, daß die ´Enterprise´-Ware noch schlechtere Sicherheit bietet als die ´Consumer´-Ware  !

Achtung: Der Grund dafür ist, dass für die Enterprise-SSD eine höhere Lagertemperatur (= schlecht für die Daten) angenommen wird.

Muß man min. einen Lese-Zyklus alle paar Wochen durchführen? Auf dem gesamten Plättle? Oder reicht es, CFs & Co. regelmäßig unter Strom zu setzen?

Das musst Du den Hersteller des jeweiligen Controllers in der Karte fragen...

Daß CDs etc. nicht ewig halten, war mir auch klar - nicht aber, daß es mit denen auch _so_ schnell vorbei ist.

Es gibt durchaus Medien für Archivzwecke, die mit langer Lebensdauer beworben werden, z.B. https://de.wikipedia.org/wiki/M-Disc. Aber wieviel davon Fakt ist und wieviel Marketing?

Letztlich kann ich 1ST1 nur zustimmen: Regelmäßig umkopieren, mehrere Kopien machen ist wohl das sicherste für Archivierung.

[RealLarry]

...nur mal so in den Raum geworfen, quasi zu Archiv-Zwecken für denjenigen, der sich neu mit dem Thema auseinandersetzt:

Beim hddriver für IDE musste ich bei mir Byte-Swapping für das Boot-Medium ausschalten. Ich konnte mit eingeschaltetem Byte-Swapping zwar von Floppy booten und mit den Medien arbeiten, aber von der CF booten wollte der Falcon so nicht.
(getestet mit einem delock #91655 und einem delock #91662 - beide CompactFlash<->IDE)

[1ST1]

Natürlich habe ich die CF vorher dementsprechend getestet. Den Bug in HDRUTIL muss ich nochmal versuchen nachzustellen. Inzwischen ist die CF befüült und voll funktionsfähig.

[mfro]

...nur mal so in den Raum geworfen, quasi zu Archiv-Zwecken für denjenigen, der sich neu mit dem Thema auseinandersetzt:

Beim hddriver für IDE musste ich bei mir Byte-Swapping für das Boot-Medium ausschalten. Ich konnte mit eingeschaltetem Byte-Swapping zwar von Floppy booten und mit den Medien arbeiten, aber von der CF booten wollte der Falcon so nicht.
(getestet mit einem delock #91655 und einem delock #91662 - beide CompactFlash<->IDE)

Das ist klar und ist auch so in den HDDRIVER FAQs beschrieben: http://hddriver.seimet.de/de/faq.html
(unter "Kann TOS HDDRIVER von einer TOS/Windows-kompatiblen Partition booten? ").

Liegt einfach daran, daß der IDE-Bus mit 16-bit Datenworten arbeitet und auf Ataris BigEndian verdrahtet ist. Mit SCSI und ACSI-Medien geht's (dort werden immer Bytes transportiert).

[RealLarry]

Das ist klar und ist auch so in den HDDRIVER FAQs beschrieben: http://hddriver.seimet.de/de/faq.html
(unter "Kann TOS HDDRIVER von einer TOS/Windows-kompatiblen Partition booten? ").

Jaja, schonschon, aber meine (erste) CF ist rein TOS only - für anderes Zeuch ist die zweite CF

[1ST1]

Beim IDE/CF-Bootlaufwerk (nicht Partition!) am IDE-Anschluss des ATARI muss Byteswap immer ausgeschaltet sein. Beim zweiten laufwerk kann es ein oder ausgeschaltet sein. Wenn man mit dem zweiten Laufwerk Daten mit dem PC austauschen will, muss dort Byteswao eingeschaltet sein. Wenn man dieses Zweitlaufwerk am PC partitioniert, ist automatisch Byteswap an.

Bei SCSI/ACSI spielt das keine Rolle, selbst wenn am Ende über Adapter ein IDE/CF/SD-Laufwwerk angesprochen wird, weil SCSI und ACSI beim ATARI immer nur 8 Bit breit sind. IDE ist 16 Bit und hier spielt die Prozessorarchitektur, sprich Intel oder Motorola eine Rolle, Schließlich ist IDE eigentlich nichts anderes als ein verlängerter 16-Bit ISA-Bus aus dem PC/AT, und da ist halt eine Intel-CPU drin. Deswegen der Byteswap von Little- nach Big-Endian, Reihenfolge High/Low- oder Low/High-Byte.

Byteswap bedeutet übrigens auch, dass der Zugriff auf dieses Laufwerk am ATARI langsammer ist, da jedes gelesene/geschriebene 16-Bit-Wort erst mal rumgedreht werden muss.

[ari.tao]

-^^- hier ist das völlig korrekt beschrieben -aber im og. FAQ etwas mißverständlich.
Richtet man je ein Medium am IDE-Port des Falcon ohne ByteSwap (also im BigEndian-Format) und am Yamaha-IDE-Adapter ebenfalls ohne ByteSwap (also im LittleEndian-Format) via SCSI-Port am Falcon TOS+DOS-kompatibel ein, so sind beide in ihrem Slot bootfähig. Tauscht man sie gegeneinander aus, so sind beide lesbar & beschreibbar - wenn auch deutlich langsamer - aber eben nicht mehr bootfähig. Eleganterweise ist ein durch SectorCopy (ohne ByteSwap!) zw. beiden Ports hergestellter Clon auch sofort bootbar, wenn es das Original auch war.