Autor Thema: MAGX´ Macken  (Gelesen 6577 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

Offline mfro

  • Benutzer
  • Beiträge: 946
Re: MAGX´ Macken
« Antwort #120 am: Di 14.03.2017, 05:56:03 »
Könntest Du bitte mal die Quellen-Angabe für die relevante MS-Spezi. etwas genauer machen? Ich habe jetzt eine halbe Stunde lang vergeblich in dem großen Heuhaufen gestochert...

Microsoft FAT32 Spec

Offline ari.tao

  • Benutzer
  • Beiträge: 849
  • a tha yo ga a nu sha sa nam
Re: MAGX´ Macken
« Antwort #121 am: Di 14.03.2017, 21:52:18 »
^^-- Danke.
Und was sagst Du zu den ´hidden sectors´?
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline ari.tao

  • Benutzer
  • Beiträge: 849
  • a tha yo ga a nu sha sa nam
Re: MAGX´ Macken
« Antwort #122 am: Mi 15.03.2017, 12:50:13 »
Microsoft FAT32 Spec
Interessante Lektüre; das meiste ist gut verständlich, ein paar wenige Stellen sind mir noch dunkel. Gibt´s auch etwas ähnliches zu Partitionierungs-Schemata & RootSektor?

Zu den ´hidden sectors´ habe ich leider nur diesen Absatz gefunden:
BPB_HiddSec 28 4
Count of hidden sectors preceding the partition that contains this FAT volume.
This field is generally only relevant for media visible on interrupt 0x13. 
This field must always be zero on media that are not partitioned. 
NOTE: Attempting to utilize this field to align the start of data area is incorrect.
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline mfro

  • Benutzer
  • Beiträge: 946
Re: MAGX´ Macken
« Antwort #123 am: Mi 15.03.2017, 13:10:54 »
Ich könnte mir höchstens vorstellen, daß mit den hidden sectors das Wurzelverzeichnis (das bei FAT32 ja im Datenbereich liegt) versteckt werden sollte (warum auch immer).

Wenn Du dir das Datum der MS-Spezifikation anschaust, kannst Du MagiC wohl auch nicht mehr ernsthaft böse sein. Höchstwahrscheinlich gab's damals noch keine frei verfügbare FAT32 Spezifikation und manches war "nur geraten".

. Warum wird die Plattengeometrie verändert? (255 heads)

Ich denke, das ist höchstens für PC's mit alten BIOSen relevant. Die verwenden u.U. noch die C/H/S Adressierung und die ist in der "Bitbreite" für Cylinder- und Sektoranzahl beschränkt. Für große Platten bleibt da nur, die Anzahl der Heads "virtuell" auf 255 zu erhöhen, um überhaupt halbwegs in die Mitte der Disk zu kommen (daher rührt auch das Limit von 504 MB bei ganz alten bzw. 128 GB bei alten DOSen).

Gibt´s auch etwas ähnliches zu Partitionierungs-Schemata & RootSektor?
Du verwendest doch Atari-Partitionierung, oder? Das steht im Profibuch.
« Letzte Änderung: Mi 15.03.2017, 13:12:27 von mfro »

Offline ari.tao

  • Benutzer
  • Beiträge: 849
  • a tha yo ga a nu sha sa nam
Re: MAGX´ Macken
« Antwort #124 am: Mi 15.03.2017, 14:15:15 »
^^-- ja, und auch im ´Scheibenkleister´ - ist alles schon sooo lange her... Mich interessierte aktuell eher der Unterschied zum DOSen-Reich.

Daß die Platten-Geometrie zB. für CFs völlig irrelevant ist, das ist trivialerweise klar. Die Frage war eher, warum mkfatfs sie nicht unverändert läßt! (und ebenso die Anzahl der ´hidden sectors´.)

Ich könnte mir höchstens vorstellen, daß mit den hidden sectors das Wurzelverzeichnis (das bei FAT32 ja im Datenbereich liegt) versteckt werden sollte (warum auch immer).
Das erklärt aber nicht die große Zahl, zB. auf der FAT16er ´I:´! (die ganz normal ´gut gefüllt´ ist.)

Wenn Du dir das Datum der MS-Spezifikation anschaust, kannst Du MagiC wohl auch nicht mehr ernsthaft böse sein. Höchstwahrscheinlich gab's damals noch keine frei verfügbare FAT32 Spezifikation und manches war "nur geraten".
Es hilft ja nix, "MAGX böse zu sein". Ich will nur genau wissen, wo der Bug steckt und worin er besteht. Danach kann man entscheiden, ob es ein Fixing gibt und ob sich das lohnt, oder ob ein Workaround ausreicht bzw. welcher zu nehmen ist - wenn es einen gibt. Letztendlich läuft´s auf einen Unterschied zw. Atari und DOSe hinaus, der zu beachten wäre. Ist ja nicht der erste.
« Letzte Änderung: Mi 15.03.2017, 14:21:06 von ari.tao »
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline ari.tao

  • Benutzer
  • Beiträge: 849
  • a tha yo ga a nu sha sa nam
Re: MAGX´ Macken
« Antwort #125 am: So 19.03.2017, 01:16:00 »
Vor kurzem habe ich mir große Teile dieses Threads nochmals angeschaut und den Eindruck gewonnen, daß #63 möglicherweise unserem Biest schon nahe auf der Spur war: Da es möglich ist, einen Zählfehler zu provozieren, der zu wenig freien Platz anzeigt, könnte es da nicht auch das andre geben, daß also zu viel davon angezeigt wird? Dann wäre es ja gar kein Wunder, wenn in die Pampa geschrieben wird... Ich habe aber bisher keinen Beleg für diese Hypothese. Darum werde ich mir ibs. den Info-Sektor, der für die Zählerei zuständig ist, mal in den og. FAT-Specs. ansehen.
Leider habe ich aber die nächsten Wochen weder Zeit noch Gelegeheit dazu, also muß ich hier erst einmal pausieren...
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline ari.tao

  • Benutzer
  • Beiträge: 849
  • a tha yo ga a nu sha sa nam
Re: MAGX´ Macken
« Antwort #126 am: Mo 08.05.2017, 13:59:18 »
So, wieder da.
Was zwischendurch geschah:

-)
Ich habe mein Haupt-Plättle (eine CF Sandisk Ultra II 4GB) neu partitioniert (-> Anhang) und gefüllt, eine trotz SektorCopy der ersten 1,75 GB mühsame und einschl. Treechck langwierige Prozedur, und dabei auf die 2GB große F32er Archiv-Partition ´J:´ auch
   mkfatfs -a -f 2 -F 32 -s 2 J:
