Forum Übersicht - RE: Hab nun auch eine Minolta RD-175 - 3

ZITAT(manfredm @ 2010-07-09, 9:03) Ich hatte schon befürchtet, die würde uns mit USB verloren gehen, aber Gott sei dank nein, auch da gibt es Gott sei Dank die Mini/Mikro Varianten.[/quote]
Nicht nur das, es gibt die Standard-, Mini- und Micro-Varianten auch noch vom Typ A, Typ B und (bei Mini und Micro) Typ AB, jeweils als Stecker und Buchse. Und (fast) jede davon dann noch in unterschiedlichen Geschwindigkeitsklassen USB 1.x/2.0 (ohne Highspeed), USB 2.0 Highspeed und USB 3.0. Wohlgemerkt, wir reden nur von den derzeit (oder zuvor) standarisierten Steckervarianten (einige davon sind inzwischen als "deprecated" ausgewiesen), dazu kommen dann noch die unzähligen herstellerspezifischen Steckverbinder, die zwar eine USB-Verbindung herstellen, aber keinen USB-konformen Steckverbinder verwenden. Unter diesen sind mir knapp zwanzig verschiedene Typen bekannt, die relativ große Verbreitung bei Konsumgütern und in industriellen Anwendungen haben. Etwa die Hälfte davon wird als "Mini USB-Buchse" beschrieben, hat aber mit den im Standard festgelegten USB Mini-Steckverbindern überhaupt nichts zu tun, was immer wieder große Verwirrung stiftet.
ZITATDas USB Kabel für meine Alpha passt selbstverständlich nicht für die Samsungknipse meiner Frau und mein Nokiahandy hat Gottseidank wieder ein anderes und noch eines an der Voigtländerknipse meines Sohnes.[/quote]
Strenggenommen sind das dann keine USB-Kabel (nach dem USB-Standard), auch wenn sie eine USB-Verbindung herstellen. Das Kabel Deiner DSLR-A850 ist zum Beispiel nicht standardkonform, auch wenn es glücklicherweise wenigstens einem der relativ verbreiteten Firmenstandards gehorcht, siehe:

http://www.mi-fo.de/forum/viewtopic.php?t=22787

Neuere Sony Alpha DSLRs verwenden eine standardkonforme fünfpolige USB 2.0 Mini-B Buchse. Was allerdings trotzdem verwundert, ist die Tatsache, daß gerade die Mini-Verbinder inzwischen (und auch schon beim Erscheinen dieser neueren Kameras) als überholt angesehen werden müssen und das USB-Konsortium seit 2007 empfiehlt, stattdessen die etwas kleinere, aber sehr viel stabilere Micro-Variante zu verwenden. USB 2.0 Mini-B wird im aktuellen USB-Standard nur noch aus Gründen der Rückwärtskompatibilität geduldet, soll aber in neuen Designs nicht mehr verwendet werden. Da hat wohl jemand bei Sony den USB-Standard nicht gelesen... ;-)

Bei Samsung-Handies sind mir im Moment keine bekannt, die standardkonforme USB-Verbinder aufweisen würden, bei Nokia hängt es vom jeweiligen Modell ab, ob sie proprietäre oder standardkonforme Verbinder verwenden.

Viele Grüße,

Matthiasde

ZITAT(jolini @ 2010-07-08, 16:39) Ich habe nur zwei identische 256 MB CF-II Cards. Diese habe ich jeweils in der RD-175 formatiert. Eine ist zur Zeit leer (frisch formatiert, Leerkapazität 199 Bilder),[/quote]
Die ist sehr interessant.
ZITATauf der anderen befinden sich 16 Testaufnahmen (Leerkapazität 183 Bilder).[/quote]
Die ist erstmal noch nicht so wichtig. Bewahr sie aber für alle Fälle mal auf; vielleicht ergeben sich im weiteren Verlauf Fragestellungen, wofür diese Datei nützlich sein könnte.
ZITATVon beiden habe ich mit HxD jeweils ein Abbild gezogen. Die beiden zugehörigen Systemdateien MDC.CTL habe ich separat nochmal dazukopiert und das Ganze anschließend gezippt. Größe Datei Toshiba_leer.zip ca. 245 KB, Größe Datei Toshiba_used.zip ca. 24MB.[/quote]
"Toshiba_leer.zip" kannst Du einfach über das Anhangsystem des Beitragseditors hochladen, die Datei ist ja - wie erwartet - komprimiert sehr klein.

