Ubuntu Linux und Atari TOS Partitionen ...

[ari.tao]

^^-- Nein, leider hast Du das BILD-Niveau trotz Anstrengung noch nicht überwunden. Du hast nämlich mit viel Mühe etwas widerlegt, was ich gar nicht behauptet habe. Aber wir wissen ja schon seit geraumer Weile, daß Du eine Neigung hast, hin und wieder nicht richtig zu lesen. Lies also bitte nochmal meinen Beitrag #72, Mitte oder am Besten gleich dessen Zitat bei mfro in #73:

Auch Du scheinst nicht verstanden zu haben, daß ich nicht bezweifelt habe, daß die Daten der FAT16-Verwaltung auf einem Medium, das am IDE-Port des Falcon läuft, meistens im Intel-Format vorliegen,

Ähm, nein. Das tun sie eben nicht, das ist ja das Problem.

Nicht ich also habe das behauptet, sondern mfro - aber ich denke, es ist ihm da bloß das Versehen unterlaufen, daß er ´SCSI´ gelesen hat, wo doch ´IDE´ steht... (wie sein darauffolgender Absatz vermuten läßt).
Und dann lies noch einmal #46 (und hilfsweise #43 und #72), dann merkst Du vielleicht endlich, worin Dein Fehler bestand, nämlich einen falschen logischen Schluß zu ziehen! Aus dem Tatbestand, daß DateiSysteme öfters mal Strukturen im Intel-Format enthalten, darf/kann man nicht schließen, daß das immer so sein muß! Deshalb mein Spottvers in #72:

   "Und daraus schloß er liebevoll, daß so sein muß, was so sein soll".

PS: Ich habe "nicht bezweifelt, daß die Daten der FAT16-Verwaltung ... meistens im Intel-Format vorliegen" - ich habe es aber auch nicht behauptet. Beides war für meine Argumentation unnötig.

[1ST1]

´Scheibenkleister´ hineingeschaut:
...
Buch genauso wenig vor wie eine Beschreibung der FAT16 für Festplatten.

Scheibenkleister II, Seite ab 727 Kaptiel A1-4.

Nein, da steht oben drüber "Anhang I: Strukturen auf der Diskette" und es geht um FAT12.

Noch einmal ganz deutlich: Es gibt keinen logischen Grund, der erzwingt, daß eine Datei-Verwaltung im Intel-Format stehen muß. Das kann man dem oben zitierten Wikipedia-Artikel entnehmen. Daß in praxis Intels Marktmacht da durchschlägt, ist eine ganz andere Hausnummer.

[1ST1]

3) Dateisysteme (zB. FAT16) sind völlig unabhängig von der Endianess eines Mediums. Ibs. ist es falsch zu glauben, daß die Verwaltungs-Strukturen eines Dateisystems immer im Intel-Format vorliegen müssen (tun sie für TOS auch nicht) und ebensowenig ist es ihnen verboten (-> am Yamaha-Adpt.). Folgerichtig geht der Wiki-Artikel über die Byte-Reihenfolge auf Dateisysteme nicht ein (und muß es auch nicht). Es ist schlicht falsch, daß "FAT auf logischer Verwaltungsebene immer Little" ist (obwohl das für Disketten mit FAT12 in praxis so ist).

Und weitere Passagen, in denen steif und fest behauptet wird, dass FAT16 auf dem ATARI im BIG-Endian Format abgelegt werden.

BUSTED

[ari.tao]

3) Dateisysteme (zB. FAT16) sind völlig unabhängig von der Endianess eines Mediums. Ibs. ist es falsch zu glauben, daß die Verwaltungs-Strukturen eines Dateisystems immer im Intel-Format vorliegen müssen (tun sie für TOS auch nicht) und ebensowenig ist es ihnen verboten (-> am Yamaha-Adpt.). Folgerichtig geht der Wiki-Artikel über die Byte-Reihenfolge auf Dateisysteme nicht ein (und muß es auch nicht). Es ist schlicht falsch, daß "FAT auf logischer Verwaltungsebene immer Little" ist (obwohl das für Disketten mit FAT12 in praxis so ist).

Und weitere Passagen, in denen steif und fest behauptet wird, dass FAT16 auf dem ATARI im BIG-Endian Format abgelegt werden.
BUSTED

