Forum Übersicht - DiMAGE A-Reihe » Microdrive Probleme

Hallo,

ich habe mir für meine A2 ein Microdrive 4GB von Hitachi gekauft. Die Kamera erkennt ihn aber nicht "Karte nicht nutzbar". Ich habe ihn mit dem Computer
mit FAT32 formatiert - gleiches Problem. Anfrage bei Konicaservice: Microdrive 4GB von Hitachi geht mit der A2. Wo ist mein Problem bzw die Lösung?

schönen Sonntag noch

Peter

Hey Peter,

oftmals liegen die Probleme in den Partitionstabellen oder dem Master-Boot-Rekord verborgen. Seit dem ich mit Dimages zu tun habe, habe ich es vermieden, CFs oder MDs mit dem PC zu formatieren - bis dato sind mir persönlich solche Probleme fremd. Also wenn eine CF oder MD mal mit der Dimage läuft, immer nur über diese das Medium formatieren.
Eine Variante, die immer sehr vielversprechend bei der Problembehebung ist, ist die, die CF bzw. hier das MD mit einer Kamera anderer Hersteller zu formatieren. Anscheinend sind deren Anforderungen an das bestehende Filesystem niedriger. Also, wenn Du einen Bekannten oder einen Händler in der Nähe hast, formatier die MD mal mit einer Canon oder anderen Kamera eines Drittherstellers.


Dat Ei

Zitat von Dat Ei

---

oftmals liegen die Probleme in den Partitionstabellen oder dem Master-Boot-Rekord verborgen. Seit dem ich mit Dimages zu tun habe, habe ich es vermieden, CFs oder MDs mit dem PC zu formatieren - bis dato sind mir persönlich solche Probleme fremd. Also wenn eine CF oder MD mal mit der Dimage läuft, immer nur über diese das Medium formatieren.

Eine Variante, die immer sehr vielversprechend bei der Problembehebung ist, ist die, die CF bzw. hier das MD mit einer Kamera anderer Hersteller zu formatieren. Anscheinend sind deren Anforderungen an das bestehende Filesystem niedriger. Also, wenn Du einen Bekannten oder einen Händler in der Nähe hast, formatier die MD mal mit einer Canon oder anderen Kamera eines Drittherstellers.

---

Hier würden mich übrigens mal Details interessieren.

Wenn sich da ein eindeutiges Muster herauskristallisieren ließe, wäre es denkbar,
daß neue Versionen von Partitionier- und Formatier-Software bestimmte kritische
Kombinationen von Geometrieparametern vermeiden, so daß nach der Einrichtung
Medien herauskommen, die auch mit solchen Kameras kompatibel sind. U.U. kann
man das sogar modellabhängig einstellbar machen.

Ich kann mir durchaus vorstellen, solche Parameter z.B. in zukünftige Versionen
von DR-DOS' FDISK und FORMAT einzubauen (die natürlich auch unter den
anderen DOSen sowie unter Windows 9x/SE/ME laufen). Und auch für die
FreeDOS-Leute wäre sowas sicherlich interessant.

Um den Problemen auf den Grund zu gehen, bräuchte ich allerdings zur Analyse
Kopien des ersten physikalischen Sektors (512 Bytes) des Speichermediums bzw.
des ersten logischen Sektors (512 Bytes) des (oder der) darauf eingerichteten
Volumes, entweder als Binärfiles oder als Hex-Dumps. Diese Sektoren beinhalten
den sog. Master Boot Record (MBR) und den Bootsektor mit BIOS Parameter Block
(BPB).

Werkzeuge zum Auslesen dieser Sektoren kann ich bei Bedarf zur Verfügung
stellen.

Siehe auch:

http://www.mi-fo.de/forum/viewtopic.php?t=5986
http://www.mi-fo.de/forum/index.ph...0&#entry66563

Viele Grüße,

Matthias

Hallo Peter,