"Toshiba_used.zip" ist zu groß zum Hochladen bei der Standard-Quota im Forum. Das können wir - wie gesagt - bei Bedarf kurzfristig ändern, aber ich möchte mir erstmal die andere Datei anschauen, um beurteilen zu können, ob es sinnvoll ist, die große Datei auch noch zu sehen. Du könntest aber schon mal die MDC.CTL-Datei aus dem "used"-Paket zusammen mit einem DIR-Listing ZIPen und hochladen. Denn es ist sicherlich interessant zu sehen, wie sich der Inhalt der Datei verändert.
ZITATFrage: Wie verfahre ich jetzt mit den beiden ZIP-Dateien?[/quote]
Siehe oben.

Sehr interessant wären jetzt noch Abzüge von anderen frisch in der Kamera formatierten Speicherkarten und vielleicht die gleiche Karte in einem anderen Kameraexemplar formatiert. Die Agfa ActionCam ist natürlich genauso interessant.

Danke und viele Grüße,

Matthias

ZITAT(jolini @ 2010-07-08, 16:39) Frage: Wie verfahre ich jetzt mit den beiden ZIP-Dateien?[/quote]
erledigt

Herzlichen Dank.

Schon mal kurze Info vorab für alle: HxD speichert die Rohdaten im richtigen Format, kann also für unsere Zwecke verwendet werden.