Was ich geschrieben habe - und was nicht -, das kann ja glücklicherweise jeder selbst im Thread nachlesen.

Das in #56 vorgestellte Päärchen von CFs liegt übrigens immer noch auf meinem Schreibtisch: Ein Experiment, für jeden nachprüfbar, wiederholbar und demonstrierbar, der dazu willens ist. Benötigt wird lediglich ein Falcon, ein Yamaha-Adpt. (oder GigaFile oä.) und eben zwei phys. gleiche Medien. Resultat: eine CF mit Nutzdaten in BigEndian und Verwaltungdaten großenteils in LittleEndian, die andere CF aber vice versa.
Endianess bezieht sich darauf, wie die Daten im Speicher liegen (egal, ob das RAM, Magnetscheibe oder ein Register ist) - und nicht auf das Ü-Protokoll (Das war ja ein weiterer hier verbreiteter Fehler).

[1ST1]

1. GigaFile arbeitet mit SD, nicht CF. GigaFile hat ein 8 Bit breites SCSI-Interface.
2. CFs haben ein IDE-interface. IDE ist 16 Bit breit, nämlich ursprünglich im Prinzip eine Verlängerung des ISA-Busses und der ist nunmal, da nahe an Intel 80286 und neuer Prozessoren angelehnt, Little Endian.
- Der PC schreib alles in Little Endian auf den IDE-Bus: Daten, Verwaltungsstrukturen, Kommandos an die Platte
- Der Atari (Falcon, ST-Book) schreibt Kommandos an die Platte in Little-Endian (sonst versteht sie es nicht) und Daten in Big-Endian. Darin befindet sich aber wiederum ein Partitionsschema, welches teilweise Little Endian nutzt und ein Dateisystem, was seine Verwaltungsstrukturen VOLLSTÄNDIG in Little Endian schreibt, siehe oben. Die 68K Prozessoren arbeiten aber eigentlich mit BigEndian.
- Der Atari kann vom PC geschriebene Daten (im Little Endian Format) lesen, in dem er alles Byteswapt (und hinterher in den Partitionsdaten und Dateisystemverwaltungsdaten nochmals Little Endian nutzt).
4. SCSI am Atari ist 8-Bit, egal ob du jetzt den Hostadapter in der SH204 oder Megafile 44, mega STE oder einen von ICD, Inventronik usw. nimmst, alle 8 Bit. Da werden alle Daten 8 Bittig drüber geschoben und wandern so ganz von alleine in der richtigen Reihenfolge auf die Platte. Und auch der PC mit SCSI Controller ließt diese 8-Bit-Platte wieder in der richtigen Reihenfolge aus! Ganz von alleine! Weil das Interface zur Platte nur 8 Bit breit ist.

Ist das denn so schwer zu verstehen? Hast du dir mal den IDE-Adapter von P.Putnik mit Hardware-Byteswap angesehen?

[ari.tao]

Indem Du alte Fehler & Irrtümer wiederholst, die längst abgeklärt bzw. widerlegt sind, werden sie auch nicht richtig. Ich habe nun endgültig keine Lust mehr, auf Deinen obigen Mist zu antworten und werde mich aus diesem Thread ausklinken. 

Auch noch OT:
Bei mir, 1ST1, verfestigt sich inzwischen der Eindruck, daß Du hier im Forum hauptsächlich unterwegs bist, um größtmögliche Verwirrung zu stiften und auf diese Weise Sabotage zu betreiben. Erfolgreiche Projekte, in die andere viel Energie gesteckt haben (wie zB. die FireBee) werden von Dir niedergemacht, dafür andere, die ATARI-fern sind (aber Commodore- oder Dosen-nah) oder unausgegoren, die propagierst Du. Eigene Projekte, weder Hardware noch Software, habe ich von Dir noch nicht gesehen. Wirst Du eigtl. gut bezahlt von M$ für Deine Obstruktion? Oder von wem sonst?

PS: "Was vermag aber die beste Absicht im Dienste einer guten Sache gegen die Unordnung der Geistesverwirrung!" (Leautreamont, ´Die Gesänge des Maldoror´)

[1ST1]

Quatsch.

[Burkhard Mankel]

...

Quatsch.

Sehr Aussagekräftig, unsere Heiligkeit!

[1ST1]

Quatsch 

[Burkhard Mankel]

Nochaufschlußreicher