angewendet, um die Granulation auf 1024B./Cluster zu drücken. Da, wie früher schon bemerkt, mkfatfs einen hohen Speicher-Bedarf hat, ging das nicht auf meinem Falcon (mit 11MB freiem Speicher), sondern nur auf meinem TT (und anschl. Clonen auf das Plättle im Falcon).
Die gute Nachricht: ca. 30MB mehr Platz auf J (nicht gerade üppig - aber immerhin).
Die schlechte Nachricht: Nach Wechsel von MiNT zu MAGX zeigte sich sofort wieder der Zähl-Fehler! Ich werde daher, weil ich wie dargelegt nicht von dessen Harmlosigkeit überzeugt bin, die F32er Parts. unter Magx auch weiterhin nur mit Schreibschutz benutzen.
Bem.1: Kopieren mit MiNTs (1.15.9) GEMDOS auf Parts. ohne LFN hält auch noch besondere Tücken bereit: zB. gehen Umlauts und manche Sonderzeichen, die unter TOS erlaubt sind, verloren und werden durch den Unterstrich ´_´ ersetzt! Wenn Namen von Ordnern betroffen sind, fehlt dann deren gesamter Inhalt! Das ist also ähnlich schlimm, wie beim Transfer zw. Ataris und DOSen. Von einer ordentlichen Kopier-Routine in MiNT würde ich erwarten, daß sie 1 : 1 kopiert!

=)
Ich habe auch
   dosfsck -v J:
auf meinem TT erfolgreich laufen lassen können (derzeit keine Beschwerden mehr). Das ging jedoch nicht mit 27MB, aber dann doch mit 30MB freiem Speicher: Der Speicherbedarf von dosfsck ist also noch wesentlich größer als der von mkfatfs. Eine FAT von J ist ca. 8MB groß.
Bem.2: Auch dosfsck versteht die Umlauts nicht: Die erzeugen Meldungen "bad filename...".
Bem.3: dosfsck schreibt in die Konsole mit UNIX-Zeilenenden! Das ist mit dem VT52.prg von MAGX schlecht lesbar - iGgs. zu MiniWin.prg unter MiNT+NAES.
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline Skywalker

  • Benutzer
  • Beiträge: 558
  • n/a
    • x-com.atari.org
Re: MAGX´ Macken
« Antwort #127 am: Di 09.05.2017, 15:44:26 »
Mal eine Frage:
Ich meine mich erinnern zu können, das MagiC damals VFAT unterstützt.
Wann kam denn FAT32 hinzu?
http://x-com.atari.org/ - die Atari Webseite :-)
520 STM, 1040 STE + 1040STFM  und endlich auch A500+ & A1200 :-)

Offline KarlMüller

  • Benutzer
  • Beiträge: 178
MagiC und VFAT32
« Antwort #128 am: Di 09.05.2017, 20:35:25 »
Ich meine mich erinnern zu können, das MagiC damals VFAT unterstützt.
Wann kam denn FAT32 hinzu?
Mit 6.1
« Letzte Änderung: Di 09.05.2017, 20:40:15 von KarlMüller »