zu Zeiten, als MP3-PLayer mit 4GB Microdrive günstiger waren als einzelne 4GB Microdrives, wurden diese ausgebaut und einzeln (mit Gewinn) verkauft - manchmal wurde darauf hingewiesen, aber nicht immer.
Diese funktionierten aber nur in den MP3-Playern und PCs (was natürlich reiner Zufall war/ist :-(( ) und nicht in Kameras (worauf 90% der Käufer vertrauten), wie auch die "c't" berichtete.
Wenn Du also eines aus dieser "Serie" erwischt hast, kannst Du machen was Du willst - es wird nicht laufen. Diese sind meines Wissens immer weiß mit schwarzer Schrift und natürlich nicht in der hellblauen Hitachi-Originalverpackung - denn diese funktionieren.

Gruß
Gemini

Hallo zusammen,

habe stundenlang im www recherchiert und eine Lösung des 4GB Microdrive Probs herausgefunden!
Fazit: meine 4 GB Hitachi MD läuft!

(ob es auch Microdrives gibt, wie hier angesprochen, die nicht zum Laufen gebracht werden können, vermag ich nicht zu sagen).


ALTERNATIVE LÖSUNGSWEGE:

1. PC und Windows XP ist an, CF Microdrive Hitachi 4 GB steckt im Lesegerät.

2a. Mit dem Progrämmchen MkBootW.exe (bei meinem Aldi-Medion-PC in Start/Pragramme/Zubehör/Systemprogramme/ zu finden) wird ruck-zuck eine "bootfähige Flashkarte" erstellt.

2b. Alternativ können Nutzer von Nicht-Aldi-Medion-PCs unter dem Link http://masterbootrecord.de/deutsch/bootdisketten.php das file "winImage" und eine der "bootdisk -images" runterladen und anwenden.

DAMIT WIRD DAS MD FORMATIERFÄHIG GEMACHT! OHNE DEM SCHRITT GEHT NIX!

3. Das so formatierfähige CF-MD wird im CF-slot steckend ganz normal auf FAT32 formatiert. Ich habe es mit dem XP Konsolenprogramm <start/ausführen/mmc, Enter, snap-in "Datenträgerverwaltung"> mit der Einstellung "standard" (vermutlich 64kb Größe der Zuordnungseinheit) formatiert. Es sollte alterntiv auch im Explorer (und nicht über Konsole) ganz einfach zu machen sein <Lw:\Datei\formatieren\fat32...>!
Hinweis gegen erschrecken: dabei werden die Bootdateien vom Schritt 2a. bzw. 2b. auf dem CF-MD wieder gelöscht, was ja gewünscht ist.

4. CF-MD in die Dimage A2 und nun auch Olympus Camedia 8080 WZ, wird sie erkannt und ist einsatzfähig!

5. CF-MD zur Sicherheit nochmals in der Kamera formatiert, da die Bedienungsanleitung zur Dimage A2 das empfiehlt. Dieser Schritt ist aber, wie sich erwiesen hat, überflüssig!

6. Volle 4GB stehen zur Verfügung!

Viel Erfolg mit der Bitte um Rückmeldung!

Grüße, hobby3333.

Hallo,

danke für eure tatkräftige Hilfe. Da bin ich ja wohl reingefallen... @Gemini: meine Platte hat ein weißes Label und schwarze Schrift. Es gab aber keinen Hinweis in der ebay-Auktion, dass die MD nicht in Kameras läuft.
@hobby3333: Ist ja Wahnsinn, was Du alles geschrieben hast. Muß ich mir erst mal ausdrucken. Welche der Bootdisk-Images soll ich denn herunterladen? Ich habe XP Pro. Ich werde das testen und dann gebe ich Bescheid. Gibt ja vielleicht noch mehr Leute, die Pech hatten...

Danke nochmal an Alle

Gruß

Peter

Ja, nur in der Anfangzeit waren die OEM-Microdrives in der Kamera nutzbar.
Dann wurde dort eine heimtückische Falle eingebaut ...

Aber inzwischen gibt es ganz offiziell Hitachi-Microdrives mit 2 und 4 GB zu kaufen,
also Handelsware und keine OEM-Ware, und auch nicht teurer aus die kastrierten OEMs.
Solltest Du wirklich so Pech gehabt haben?

Du findest auf der Hitachi-Webseite irgendwo eine Abfragemöglichkeit für den Status der Garantie.
Schau mal nach, vielleicht erfährst Du da auch was über OEMs.

Zitat von hobby3333

---

2a. Mit dem Progrämmchen MkBootW.exe (bei meinem Aldi-Medion-PC in Start/Pragramme/Zubehör/Systemprogramme/ zu finden) wird ruck-zuck eine "bootfähige Flashkarte" erstellt.

2b. Alternativ können Nutzer von Nicht-Aldi-Medion-PCs unter dem Link http://masterbootrecord.de/deutsch/bootdisketten.php das file "winImage" und eine der "bootdisk -images" runterladen und anwenden.

DAMIT WIRD DAS MD FORMATIERFÄHIG GEMACHT! OHNE DEM SCHRITT GEHT NIX!

---

Wichtig zu wissen wäre, was dieses Programm *genau* macht - ich meine nicht so
oberflächlichen Kram wie: Initialisiert MBR mit richtigem Partitionstyp und Größe,
schreibt Bootsektor mit BPB, initialisiert Dateisystemstrukturen und schreibt Kernel-
dateien, sondern es kommt eben darauf an, was /genau/ da drin steht, denn da
gibt es nahezu unendlich viele Kombinationsmöglichkeiten - und manche davon
sind zwar von der Spezifikation her absolut legitim, funktionieren aber ganz
offensichtlich bei weitem nicht mit allen Embedded Betriebssystemen, die FAT-
Volumes mounten.

Da Du ja jetzt beide Bedingungen beliebig oft wieder erzeugen kannst, wäre es
nett, wenn Du mir mal Kopien der beiden oben angesprochenen Sektoren
zukommen lassen könntest, einmal vorher (also wenn die Kamera das CF/MD
nicht akzeptiert), und einmal nachher.
Ich habe verschiedene Vermutungen, woran es liegen könnte (ich meine jetzt den
zugrundeliegenden technischen Sachverhalt auf unterer Betriebssystemebene),
aber solange ich keine konkreten Beispiele sehe, bringt es nichts, hier wild herum-
zuspekulieren, zumal das sehr (sagen wir mal detailorientiert werden würde.
Aber wenn sich meine Vermutung erhärten würde, könnte man u.U. ein viel
effektiveres Workaround als das jetzt von Dir gefundene beschreiben und KoMi
/gezielt/ auf den Fehler bzw. die Begrenzung in deren Dateisystemtreiber
hinweisen, so daß die das mit einem zukünftigen Firmware-Update fixen können.
Die Entwickler bei KoMi sind Embedded-Programmierer mit Spezialisierung
auf Fotografie, d.h. das sind wohl eher nicht Experten für die Innereien eines
Desktop-Betriebssystems.
Und selbst bei vermeindlich simplen Dateisystemen wie FAT12, FAT16 und FAT32
gibt es allerhand Fallstricke zu beachten, wenn man mit allen Medien klarkommen
will, die "in the wild" vorkommen. Diese Sachen sind zum Teil hochgradig komplex
und selbst für Systemprogrammierer absolut nicht offensichtlich, z.T. treten nur
durch Zusammenspiel etlicher selbst auf den zweiten Blick nicht zusammen-
hängender Sonderzustände gleichzeitig auf, ergeben sie sich nur aus dem
historischen Wachstum des Systems, basieren auf mitgeschleppten Fehler
im "Vorbild" MS-DOS/PC DOS oder sind (mutmaßlich) Korrekturen für Fehlern
in anderen alten Systemen wie OS/2. All das ist nirgendwo öffentlich
dokumentiert, aber als einer der Entwickler von DR-DOS und Mitwirkender in
diversen "Undocumented"-Projekten habe ich über die Jahre schon tausende
Stunden mit dem Einkreisen, Festnageln und Analysieren von genau solchen
Problemen verbracht und könnte da meine Erfahrung und das Wissen um etwa 30
solcher undokumentierter "Zusatzregeln" für das 100% kompatible Erzeugen,
Lesen und Schreiben von FAT-Partitionen einbringen, um die Komiker auf die
richtige Fährte zu bringen.

Geht aber alles nur, wenn ich solche Beispielsektoren zu sehen bekomme -
ich habe ja selbst keine Digitalkamera...

Viele Grüße,

Matthias

PS. Hier findest sich ein Beispiel für einen solchen undokumentierten Quirk:

http://www.mi-fo.de/forum/index.ph...t=0&#entry86726

Hallo Matthias,

Du schreibst sehr ausführlich über Betriebssysteme. Bist Du ein USER? (Tron lässt grüßen). Gerne will ich Dir Hexdumps schicken, aber wie bekomme ich die? Du hast Tools angeboten. Wenn Du mir mit wenigen Worten (HaHa) dann noch sagst, wie ich sie anwende, hast Du Schwups auch Die Daten.

mit freundlichen Grüßen

Peter

Zitat von Peter E. Czitsch

---

Gerne will ich Dir Hexdumps schicken, aber wie bekomme ich
die? Du hast Tools angeboten. Wenn Du mir mit wenigen Worten (HaHa) dann noch sagst, wie ich sie anwende, hast Du Schwups auch Die Daten.

---

Es gibt verschiedene Möglichkeiten, die davon abhängen, unter welchem System
Du arbeitest:

Am einfachsten ist es wahrscheinlich, wenn Du unter Windows 95/98/SE/ME
arbeitest. Alternativ dazu tut's auch DOS, sofern Dein Rechner entweder das
Booten von CF/MD erlaubt (siehe System-Setup) oder Du von einem beliebigen
Medium (z.B. Floppy, Festplatte oder CD) booten kannst und das CF trotzdem
noch über das System-BIOS (INT 13h) eingebunden werden kann, so als
wäre es eine Festplatte oder eine Superfloppy. Ob das geht, ist aber von Deinem
System-BIOS abhängig. Falls das nicht unterstützt wird, würdest Du unter DOS
eigene Laufwerkstreiber für den CF/MD-Adapter benötigen, entweder einen
PCMCIA-/PC Card-Stack oder ein USB-Stack, je nachdem, was Du für Hardware
hast (PCMCIA bevorzugt). Solche Treiber sind aber schwer zu finden und leider
nicht für alle Adapter zu bekommen.

Zum Auslesen unter DOS findest Du unter dem oben auch schon angegebenen
Link (http://www.mi-fo.de/forum/index.ph...t=0&#entry66563)
zwei rudimentäre Batchjobs GETBOOT.BAT und GETMBR.BAT. Die sollten unter
jedem DOS sowie unter Windows 95/98/SE/ME laufen, vorausgesetzt das zum
Lieferumfang gehörende Tool DEBUG liegt in einem der Systemverzeichnisse
bzw. im Aufrufverzeichnis, von dem aus Du die Batchjobs startest.

GETBOOT läuft u.U. auch in DOS-Boxen von DOS-Emulatoren, sofern der
Emulator das direkte Lesen von logischen Sektoren erlaubt - also (aus
Anwendersicht auf den DOS-Emulator gesehen) am FDOS (FAT-Dateisystem-
treiber) des BDOS vorbei, aber nicht an den logischen und physikalischen
Laufwerkstreibern des darunter liegenden DOS-BIOSes vorbei. Das ist so z.B.
manchmal auch unter Windows NT/2000/XP und OS/2 gegeben, aber in der
Regel nicht. Ausprobieren kann nicht schaden - wenn's nicht geht, wird das
Betriebssystem sich schon beschweren.

GETMBR wird hingegen unter Windows NT/2000/XP oder OS/2 generell nicht
laufen, da es direkten Lesezugriff auf physikalische Sektoren benötigt, also
noch unterhalb des physikalischen Laufwerktreibers im DOS-BIOS, d.h. auf
System-BIOS-Ebene (INT 13h) ansetzt. Das ist so nur unter "echtem" DOS
bzw. unter Windows 95/98/SE/ME erlaubt, unter anderen Systemen wird das
mit einer Fehlermeldung abgefangen.

Angenommen, das CF/MD wäre als Laufwerk F: (also das sechste logische
Laufwerk) eingebunden, dann würde "GETBOOT 5" (5 = 6 - 1, da 0-basiert) eine
512 Bytes lange Binärdatei namens BOOT5.BIN erzeugen, die den Inhalt des
Bootsektors enthält. Hilfe gibt es mit "GETBOOT /H".

Die meisten CFs/MDs sind als Wechselplatte (removable drive) konfiguriert.
Falls das auch bei Deiner/m CF/MD so ist, wird die Karte vom System ähnlich
wie eine Festplatte (also ein partitioniertes Medium) eingebunden (s.o.).
Wenn das CF/MD über das System-BIOS oder einen anderen INT 13h Treiber
eingebunden ist, kannst Du den MBR auslesen, sonst nicht.
Sollte das CF/MD als Superfloppy (also als nicht partitioniertes Medium) konfiguriert
sein, gibt es logischerweise auch keinen MBR. Was nicht existiert, muß man
auch nicht auslesen. ;-) Bei manchen CF/MFs kann man das mit Tools vom
Hersteller umkonfigurieren; mir sind solche Tools z.B. für Industrial CFs von
Toshiba und Sandisk bekannt, aber vielleicht gibt's sowas auch von Hitachi.
Diese Tools setzen ein Flag im Konfigurationsspeicher der CF. Ob ein
Betriebssystem ein Wechselmedium jetzt als Wechselplatte oder als Superfloppy
sieht (und sehen kann) hängt von den Treibern ab. U.U. kommt aber die Kameras-
Software nur mit einer Variante zurecht (vermutlich als Wechselplatte).

Angenommen, das CF/MD wäre jetzt auf BIOS-Ebene als viertes physikalisches
Laufwerk eingebunden, dann hätte es die Kennung 83h (83h = 80h + 4 - 1,
da 0-basiert ab Offset 80h). Festplatten/Wechselplatten fangen bei 80h an,
Floppies/Superfloppies ab 0h. Also würde "GETMBR 83" eine 512 Bytes große
Binärdatei namens MBR83.BIN erzeugen, die den Master Bootstrap Loader
und die Partitionstabelle des MBR enthält. Auch hier gibt es Hilfe mit "GETMBR /H".

Unter Windows NT/2000/XP wird es schwieriger, da man da mit klassischen
DOS-Tools, die für solche Arbeiten prädestiniert sind, nicht weiterkommt -
direkte Hardware-Zugriffe werden abgefangen. Wir müßten dann z.B. einen
Diskeditor oder ein Disk-Image-Programm (z.B. http://www.drivesnapshot.de
oder http://uranus.it.swin.edu.au/~jn/linux/rawwrite/dd.htm ) für Win32 benutzen.
Jedenfalls könntest Du mit einem Disk-Imager eine Abzugsdatei des Mediums,
in diesem Fall des CFs/MDs, machen. Ideal wäre ein unkomprimiertes Dateiformat,
denn dann entsprechen die ersten 512 Bytes dieser Abzugsdatei dem MBR,
und man kann sie leicht abspalten. Auch der Bootsektor findet sich relativ
nah dahinter (geometrieabhängig, kann man dann am MBR ablesen). Wenn
das Medium frisch formatiert ist, müßte die etwa 4 GB große Abzugsdatei
sich extrem gut mit ZIP komprimieren lassen (auf wenige KB) - das wäre
dann auch noch eine akzeptable Größe für eine Mail. Lieber sind mir natürlich
die einzelnen Dateien.

Unter Linux ist "dd" das Tool der Wahl.

Viele Grüße,

Matthias

Hallo Matthias,

danke für deine "kurze" Erläuterung. Du steckst wohl voll in der Materie, RESPEKT.
Leider kann ich mit Deinen beschriebenen Methoden nichts anfangen, da ich 1. unter Windows XP arbeite und 2. die Karte nicht bootfähig ist. Ich kann sie also nicht auslesen. WinImage sagt z.B. da gibt es nichts zum Auslesen.
Jeder Versuch ein Image darauf zu speichern ist mit der Fehlermeldung "The current Image Format is not supported by the disk dive" bis jetzt gescheitert.

Aber ich gebe die Hoffnung (noch) nicht auf...

Gruß

Peter

Zitat von Peter E. Czitsch

---

Leider kann ich mit Deinen beschriebenen Methoden nichts anfangen, da ich 1. unter Windows XP arbeite und 2. die Karte nicht bootfähig ist. Ich kann sie also nicht auslesen. WinImage sagt z.B. da gibt es nichts zum Auslesen.

---

Ich kenne WinImage nicht (außer vom Namen her), aber ich vermute, daß das
erstmal nachschaut, ob überhaupt Dateien auf dem Medium sind und bricht dann
bei einer/s leeren CF/MD ab. Wer will schon (außer Entwicklern) einen Abzug
einer/s frisch formatierten CF/MD machen? ;-) Vielleicht kann man dieses
"Feature" abschalten, sonst probier mal Tom Ehlerts DriveSnapShot (Link hatte ich
ja schon angegeben - da gibt's eine 30-Tage-Demo-Version, Du kannst das
Programm ja nachher wieder deinstallieren). Keine Sorge, Tom ist ein seriöser
Entwickler (übrigens auch aus Aachen) und einer der "Macher" bei FreeDOS.
Wenn das auch nicht geht, sehe ich als Ausweg z.B. das DD für Windows (Link
ebenfalls in meiner letzten Mail angegeben), sonst müssen wir einen Diskeditor
für Windows XP suchen - da gibt's bestimmt auch ein freies Tool - wir brauchen
ja im Grunde nur eine absolut minimale Funktionalität.

Man könnte zwar auch das CF/MD bootfähig machen, aber wenn Du das mit einem
Imager machst, hast Du nichts davon, weil der nicht nur die Kerneldateien neu
schreibt, sondern auch den Bootsektor - und dann können wir logischerweise
nicht mehr den vorherigen Inhalt desselben auslesen. ;-) (Es gäbe eine Lösung
mit DR-DOS, das zwar normalerweise von seinen eigenen funktionell stark
erweiterten Bootsektoren gebootet werden will, aber notfalls auch mit denen
von PC DOS oder MS-DOS vorlieb nimmt, wenn man etwas trickst und ein paar
Dinge beachtet. Das hätte den Vorteil, daß man am Bootsektor nichts verändern
muß, und die DR-DOS Kerneldateien einfach mit dem COPY-Befehl auf das
Medium kopieren kann (geht bei MS-DOS/PC DOS nicht), also nicht auf SYS
o.ä. angewiesen ist. Aber auch dabei sind einige Dinge zu beachten, die an
dieser Stelle zu kompliziert und off-topic zu erläutern wären. Wäre es meine
Kamera und CF-Karte/MD vor Ort, wäre das also ein technisch gangbarer Weg,
aber jemand da "remote" durchzulotsen, ist wohl leider zu aufwendig.)

Viele Grüße,

Matthias

Hallo Peter, liebe Forenten,

zwar arbeitet auch DriveSnapshot etwas zu "intelligent", um eine echte Low-Level-
Analyse garantiert unverfälschter Daten zu erlauben, aber schon aus den (leider
nur) Fragmenten des MBR und des Bootsektors des von Peter ausgelesenen
4 GB MDs kann man sehr deutliche Rückschlüsse darauf ziehen, warum es
mit der A2 nicht funktioniert.

Der erste physikalische Sektor des Mediums enthält normalerweise den sog.
Master Bootstrap Loader (MBR) und die Partitionstabelle, in der alle primären
Partitionen des Mediums definiert sind. Bei den meisten Betriebssystemen sind
maximal vier primäre Partitionen zulässig.

NB. Nur ältere DOS-Versionen und Disk-Manager-Tools unterstützen
mitunter bis zu 16 primäre Partitionen. DR-DOS ab 7.07 und PTS-DOS
unterstützen einen fünften Partitionseintrag für sog. Advanced Active
Partitions. DR-DOS in Verbindung mit LOADER darüberhinaus auch
einen weiteren Eintrag für Multi-Boot-Scenarios.
 
Sog. logische Laufwerke in erweiterten Partitionen kann man hingegen
unter DOS ab 3.30 und unter allen heutigen Systemen praktisch in
beliebiger Anzahl anlegen. Eine erweiterte Partition dient dabei als
Container für die Kette logischer Laufwerke und "verbraucht" nach außen
hin lediglich einen primären Partitionseintrag. Normale Betriebssysteme
erlauben maximal eine erweiterte Partition pro physikalisches Laufwerk,
bestimmte Ausgaben von DR-DOS jedoch bis zu vier.
 

Der untersuchte Sektor enthält eine gültige Signatur (55h AAh), die ihn als gültigen
MBR-Sektor ausweist. Ansonsten würde das Medium vom Betriebssystem als
unpartitioniert und unformatiert zurückgewiesen werden.

Der Sektor enthält jedoch keinen MBR-Code, noch nicht mal eine Endlosschleife
oder Code zur Ausgabe einer Fehlermeldung, d.h. würde man versuchen, von
diesem Medium zu booten, so würde der Rechner keine Fehlermeldung ausgeben,
sondern abstürzen. Im Einzelfall könnte ein Absturz in dieser frühen Phase des
Bootens zur Zerstörung des Flash-Speicherinhaltes des Rechners führen, so daß
der Rechner ohne valides System-BIOS danach überhaupt nicht mehr bootfähig
wäre und man das System-BIOS erst mit einem externen Flash-Burner neu
brennen müßte. Das ist zwar ziemlich unwahrscheinlich, aber schon vorge-
kommen (sogar mir selbst unter reproduzierbaren Testbedingungen, insofern
sind das nicht irgendwelche wilden Internet-Gerüchte ;-).
Sollte das also noch dem Auslieferungszustand des Mediums entsprechen, so sollte
der CF/MD-Hersteller hier dringend seine Initialisierungsprozedur überarbeiten
und dort wenigstens eine Endlosschleife einbauen, besser eine Fehlermeldung aus-
geben, auf eine Tastatureingabe warten und INT 19h anspringen, so wie das
offiziell für diesen Fall definiert ist. Mit ein wenig Trickserei kann man das sogar
so programmieren, daß sich das nicht nur auf x86-PCs sauber verhält.

Die Partitionstabelle enthält nur einen einzigen Eintrag. Das ist soweit normal, denn
üblicherweise richtet man auf einer CF ja auch nicht mehr als ein Volume ein - die
meisten Betriebssysteme würden damit eh nicht zurechtkommen.

Dieser Eintrag erstreckt sich über die gesamte nutzbare "Oberfläche" des Mediums,
also etwa 4 GB. Auch noch kein Problem.

Aber als Partitionstyp ist dort die ID 06h eingetragen - das steht für "FAT16B"
(also 16-Bit-FAT mit 32-bittigen Sektoreinträgen) alias "BIGDOS".
Um mit einer 16-Bit-FAT (also etwas weniger als 2^16 = 65536 Zuordnungs-
einheiten, auch Cluster genannt) ein Volume mit mehr als 2 GB abzudecken,
müssen die Cluster größer als 32 KB werden. Dies ist aber offiziell nicht
erlaubt und die allermeisten Betriebssysteme weltweit kommen damit nicht
zurecht, so auch nicht Windows 95/98/SE/ME sowie sämtliche Ausgaben von
MS-DOS, PC DOS, RxDOS und OS/2, ob alt oder neu. Es gibt ein paar Ausnahmen:
Windows NT/2000/XP, Linux sowie neuere Ausgaben von DR-DOS und FreeDOS
können auch Partitionen mit Clustergrößen von 64 KB mounten - damit sind
also FAT16B-Partitionen bis zu 4 GB Größe möglich. (Für Details sei auf den
folgenden Thread verwiesen: http://www.mi-fo.de/forum/viewtopic.php?t=5986)

Zu den meisten Entwicklern von Embedded Betriebssystemen dürfte sich das
aber noch nicht herumgesprochen haben, insofern ist es eher unwahrscheinlich,
daß ein in einer Kamera genutztes Betriebssystem Cluster mit 64 KB unter-
stützt und es dürfte eher die Regel sein, daß ein solches Betriebssystem im
Rahmen des FAT16-Dateisystems auf maximal 2 GB pro Volume beschränkt
bleibt. Ich denke, das dürfte auch bei der Minolta DiMAGE A2 nicht anders sein.

Für Mediengrößen oberhalb 2 GB muß man eben entweder auf /mehrere/ FAT16-
Partitionen ausweichen (es wäre noch zu klären, ob die A2 /damit/ klarkommt,
denn das wäre zwar standardkonform, aber bei einem Wechselmedium auch
nicht gerade üblich), oder eben stattdessen FAT32 einsetzen.
Von den 32-Bit-breiten FAT-Einträgen werden im Rahmen des FAT32-Dateisystems
nur die untersten 28 Bit verwendet (außer bei der ausschließlich von DR-DOS ab
7.07 unterstützten proprietären Erweiterung FAT32B, die alle 32 Bit benutzt).
Es stehen also grob 2^28 Zuordnungseinheiten zur Verfügung, so daß man bei
einem 4 GB großen Medium problemlos wieder auf kleine Clustergrößen von
4 KB bis 8 KB kommt (mit genügend Spielraum nach oben).

Der Bootsektor dieser 4 GB großen FAT16B-Partition hat eine gültige Kennung
55h AAh, die das Volume als formatiert ausweist.

Der Bootsektor enthält einen zumindest vom äußeren Format her standard-
konformen XBPB (Extended BIOS Parameter Block), wie er für FAT16B ab
DOS 3.31 gängig (wenn auch nicht vorgeschrieben) ist.
Das OEM-Label steht noch auf "MSDOS5.0", wie es für ein unter Windows NT
formatiertes Medium üblich ist, die Medien-ID F8h identifiziert das Volume als
Festplatte, hier also als Wechselplatte (removable drive) zu verstehen,
ein Volume-Label ist nicht definiert ("NO_NAME____" und der rein kosmetische
Dateisystemeintrag steht völlig korrekt auf "FAT16___". ('_' in diesen Beispielen
bitte jeweils durch ' ' ersetzen - die Foren-Software verschluckt leider mehr als
ein Leerzeichen hintereinander.) Als Bootcode enthält der Bootsektor den NTLDR-
Code, also den Bootstrap Loader für Windows NT.

Daraus wird klar, daß dieses Medium unter Windows NT/2000/XP formatiert wurde,
welches sich ja, wie oben angesprochen, auch nicht an der Übergröße des FAT16-
Volumes stört.

Meine Vermutung geht jetzt dahin, daß der Bootsektor zwar nicht mehr im Original-
Zustand ist (wir also nicht mehr feststellen können, was sich dort ursprünglich drin
befunden hat), daß aber der MBR-Sektor nach wie vor noch im Original vorliegt,
sonst wäre da mit großer Wahrscheinlichkeit der fehlende Master Bootstrap Loader
Code eingetragen worden.
D.h. das Medium ist zwar schon fremdformatiert, aber noch nicht neu partitioniert
worden (braucht man ja auch nicht). Normalerweise kapseln moderne Betriebs-
systeme partionierte Wechselmedien auch so, daß sie überhaupt nicht mehr wie
partitionierte Medien aussehen - nur mit Tricks kommt man überhaupt an den MBR
heran (z.B. indem man /von/ diesem Medium bootet, sofern das möglich ist).
"Nach oben", also für den Anwender, sehen sie aus wie Superfloppies.

Ich könnte mir also vorstellen, daß die Kennung 06h (für "FAT16B" in der
Partitionstabelle selbst dann noch so dort stehen bleibt, wenn man das
Medium als FAT32 neu formatiert. Das würde gängige Desktop-Betriebs-
systeme nicht mal aus der Bahn werfen, da diese nur schauen, ob der Partitions-
typ ein bekannter und unterstützter Typ ist. Falls ja, werden die Volumes
entsprechend der im Bootsektor und dem Anfang der FAT verankerten
Charakteristika mit dem jeweils entsprechenden Dateisystemtyp gemountet,
und zwar völlig unabhängig davon, ob die Partitions-ID im MBR jetzt für das
ermittelte Dateisystem stimmt oder nicht (die ID wird nur von Low-Level-Tools
benötigt, die unterhalb des Betriebssystems arbeiten müssen, z.B. FDISK,
LOADER oder bei Multi-Bootloader). Falls der Partitionstyp hingegen nicht
unterstützt wird, wird das entsprechende Laufwerk einfach übergangen.
Insofern macht ein falscher Partitionstyp Desktop-Systemen herzlich wenig
aus, Embedded Systeme könnten sich aber daran verschlucken (da dieses
Verhalten, wie Volumens gemountet werden, und daß dabei der Partitions-
typ selbst unrelevant ist, nicht dokumentiert ist) und dann könnten sie z.B.
versuchen, ein als FAT32-formatiertes Volume "auf Deubel-komm-raus" als
FAT16 zu mounten, nur weil der Partitionstyp im MBR eben auf 06h für
"FAT16B" steht - das Ergebnis wäre ein Absturz oder einfach nur völliges
Datenchaos auf der Karte.
Um hier absolut sauber zu bleiben, müßte also statt der 06h bei einem als
FAT32-formatierten Volume auch eine ID 0Bh (bzw. ab 8 GB Volume-Größe
0Ch) stehen. Das bliebe also noch zu verifizieren.

Was ich noch nicht untersucht habe, sind die einzelnen Einträge des BPB, aber
um deren Konsistenz zu prüfen, bräuchte ich auch wirklich einen 1:1-Abzug
der ersten ca. 100 Sektoren des Mediums. Das geht mit DriveSnapshot nicht,
da es das Image bearbeitet (komprimiert und nur Sektoren mit "Nutzlast"
speichert). Da müßte man also "DD for Windows" oder einen Diskeditor wie
z.B. Runtimes DiskExplorer for FAT (http://www.runtime.org/diskexpl.htm)
für nehmen.

Trotzdem denke ich, daß wir das Problem schon gefunden haben:

Die A2 kommt nicht mit einer Clustergröße von 64 KB zurecht.

Das ist kein echter Fehler, aber zwecks universellerer "Medienkompatibilität" kann
man nur an Konica Minolta appellieren, daß sie die Unterstützung dafür mit einem
Firmware-Update nachschieben sollten, zumindest aber sollten zukünftige Kameras
damit klarkommen, einfach weil - wie wir sehen - solche etwas "schräg"
formatierten Medien "in the wild" vorkommen. Wäre übrigens auch interessant,
das Gleiche mit der Dynax 7 D zu untersuchen.

Das heißt übrigens nicht, daß andere in diesem Forum vorgebrachte Probleme
mit CFs/MDs auch genau damit zusammenhängen - da gibt es viel zu viele
Kleinigkeiten, wo es schief laufen kann. Das müßten wir dann im jeweiligen
Einzelfall untersuchen, ehe wir da in der Zukunft u.U. ein Muster ableiten können.

Viele Grüße,

Matthias

Hallo Matthias,

wie kann es dann sein, dass mein Hitachi MD 4GB mit 64 KB Clustergröße in der MINOLTA A2 funktionierte. Ich hatte im Forum schon gepostet (Nochmals hier zur Erinnerung):

ZITAT BEGINN: __________________________________________
ALTERNATIVE LÖSUNGSWEGE:

1. PC und Windows XP ist an, CF Microdrive Hitachi 4 GB steckt im Lesegerät.

2a. Mit dem Progrämmchen MkBootW.exe (bei meinem Aldi-Medion-PC in Start/Pragramme/Zubehör/Systemprogramme/ zu finden) wird ruck-zuck eine "bootfähige Flashkarte" erstellt.

2b. Alternativ können Nutzer von Nicht-Aldi-Medion-PCs unter dem Link http://masterbootrecord.de/deutsch/bootdisketten.php das file "winImage" und eine der "bootdisk -images" runterladen und anwenden.

DAMIT WIRD DAS MD FORMATIERFÄHIG GEMACHT! OHNE DEM SCHRITT GEHT NIX!

3. Das so formatierfähige CF-MD wird im CF-slot steckend ganz normal auf FAT32 formatiert. Ich habe es mit dem XP Konsolenprogramm <start/ausführen/mmc, Enter, snap-in "Datenträgerverwaltung"> mit der Einstellung "standard" (vermutlich 64kb Größe der Zuordnungseinheit) formatiert. Es sollte alterntiv auch im Explorer (und nicht über Konsole) ganz einfach zu machen sein <Lw:\Datei\formatieren\fat32...>!
Hinweis gegen erschrecken: dabei werden die Bootdateien vom Schritt 2a. bzw. 2b. auf dem CF-MD wieder gelöscht, was ja gewünscht ist.

4. CF-MD in die Dimage A2 und nun auch Olympus Camedia 8080 WZ, wird sie erkannt und ist einsatzfähig!

5. CF-MD zur Sicherheit nochmals in der Kamera formatiert, da die Bedienungsanleitung zur Dimage A2 das empfiehlt. Dieser Schritt ist aber, wie sich erwiesen hat, überflüssig!

6. Volle 4GB stehen zur Verfügung!
ZITAT ENDE __________________________________________

Ich habe nochmals nachgesehen: ja ich habe auf 64 KB Clustergröße formatiert!
Das kann wohl dann nicht das Fehlerkriterium sein!?
Es muss wohl was anderes sein. Kann mal jemand mein Rezept 2a nachvollziehen?
Zum testen hänge ich hier mal das CF - initialisierungsfile an. Mal sehen ob es klappt.

hobby3333.

Ich würde erst mal schauen, ob es daran liegt, daß die Partition aktiviert ist oder nicht. Das ist das erste Kriterium für bootfähig / nicht bootfähig. Und das ist so simpel, daß ein programmierer nicht daran denkt. Die Technik Fredis sind immer kompliziert unterwegs. Und dies technisch Zeug haben die Entwckler der Kameras bestimmt auswendig gelernt. Aber an so einfache Dinge denken die nicht...