Dein Image beinhaltet allerdings einen Rohabzug einer Partition auf der PCMCIA-Karte (HxD nennt das "logische Datenträger", keinen vollständigen Abzug des gesamten Mediums, das ja mehrere Partitionen enthalten kann und wo am Anfang noch der sog. Master Bootstrap Loader zu finden ist (HxD nennt das "physikalische Datenträger". Ich nehme zwar an, daß nur eine Partition besteht, aber in punkto Spitzfindigkeiten wäre das durchaus nochmal überprüfenswert. Und der Inhalt des MBRs ist in jedem Fall sehr interessant. Kannst Du das noch nachreichen?

Ansonsten: Der Aufbau der MDC.CTL scheint sehr einfach zu sein. Eine frische MDC.CTL-Datei besteht - vom Header abgesehen - offenbar nur aus Nullen. Bei Deiner Beispieldatei finden sich am Anfang sechs Bytes mit anderen Werten:

Offset +0000h: Aktuelle freie Speicherkapazität in Bildern (hier 199 bei frischer Karte, 183 bei benutzter Karte)
Offset +0001h: Anzahl auf dem Medium gespeicherter Bilder (0 bei frischer Karte, 16 bei benutzter Karte
Offset +0002h: Freie Speicherkapazität in Bildern bei einer leeren Karte (hier 199 in beiden Fällen)
Offset +0003h: unbekannt? (1 bei frischer Karte, 4 bei benutzter Karte)
Offset +0004h: unbekannt? (1 bei frischer Karte, 4 bei benutzter Karte)
Offset +0005h: unbekannt? (1 bei frischer und benutzter Karte)

Das könnten Bytes sein, die irgendwelche Granularitäten angeben oder Löschzähler oder eine Versionsnummer oder auch sonst was. Wird sich noch zeigen...

Die Datei wird von der Kamera sektorweise angesprochen.

Desweiteren finden sich in der MDC.CTL-Datei der benutzten Karte jeweils am Anfang der Folgesektoren (also bei Offsets +0100h, +0200h, ...) ein paar Bytes ungleich 0. Ich hab zwar ein paar Vermutungen, um was es sich dabei handeln könnte, aber um das zu verifizieren, müßte ich noch ein paar Beispieldateien mehr sehen.

Vielleicht wäre folgendes Experiment aufschlußreich:

- Karte frisch in Kamera formatieren
- Karte entnehmen und MDC.CTL Datei auf PC als MDC_0.CTL sichern.

- Karte wieder in Kamera stecken und ein Foto machen
- Karte entnehmen und MDC.CTL Datei auf PC als MDC_1.CTL sichern.

- Karte wieder in Kamera stecken und ein Foto machen
- Karte entnehmen und MDC.CTL Datei auf PC als MDC_2.CTL sichern.

.. (wiederholen bis mindestens 20 Aufnahmen gemacht wurden)

- Karte wieder in Kamera stecken und letztes Foto löschen
- Karte entnehmen und MDC.CTL Datei auf PC als MDC_21.CTL sichern.

- Karte wieder in Kamera stecken und letztes Foto löschen
- Karte entnehmen und MDC.CTL Datei auf PC als MDC_22.CTL sichern.

- Karte wieder in Kamera stecken und ein Foto machen
- Karte entnehmen und MDC.CTL Datei auf PC als MDC_23.CTL sichern.

- Karte wieder in Kamera stecken und ein Foto machen
- Karte entnehmen und MDC.CTL Datei auf PC als MDC_24.CTL sichern.

- Alle MDC_xx.CTL Dateien als ZIP-Archiv packen und hier hochladen.

Das ist aber in erster Linie nur interessant, um unseren allgemeinen Wissensdurst zu stillen, für die Erzeugung von MDC.CTL-Dateien in einem eigenen Formatierprogramm o.ä. ist es vermutlich gar nicht nötig, viel mehr über den Aufbau der MDC.CTL-Datei zu wissen, als das, was wir jetzt schon ablesen können. Wir brauchen nur noch Beispiele von sehr viel kleineren und sehr viel größeren Karten.

Viele Grüße,

Matthias

Bei dem Dateisystem der frisch in der RD-175 formatierten PCMCIA-Karte handelt es sich um das Dateisystem "FAT16B" in der neueren "BIGDOS"-Variante ab DOS 3.31 mit 32-Bit-breiten Sektoreinträgen (also der FAT16-Variante, die auf partitionierten Medien mit dem Partitionstyp 06h korrespondieren würde, nicht der älteren FAT16-Variante mit Partitionstyp 04h).

Das Format des BIOS Parameter Blocks im Bootsektor entspricht vom Aufbau her einem standardkonformen XBPB (Extended BPB) mit Signaturbyte 29h an Offset +26h, wie er ab DOS 3.31 und OS/2 1.3 üblich ist. Verschiedene Einträge weisen auf die Verwendung als partitioniertes Medium hin, also auf eine Konfiguration als Wechselfestplatte, nicht als Superfloppy.

Das Dateisystem nutzt zwei FATs, die beide synchron gehalten werden. Zwei FATs sind gängig, Microsoft-Betriebssysteme kommen auch nicht mit anderen Werten als zwei FATs klar, außer auf RAM-Disks, wo üblicherweise nur eine FAT verwendet wird.

Die Sektorgröße beträgt 512 Bytes/Sektor (allgemein üblich), und das Volume weist in diesem Fall eine Clustergröße von 32 KiB auf. Letzteres ist für ein Volume mit - wie hier - gerade mal 256 MiB Größe extrem unüblich! Normale Formatierprogramme würden hier standardmäßig eine wesentlich kleinere Clustergröße (4 KiB oder 8 KiB) wählen.
Eine Clustergröße von 32 KiB garantiert allerdings eine maximal effiziente Ausnutzung des verfügbaren Speicherplatzes auf einem Volume, auf dem ja nur große Bilddateien gespeichert werden sollen. Der Verschnitt (Cluster Overhang) bleibt so minimal.
Möglicherweise korrespondiert auch die Größe der MDC.CTL-Datei mit der Clustergröße. Sollte die MDC.CTL hingegen immer 32 KiB groß sein, wäre es denkbar, daß die Kamera-Firmware, die möglicherweise nur eine unvollständige FAT-Implementierung besitzt, diese Datei nur dann sauber verarbeiten kann, wenn sie nicht über mehrere Cluster verteilt ist, und daß deshalb die Clustergröße auf 32 KiB hochgesetzt wurde und kleinere Clustergrößen zu einer Fehlfunktion führen würden. Clusterketten zu folgen, wie es ein FAT-Dateisystemtreiber machen muß, ist eine relativ zeitaufwendige Sache und auch nicht ganz trivale Angelegenheit, wenn man das auf einem Mikrocontroller, wie er vermutlich in der Kamera werkelt, implementieren möchte (was nicht heißt, daß es nicht geht - ich habe das selbst schon oft genug gemacht).
Es wäre z.B. denkbar, daß die MDC.CTL-Datei eine Art "Karte" enthält, die einen Paralleleinstieg in den Datenbereich der FAT-Partition "an den FAT-Dateisystemverwaltungsstrukturen vorbei" bietet, so daß die Kamera unkompliziert und schnell auf die Bilddateien zugreifen kann, die unfragmentiert an bestimmten festgelegten Orten auf dem Medium liegen und daß die FAT-Verwaltungsstrukturen dann erst asynchron nachgezogen werden, damit nach Entfernen der Karte aus der Kamera auch ein normaler FAT-Dateisystemtreiber die Dateien findet. Sowas könnte Performancegründe haben, aber auch ursächlich im begrenzten Speicherplatz in der Kamera begründet liegen. Vielleicht wird darüber aber auch sowas wie wear leveling realisiert. Ist aber erstmal noch Spekulation.

Die Zahl der Wurzelverzeichniseinträge ist mit 256 Einträgen á 32 Bytes der Größe des Mediums angemessen und insofern korrekt berechnet, als daß sie genau auf einer Sektorgrenze auskommt. Minimal wären hier 208 Einträge möglich gewesen, wenn wir 199 plus 1 Dateien speichern können müssen. Aber die drei gewonnenen Sektoren hätten auch nicht genug Speicherplatz ergeben, als daß man ein Bild mehr hätte speichern können, insofern ist das schon völlig in Ordnung so.

Das Volume besitzt im vorliegenden Fall eine logische Geometrie mit 16 Köpfen und 32 Sektoren pro Spur.
Neben der Adressierung über die Logical Block Address (LBA) kann so auch noch über das Tripel aus Zylinder/Kopf/Sektor (CHS) auf das Medium zugegriffen werden. Das ist gute gängige Praxis bei Medien mit weniger als 8 GiB Speicherplatz, aber gerade bei Flash-Disks, die ja keine "echte" Geometrie mehr haben, die man zwangsläufig nach außen reflektieren müßte, ist das nicht immer der Fall, insofern erwähnenswert.
Es wäre in jedem Fall zu prüfen, ob die Kamera über CHS oder über LBA auf das Medium zugreift, denn wenn sie dafür CHS benutzt, kommt sie wahrscheinlich nicht mit allen theoretisch möglichen logischen Geometrien zurecht, so daß bei der Formatierung eine passende logische Geometrie forciert werden müßte.
Mehr als 16 Köpfe wurden von vielen alten PCs nicht unterstützt, was letztlich auf eine Beschränkung des WD1003-Disk-Controllers zurückgeht, der in PC/ATs zum Einsatz kam, bevor IDE-Platten das Licht der Welt erblickten, und zu dem selbst IDE-Platten rückwärtskompatibel blieben. Zwar wurde diese Beschränkung später aufgehoben, aber trotzdem versuchte man aus Rückwärtskompatibilitätsgründen noch lange, die Anzahl der Köpfe auf maximal 16 zu beschränken. Viele ältere (Adaptec-)SCSI-Controller ohne Sektormapping beschränken die Geometrie auf maximal 32 Sektoren und 64 Seiten, ein IBM-kompatibles Rechner-BIOS auf maximal 1023 Zylinder.
Bei einer Gesamtgröße des Volumens von hier 500192 Sektoren á 512 Bytes (entsprechend 244,24 MiB) ergibt das 977 Zylinder.

Entgegen dem Standard ist der freie Datenbereich mit dem Füllbyte FFh belegt. Normalerweise wird der freie Bereich hingegen mit dem Wert F6h gefüllt. (Das rührt noch aus den Zeiten von uralten Disk-Controllern her, für die dieses Bitmuster besondere Eigenschaften hatte.) Heutigen Festplatten ist es völlig egal, auf Flash-Disks ist es allerdings sehr sinnvoll (und wird durchaus auch von anderen so gemacht), als Füllbyte den Wert FFh zu verwenden, um den Verschleiß des Mediums zu minimieren. Es handelt sich also um keinen Fehler in der Implementierung, sondern nur um eine erwähnenswerte Spitzfindigkeit. Jedem normalen FAT-Dateisystemtreiber muß es völlig egal sein, was in nicht beschriebenen Bereichen für Werte stehen. Viele bessere Formatierprogramme erlauben auch die Angabe alternativer Füllbytes, um auf solche Besonderheiten besser eingehen zu können.

Die MDC.CTL-Datei liegt direkt am Anfang des Datenbereichs im Cluster 2, also dort, wo bei einem bootfähigen Medium normalerweise die Bootloader/Kerneldateien liegen würden (IO.SYS/MSDOS.SYS, IBMBIO.COM/IBMDOS.COM bzw. DRBIOS.SYS/DRBDOS.SYS bei diversen DOS-Versionen). Die Datei ist im ersten Verzeichniseintrag eingetragen. Das muß nicht, aber könnte eine der kritischen Bedingungen sein, die darüber entscheiden, ob die Kamera mit der Datei umgehen kann oder nicht. Denn wenn sie selbst nur einen rudimentären FAT-Dateisystemtreiber implementiert hat, möchte sie vielleicht auch auf diese Datei direkt zugreifen, nicht erst über das gemountete Dateisystem. (Sowas ähnliches machen auch die Bootsektoren vieler Microsoft-Betriebssysteme, die die Bootdateien unfragmentiert an einer physikalisch vorbestimmten Stelle auf dem Medium erwarten - wobei das meiner Ansicht mehr daran liegt, daß deren Entwickler nicht effizient programmieren können und es einfach nicht geschafft haben, mehr "Intelligenz" in den zwangsläufig hart begrenzten Platz des Bootsektors (512 Bytes) zu packen - aus eigener Erfahrung weiß ich, daß man mit "Grips" in 512 Bytes neben dem kompletten herkömmlichen DOS-Bootsektor-"Pflichtprogramm" durchaus auch ein Mini-Disk-Operating-System mit FAT12/FAT16/FAT16B/FAT32/FAT32B-Dateisystem und CHS/ECHS/LBA28/LBA32-Unterstützung zum Auffinden und Laden der nicht notwendigerweise unfragmentiert auf dem Medium liegenden Kerneldateien (bis 64 KiB Image-Größe) nebst einem mit DR-DOS, PC-DOS, MS-DOS und REAL/32 rückwärtskompatiblen Multi-OS-Bootstrap-Loader und PnP-Unterstützung unterbringen kann, der auch auf Maschinen mit gerade mal 128 KiB Hauptspeicher noch funktioniert und mit Maschinenbefehlen auskommt, die ein Original IBM PC von 1981 genauso versteht wie jeder heute gängige PC, aber das ist ein anderes Thema... ;-) )

Die MDC.CTL-Datei besitzt die Attribute "Versteckt" und "Schreibgeschützt" (und "Archiv", was aber für unsere Fragestellung unrelevant ist). Das "System"-Attribut ist nicht gesetzt, was normalerweise bedeutet, daß die Datei von Defragmentiersoftware als relokatibel angesehen werden darf (ob das auch wirklich so ist, muß noch überprüft werden). Der Verzeichniseintrag selbst entspricht weitestgehend dem Standard, wie er von FAT12-/FAT16-Volumes her bekannt ist, d.h. ohne OS/2 Extended Attributes, ohne DR File Password, File Owner, Permission Sets und Deletion Tracking, und ohne VFAT-Erweiterung für lange Dateinamen - mit einer Ausnahme:
Der allgemein übliche Last Modified-Zeitstempel für die Datei an Offset +18h steht fest auf BF21h, was korrekt nach dem Standard interpretiert für 2075-09-01, 00:00:00 Uhr steht. Vermutlich ist hier aber eher das magische Datum 1996-12-31 im Releasezeitraum der Kamera gemeint gewesen, das sich (fast) ergibt, wenn man die beiden Bytes des Datumsstempels vertauscht. Korrekt ergibt sich damit das ungültige Datum "1996-13-31, 00:00:00 Uhr", aber es ist anzunehmen, daß der Entwickler dieses Codes sich nicht mit dem FAT-Dateisystem auskannte und es so zu einem off-by-1-Fehler und einem Byte-Order-Fehler kam.
Zusätzlich steht der erst mit Windows 95 eingeführte Last-Access-Zeitstempel an Offset +12h auf 3CE8h, was sich als 2010-07-08 dekodieren läßt und somit mit großer Wahrscheinlichkeit nicht von der Formatiersoftware, sondern vom PC-Betriebssystem stammt, das auf diese Datei zugegriffen hat. Bitte mal überprüfen, indem das Image der frisch erzeugten Datei gezogen wird, bevor auf irgendeine Datei auf dem Medium zugegriffen wurde (also auch ohne die MDC.CTL-Datei vorher zu kopieren).

Wurdest Du beim Formatieren nach dem gewünschten Namen gefragt, oder wo kommt die Angabe "TOSHIBA256M" her? Interessant ist übrigens, daß das Volume Label nur im XBPB selbst vorkommt, nicht als spezieller Verzeichniseintrag, wie es früher üblich war.

Viele Grüße,

Matthias

Auf dem "leeren" Image finden sich im Datenbereich auch noch eine Reihe verwaister Verzeichniseinträge sowie Bereiche, die offenbar zu gelöschten Dateien gehören (jetzt weiß ich auch, warum die gezippte Datei immerhin über 200 KiB groß ist, ich hätte nämlich noch viel weniger erwartet ;-) ). Im Moment ist nicht klar, ob die während der Formatierung so erzeugt wurden, oder ob das Fragmente einer früheren Nutzung sind.

Um dem auf den Grund zu gehen, schlage ich vor, die leere Speicherkarte in einem PC mit einer vollständigen Formatierung (keine Schnellformatierung) komplett zu löschen. Die vollständige Formatierung ist wichtig, damit der gesamte Datenbereich neu initialisiert wird.
Bitte davon ein Image ziehen, damit wir "vorher-nachher" vergleichen können.
Dann diese Karte in der Kamera formatieren, keine Bilder speichern etc. und von dieser Karte im PC ein weiteres Image ziehen, ohne vorher auf irgendwelche Dateien auf der Karte zugegriffen zu haben.

Viele Grüße,

Matthias

ZITAT(matthiaspaul @ 2010-07-10, 15:40) Die MDC.CTL-Datei liegt direkt am Anfang des Datenbereichs im Cluster 2, also dort, wo bei einem bootfähigen Medium normalerweise die Bootloader/Kerneldateien liegen würden (IO.SYS/MSDOS.SYS, IBMBIO.COM/IBMDOS.COM bzw. DRBIOS.SYS/DRBDOS.SYS bei diversen DOS-Versionen). Die Datei ist im ersten Verzeichniseintrag eingetragen. Das muß nicht, aber könnte eine der kritischen Bedingungen sein, die darüber entscheiden, ob die Kamera mit der Datei umgehen kann oder nicht.[/quote]
Um herauszubekommen, ob es für die Kamera wichtig ist, daß die Datei MDC.CTL im ersten Verzeichniseintrag eingetragen ist, schlage ich folgendes einfaches Experiment vor:

- Die Speicherkarte wird in der Kamera frisch formatiert.
- HxD wird unter Extras>Optionen>Sicherheit so konfiguriert, daß kein Schreibschutz aktiviert wird.
- Am PC wird mit HxD das zugehörige logische Laufwerk ohne Schreibschutz geöffnet.
- In der Hex-Editor-Ansicht sucht man von oben nach unten den Text "MDC". Das erste Vorkommen in der hier besprochenen 256MB-Disk befindet sich an Dateioffset +E000h. Dort müßte etwas wie folgt stehen:
ZITAT[...]
+DFF0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+E000h: 4D 44 43 20 20 20 20 20 43 54 4C 23 00 00 00 00
+E010h: 00 00 E8 3C 00 00 00 00 21 BF 02 00 00 80 00 00
+E020h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+E030h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+E040h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[...][/quote]
Die grünen Bereiche müssen exakt so vorkommen, wie hier gezeigt, sonst nachfragen und keinesfalls speichern. Die blauen Bereiche könnten bei anderen Mediengrößen von den hier dargestellten Werten abweichen (dann nimmt man die Werte, die jeweils angezeigt werden).

- Den grünen und blauen Bereich schreibt man 1:1 ab und trägt ihn exakt 32 Bytes tiefer (d.h. hier ab Dateioffset +E020h) in den roten und braunen freien Bereich ein (blaue und braune Bereiche hier wie im Beispiel angegeben):
ZITAT[...]
+DFF0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+E000h: 4D 44 43 20 20 20 20 20 43 54 4C 23 00 00 00 00
+E010h: 00 00 E8 3C 00 00 00 00 21 BF 02 00 00 80 00 00
+E020h: 4D 44 43 20 20 20 20 20 43 54 4C 23 00 00 00 00
+E030h: 00 00 E8 3C 00 00 00 00 21 BF 02 00 00 80 00 00
+E040h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[...][/quote]
- Danach werden noch einige Bytes im grünen/blauen Bereich wie folgt geändert:
ZITAT[...]
+DFF0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+E000h: E5 44 43 20 20 20 20 20 43 54 4C 00 00 00 00 00
+E010h: 00 00 00 00 00 00 00 00 21 BF 00 00 00 00 00 00
+E020h: 4D 44 43 20 20 20 20 20 43 54 4C 23 00 00 00 00
+E030h: 00 00 E8 3C 00 00 00 00 21 BF 02 00 00 80 00 00
+E040h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[...][/quote]
- Dies speichert man nun mit HxD auf die Karte zurück.
- Karte nun wieder in die Kamera einlegen und überprüfen, ob diese damit arbeiten kann (Bilder speichern, usw.) oder eine Fehlermeldung anzeigt.

Viele Grüße,

Matthias

ZITAT(ddd @ 2010-07-02, 10:00) gruesze, thomas (mit 'nem Schrank voller SCSI-Krempel. Braucht jemand einen HVD-Fast-SCSI-Adapter für PA-Bus? Die letzte Platte ist verreckt...)[/quote]

Hast Du (irgendjemand hier) noch einen SCSI 1 Gender Changer female-female rumliegen?? Der würde mir bei den diversen Basteleien zu diesem Thread deutlich helfen.

mfg / jolini

ZITAT(matthiaspaul @ 2010-07-10, 15:40) Der allgemein übliche Last Modified-Zeitstempel für die Datei an Offset +18h steht fest auf BF21h, was korrekt nach dem Standard interpretiert für 2075-09-01, 00:00:00 Uhr steht.[/quote]

Mit einem Experiment können wir leicht herausbebekommen, ob dieser seltsame Datumsstempel der MDC.CTL-Datei für die Kamera in irgendeiner Weise relevant ist oder nicht. Ich schlage dafür folgendes vor:

- Die Speicherkarte wird in der Kamera frisch formatiert.
- HxD wird unter Extras>Optionen>Sicherheit so konfiguriert, daß kein Schreibschutz aktiviert wird.
- Am PC wird mit HxD das zugehörige logische Laufwerk ohne Schreibschutz geöffnet.
- In der Hex-Editor-Ansicht sucht man von oben nach unten den Text "MDC". Das erste Vorkommen in der hier besprochenen 256MB-Disk befindet sich an Dateioffset +E000h. Dort müßte etwas wie folgt stehen:
ZITAT[...]
+DFF0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+E000h: 4D 44 43 20 20 20 20 20 43 54 4C 23 00 00 00 00
+E010h: 00 00 E8 3C 00 00 00 00 21 BF 02 00 00 80 00 00
+E020h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[...][/quote]
Die grünen Bereiche müssen exakt so vorkommen, wie hier gezeigt, sonst nachfragen und keinesfalls speichern. Die blauen Bereiche könnten z.B. bei anderen Mediengrößen von den hier dargestellten Werten abweichen (dann beläßt man die Werte, die jeweils angezeigt werden).

- Nun werden darin vier Bytes (rot) wie folgt geändert:
ZITAT[...]
+DFF0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+E000h: 4D 44 43 20 20 20 20 20 43 54 4C 23 00 00 00 00
+E010h: 00 00 00 00 00 00 00 00 EB 3C 02 00 00 80 00 00
+E020h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[...][/quote]

- Dies speichert man nun mit HxD auf die Karte zurück.
- Karte nun wieder in die Kamera einlegen und überprüfen, ob diese damit arbeiten kann (Bilder speichern, usw.) oder eine Fehlermeldung angezeigt wird.

Viele Grüße,

Matthias

In diesem Beitrag findet sich übrigens noch eine weitere Beispiel-MDC.CTL-Datei:

http://www.mi-fo.de/forum/index.php?showto...st&p=189601

Viele Grüße,

Matthias

ZITAT(matthiaspaul @ 2010-07-10, 12:09) Dein Image beinhaltet allerdings einen Rohabzug einer Partition auf der PCMCIA-Karte (HxD nennt das "logische Datenträger", keinen vollständigen Abzug des gesamten Mediums, das ja mehrere Partitionen enthalten kann und wo am Anfang noch der sog. Master Bootstrap Loader zu finden ist (HxD nennt das "physikalische Datenträger". Ich nehme zwar an, daß nur eine Partition besteht, aber in punkto Spitzfindigkeiten wäre das durchaus nochmal überprüfenswert. Und der Inhalt des MBRs ist in jedem Fall sehr interessant. Kannst Du das noch nachreichen?[/quote]

Nachdem meine SCSI-Konfiguration provisorisch wieder läuft (wegen der leidigen Steckerkompatibilität muß ich immer einen ganzen SCSI-Tower mit mehreren Laufwerken, Streamern, etc. dazwischenschalten, siehe Hilferuf Gender Changer, post # 38), fange ich mal an die Liste abzuarbeiten. Hier zunächst das physikalische Abbild von Toshiba256MB_leer, sorry diese Feinheit hatte ich anfänglich übersehen.

mfg / jolini

moin, ZITAT(jolini @ 2010-07-11, 18:19) siehe Hilferuf Gender Changer, post # 38[/quote]
Details siehe PM!
sorry fürs späte Melden, es ist hier so heiß & stickig (drinnen wie draußen, tags wie nachts), dass selbst der Liedschlag zur schweißtreibenden Anstrengung gerät.

gruesze, thomas

ZITAT(matthiaspaul @ 2010-07-10, 16:51) Um dem auf den Grund zu gehen, schlage ich vor, die leere Speicherkarte in einem PC mit einer vollständigen Formatierung (keine Schnellformatierung) komplett zu löschen. Die vollständige Formatierung ist wichtig, damit der gesamte Datenbereich neu initialisiert wird.
Bitte davon ein Image ziehen, damit wir "vorher-nachher" vergleichen können.
Dann diese Karte in der Kamera formatieren, keine Bilder speichern etc. und von dieser Karte im PC ein weiteres Image ziehen, ohne vorher auf irgendwelche Dateien auf der Karte zugegriffen zu haben.[/quote]

aber gerne doch ...

mfg / jolini

ZITAT(matthiaspaul @ 2010-07-10, 15:40) Wurdest Du beim Formatieren nach dem gewünschten Namen gefragt, oder wo kommt die Angabe "TOSHIBA256M" her? Interessant ist übrigens, daß das Volume Label nur im XBPB selbst vorkommt, nicht als spezieller Verzeichniseintrag, wie es früher üblich war.[/quote]

Nein, ich wurde nicht gefragt. Das waren wohl die kleinen, unheimlichen bits- und bytes-Schieber.

mfg / jolini

moin, ZITAT(matthiaspaul @ 2010-07-10, 15:40) Wurdest Du beim Formatieren nach dem gewünschten Namen gefragt, oder wo kommt die Angabe "TOSHIBA256M" her?[/quote]
Da jolini ja verneint hat, dürfte das von Anfang an auf der vorformatierten Karte drauf gewesen sein!
Kenne ich von einigen, speziell Toshiba, CF-Karten. Die hatten auch ein Volume-Label, welches entsprechend aussah (ich habe die immer geändert).

Vermutung: der Volume-Label wird von der Minolta-Formatier-SW nicht angerührt, ev. der ganze XPBP nicht?

gruesze, thomas