Forum Übersicht - RE: Objektivsimulator für das Minolta-/Sony-A-Bajonett - 7

ZITAT(ddd @ 2010-04-23, 11:10) Ausserdem gibt es einen Adapter, der das Ganze nutzbar macht, Details folgen.

Ich habe nicht vor, damit Umsätze zu generieren! Das ist eine Spielerei für mich, Mitmacher müssen nur ggfs. entstehende Bauteil- und Versandkosten mittragen.[/quote]

!SUPER! Ich ziehe respektvoll mein Mützchen.

mfg / Werner

moin,

eine erste Schaltplanversion habe ich oben (post #87) eingehängt.

Das Analyseprogramm für die Digitrace-SampleLogs ist fast fertig. Sobald eine erste (Spaghetticode-) Version richtig läuft, hänge ich es hier als Anhang ein.
Auch SampleLogs (gezippt sind sie recht klein) als Beispiele wird es dann geben, und natürlich fertig ausgewertete nicht nur von gewöhnlichen Objektiven.

gruesze, thomas

Thomas arbeitet schon an einem Auswertetool für Linux, deshalb habe ich mir mal die DOS-/Windows-Seite vorgenommen und - ein bißchen Spaß muß sein - folgendes kleines DEBUG-Skript geschrieben, das ein Tracelog in Form einer Digitrace-Datei in die uns bereits von PonyProg etc. bekannten Lensdumps übersetzt und ausgibt:

DGT2LDMP.DEB (lies als "DGT to Lensdump", die "2" steht aber auch für Kanal 2=MISO):

A
            &#59; assume ES = DS = CS, SS:SP initialized, CS segment allocated
mov   dx,200&#59; DS:DX -> ASCIZ source file name "TRACELOG.DGT"
xor   cx,cx &#59; share compatibility mode
mov   ah,3D &#59; open file
int   21    &#59; call DOS
 jc   183&#59;  bail out on error
mov   di,500&#59; ES:DI -> target buffer (growing)
xor   dx,dx &#59; assume clock status DH = low, set bit counter DL = 0
mov   bx,ax &#59; file handle
;read_sector:;  (112h)
push  dx    &#59; preserve status
mov   cx,200&#59; count of bytes to read (1 sector)
mov   dx,300&#59; DS:DX -> source buffer
mov   ax,3F00; read file by handle BX, assume AL = 0 (for buggy emulators)
clc         &#59; assume no error (for buggy emulators)
int   21    &#59; call DOS
 jc   162&#59;  close file on read error
test  ax,ax &#59; zero bytes read?
 jz   162&#59;  close file on EOF
mov   si,dx &#59; DS:SI -> source buffer
pop   dx    &#59; restore status
mov   cx,ax &#59; count of bytes to process
cld         &#59; count upwards
;scan_buffer:;  (12Bh)
lodsb    &#59; read tracelog byte from DS:[SI] into AL, increment pointer
mov   ah,al &#59; stream status
and   ah,1  &#59; strip off all but channel 1 (CLK)
cmp   ah,dh &#59; clock level change?
 je   15E&#59;  nothing to process, if same as before
mov   dh,ah &#59; store current status for next round
test  ah,ah &#59; sample on falling edge
 jnz  15E&#59;  skip if rising edge
shr   al,1  &#59; extract desired channel 2 (LSIN/MISO)
and   al,1  &#59; 1 if channel bit high, 0 if channel bit low
mov   ah,[220]; get previously processed result byte
or    ah,al &#59; merge new bit from bitstream into result byte
ror   ah,1  &#59; prepare for next bit in the row
mov   [220],ah; temporarily store away interims result
inc   dx    &#59; increment bit counter DL
cmp   dl,8  &#59; 8 bits read?
 jb   15E&#59;  byte not finished, get next bit from bitstream
mov   dl,0  &#59; bit counter back to 0 for next byte
mov   al,ah &#59; get decoded byte
mov   [220],dl; reset result byte to 0 for next round
stosb    &#59; store decoded byte AL at ES:[DI], increment pointer
test  di,di &#59; target buffer overflow?
 jz   162&#59;  bail out and close file 
;scan_skip: &#59;  (15Eh)
 loop 12B&#59;  dec counter CX, finished reading buffer? else get next byte
jmp   112&#59; source buffer empty, read next sector
;close_source:;  (162h)
pop   dx    &#59; stack alignment (cosmetics since not necessary inside DEBUG)
mov   ah,3E &#59; close source file by handle BX
int   21    &#59; call DOS
xor   cx,cx &#59; attributes
mov   dx,210&#59; DS:DX -> ASCIZ target file name "LENSDUMP.BIN"
mov   ah,3C &#59; create or trunc file
int   21    &#59; call DOS
 jc   183&#59;  bail out on error
mov   bx,ax &#59; file handle 
mov   dx,500&#59; DS:DX -> buffer contents to store on disk
sub   di,dx &#59; get count of decoded bytes
mov   cx,di &#59; count of bytes to write
mov   ah,40 &#59; write file by handle BX
int   21    &#59; call DOS
mov   ah,3E &#59; close file by handle BX
int   21    &#59; call DOS
;exit_program:;  (183h)
nop         &#59; mark end of code
 

F 200 L FE00 0
E 200 "TRACELOG.DGT"
E 210 "LENSDUMP.BIN"
G=100 183
D 500
Q
Q        &#59; R1.00 2010-04-24 MPL
 

Hinweis: Zur Dokumentation habe ich den Code oben mal kommentiert. Da aber nicht alle Versionen von DEBUG Kommentare erlauben, enthalten die angehängten Dateien diese Kommentare nicht (leider wird die formatierte Darstellung trotz CODE-BBCode etwas gestört...).

Das Skript wird wie folgt am Prompt von DOS oder Windows aufgerufen:

DEBUG < DGT2LDMP.DEB

Dabei wird das Tracelog unter dem Dateinamen TRACELOG.DGT im aktuellen Verzeichnis erwartet. Das Skript schreibt das Ergebnis in die Datei LENSDUMP.BIN im aktuellen Verzeichnis. Wenn letztere Datei schon existiert, wird sie überschrieben.

Das Skript ist so voreingestellt, daß es das Tracelog durchscannt und bei jeder fallenden Flanke der Clock den Zustand von MISO sampelt. Der daraus resultierende Bitstrom der MISO-Werte wird byteweise ins Lensdump geschrieben, wobei bei dieser Gelegenheit gleich die Bitreihenfolge in die von uns für die spätere Auswertung gewünschte Reihenfolge gedreht wird. Das Ergebnis ist ein Lensdump in einer ähnlichen Form, wie wir sie schon von weiter oben aus diesem Thread her kennen.

Das Tracelog wird in dem von Thomas oben schon beschriebenen Digitrace-Format erwartet, wobei es für die automatische Auswertung wichtig ist, die folgende Kanalzuordnung einzuhalten:
Kanal 1 = 25-polige D-Sub-Verbinder Pin 2 = Parallel-Port Bit 0 = "L3" (CLK)Kanal 2 = 25-polige D-Sub-Verbinder Pin 3 = Parallel-Port Bit 1 = "L1" (LSIN/MISO)Kanal 3 = 25-polige D-Sub-Verbinder Pin 4 = Parallel-Port Bit 2 = "L4" (CSLNS/SS)Kanal 4 = 25-polige D-Sub-Verbinder Pin 5 = Parallel-Port Bit 3 = "L6" (LSOUT/MOSI) - optional
Die von dem Skript maximal unterstützte Dateigröße für TRACELOG.DGT liegt bei 2 Gigabyte, die maximale Dateigröße der resultierenden Datei LENSDUMP.BIN kann 64256 Bytes erreichen, was aber in der Praxis nicht vorkommen dürfte, da die Objektive ja nur wenige Dutzend Bytes enthalten und LENSDUMP.BIN dementsprechend kurz bleibt.

Einige Funktionen lassen sich auch leicht ohne Offset-Verschiebungen im Skript anpassen, indem man den Code im inneren Schleifenblock zum Teil mit NOPs (Opcode 90h) überschreibt:

Wird in DGT2LDMP.DEB der Codebereich +137h bis +158h mit NOPs (Opcode 90h) überschrieben (was man durch Einfügen einer Zeile "F 137 158 90" unmittelbar vor der Zeile mit "G=100 183" erreicht), so nimmt das Skript keinerlei Auswertung mehr vor, sondern komprimiert das Tracelog nur so, daß jeweils nur noch das erste Tracebyte (mit allen vier Kanälen) bei einer steigenden oder fallenden Flanke der Clock weggeschrieben wird. Wenn wir davon ausgehen, daß es keine Glitches gibt, kann man so eine erhebliche Größenreduzierung und damit handhabbare Dateigrößen der Tracelogs erreichen, ohne daß dabei für uns relevante Informationen verlorengehen. Deshalb liefert eine spätere Auswertung der resultierenden Tracelogs mit der vollständigen Version des Skripts auch das gleiche Ergebnis, das man erhalten würde, wenn man diese Auswertung über das Original-Tracelog hätte laufen lassen. Neben der kompakteren Darstellung im Hexeditor ist das vielleicht auch praktisch, wenn der Speicherplatz auf der Platte nicht für die Ablage vieler DGT-Dateien in Originalform reicht. (Ein solches DEBUG-Skript habe ich unten als CRUSHDGT.DEB angehängt. Es erwartet TRACELOG.DGT als Eingangsdatei und schreibt die zusammengestauchte Datei CRSHTRLG.DGT zurück auf die Platte. Nach Umbenennung der resultierenden Datei in TRACELOG.DGT verarbeitet DGT2LDMP.DEB diese Datei genauso wie die um Größenordnungen größere Original-TRACELOG.DGT-Datei. Wer die Quelldatei sowieso nicht behalten will, sondern nur noch die komprimierte Form, kann statt CRSHTRLG.DGT als Namen der Zieldatei auch den Namen der Quelldatei TRACELOG.DGT in CRUSHDGT.DEB angeben.)

Patcht man stattdessen in DGT2LDMP.DEB nur den Bereich +13Bh bis +158h des Skripts mit "F 13B 158 90" tot, so sampelt das Skript nur noch an der fallenden Flanke. Möchte man an der steigenden statt an der fallenden Flanke sampeln, so kann man den "jnz 15E" Befehl durch "jz 15E" ersetzen. Dazu braucht man einfach nur den Wert 75h an Offset +139h durch 74h ersetzen, z.B. indem man vor dem "G=100 183" ein "E 139 74" einfügt.

Wird stattdessen in DGT2LDMP.DEB der Bereich +13Fh bis +158h totgepatcht, so unterbleibt lediglich die Kompaktierung des Bitstroms in Bytes, d.h. jedes Byte im resultierenden Lensdump enthält nur den Wert 00h für Low oder 01h für High für den Kanal 2 (MISO), alle anderen Kanäle werden maskiert. Die Daten bleiben also als ein-Byte-pro-Flanke organisiert, so daß sich das zeitliche Verhalten leichter in einem Hex-Editor begutachten läßt, dafür ist die Auswertung des Dumps als Werte schwieriger als in der vollständigen Version des Skripts, das den kontinuierlichen Bitstrom in eine byteweise Darstellung übersetzt und so die übertragenen Daten als solche sichtbar macht.

Möchte man analog zu den MISO-Daten auch den Strom der SS- oder MOSI-Leitung aus dem Tracelog extrahieren, so reicht es dafür im Prinzip, den "shr al,1" Befehl an Offset +13Bh in "shr al,2" (für SS) bzw. "shr al,3" (für MOSI) zu ändern. Diese Befehle existieren aber erst ab dem 80188/80186-Prozessor. Ist auch Rückwärtskompatibilität mit dem 8088/8086 gewünscht, kann man "shr al,1" auch einfach verdoppeln bzw. verdreifachen. In jedem Fall wird die Sequenz dadurch zwischen 1 und 4 Bytes länger, so daß danach die Sprungbezüge angepaßt werden müssen.
(Der Einfachheit halber habe ich solche fertig vorbereitete Skripte als DGT3LDMP.DEB (für Kanal 3=SS) und DGT4LDMP.DEB (für Kanal 4=MOSI) angehängt. Diese erwarten TRACELOG.DGT als Eingangsdatei und schreiben LENSDMP3.BIN bzw. LENSDMP4.BIN auf die Platte zurück.)

Bei Bedarf ließe sich aus dem Skript mit wenig Aufwand ein richtiges kleines Progrämmchen stricken, das unabhängig von DEBUG ausgeführt werden kann und mit handlichen gut 150 Bytes Code schön kompakt ausfällt und selbst auf archaischen PCs rasend schnell arbeitet.

Erschöpfende Informationen zu den im Skript verwendeten DOS-API-Aufrufen des Interrupt 21h und den verwendeten Assemblerbefehlen finden sich in Ralf Browns Interruptliste (RBIL), der wohl besten Referenz zu dem Thema: http://www.cs.cmu.edu/~ralf/files.html Wer Fragen dazu hat, kann aber auch gerne hier fragen. Da ich DR-DOS mitentwickelt und auch lange und intensiv zu RBIL beigetragen habe, sitzt ihr hier sozusagen an einer der Quellen. ;-)

Hinweis: Ich konnte das Skript bisher nur "trocken" testen, da ich noch keine Digitrace-Tracelogs vorliegen habe. Derzeit findet keine Auswertung von SS als Triggerbedingung statt. Zu beachten ist, daß das erste relevante MISO-Bit jenes in zeitlichem Zusammenhang mit der ersten fallenden Flanke der Clock ist und nicht das erste, bei dem die Clock (schon vorher) low ist. Anhand der von Thomas eingestellten Grafiken erscheint mir das die richtige Voreinstellung für unseren Fall, falls nicht, würden die Bitsynchronisation nicht richtig arbeiten und man müßte noch ein paar kleinere Änderungen an dem Skript vornehmen.
EDIT: Inzwischen auch "live" getestet: Funktioniert problemlos.
EDIT: Neuere Fassungen dieser Skripte finden sich hier: http://www.mi-fo.de/forum/index.php?showto...st&p=260933

Viele Grüße,

Matthias

Ich spiele mich hier gerade mit meinem Zeroplus Logikanalysator herum, der auch das SPI-Protokoll dekodieren kann. (Der kleinste ist zum Beispiel hier günstig erhältlich)

Ich hab mal versucht, die Kommunikation zwischen einer Minolta 5000 und einem 35-105 zu belauschen. Zur Auswertung bin ich noch nicht gekommen, ab ich häng mal zwei Anhänge an, einmal mit den Daten und einmal ein Screenshot, wo man das Timing ausschnittsweise sieht.

Ich sags gleich, ich brauch noch ein bisschen Einarbeitungszeit, aber wenn besondere Wünsche bezüglich Auswertung da sind, immer her damit.

[attachment=7634:35_105_3...olta5000.JPG]

ZITAT(littlelamb @ 2010-04-24, 23:19) wenn besondere Wünsche bezüglich Auswertung da sind, immer her damit.[/quote]
Prima!

Aber wenn Du die Tabelle nicht im proprietären .XLS-Format, sondern als .CSV-Datei (Comma Separated Values) einstellen würdest, könnten bestimmt noch mehr Leute etwas damit anfangen. Nicht jeder arbeitet mit Microsoft Excel, wohingegen man Dateien im Austauschformat CSV mit wirklich jedem anderen Tabellenkalkulationsprogramm bearbeiten kann (auch mit ganz alten Programmen und unter anderen Betriebssystemen als Windows), und auch die automatische Auswertung mit Skripten wäre sehr viel einfacher.

Excel kann .CSV exportieren.

Viele Grüße,

Matthias

Ach so, vielleicht sollte ich noch ein paar Worte zur Ausführung von 16-Bit-Programmen wie DEBUG unter Windows verlieren:

DEBUG gehört nach wie vor zum Lieferumfang von Windows (sicher bis Windows XP, vermutlich auch bei Windows Vista und Windows 7). Auch die aktuellen Windows-Versionen (sicher bis Windows 7) können 16-Bit-Programme ausführen, es gibt lediglich zwei Ausnahmen:

- 64-Bit-Windows-Varianten unterstützen leider keine 16-Bit-Programme mehr. Dort müßte man auf ein alternatives DEBUG ausweichen und dieses in einem DOS-Emulator laufen lassen... Da bieten sich sowohl das DR-DOS DEBUG als auch das FreeDOS DEBUG an, die sowieso erheblich leistungsfähiger als das doch recht krude MS-DOS/PC DOS DEBUG sind, das (sonst) bei Windows beiliegt. Die von mir vorgestellten DEBUG-Skripte nutzen keine der erweiterten Fähigkeiten von DR-DOS oder FreeDOS DEBUG und laufen von daher gleichermaßen unter allen Varianten von DEBUG.

- 32-Bit-Windows-Versionen, bei denen im Januar 2010 das folgende "Workaround" für eine Sicherheitslücke eingespielt wurde:

http://www.heise.de/security/meldung/Windo...ate-908743.html

Dann sollte man die neusten Patches einspielen, denn inzwischen hat Microsoft einen echten Patch für das Problem veröffentlicht, weshalb die komplette Deaktivierung der VDM seit Februar 2010 nicht mehr angezeigt ist. Sofern man Adminrechte auf dem Rechner hat, kann man die Deaktivierung des 16-Bit-Subsystems mit folgendem Registry-Patch wieder rückgängig machen (REG-Datei speichern und ausführen):

VDMALLOW.REG:

Windows Registry Editor Version 5.00
 
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\AppCompat]
"VDMDisallowed"=dword:00000000
 

Viele Grüße,

Matthias

moin,

hier kommt die erste Version der Auswertung: [attachment=7638:3000i_mA...oo_122_1.zip]
Enthalten sind:
- dgtana.v05 = Auswerteprogramm, läuft unter linux/Unix/..., wenn sh&gawk vorhanden sind (Standard bei linux). Knoppix-Live-System von CD geht.
- 3000i_mAF24F28_mfoo_122-1.dgt = Sample-Datei von Digitrace, 1MByte entpackt. Ansehen ist mit Digitrace (File>Load) möglich!
- 3000i_mAF24F28_mfoo_122-1.uat = trace/debug-Datei von dgtana, enthält Zeitstempel usw, 41kByte entpackt.
- 3000i_mAF24F28_mfoo_122-1.uaa = die Auswertung... zur Ansicht unten auch im code-Block.

dgtana erwartet genau ein Argument, eine *.dgt-Datei. Diese kann mit Pfad angegeben werden, die Auswertung und der trace werden aber immer im lokalen Verzeichnis abgelegt.

Bitte unbedingt die 5-segmentige Benennung einhalten:

<body>_<lens>_<settings>_<granularity>-<lfn>.dgt mit
body = Kameraseitiges Gerät
lens = Objektivseitiges Gerät
settings = Einstellungen wie MF/AF, Brennweite bei Zoom, Fokusdistanz, Andrücken oder Auslösen, Fokusstop, Makroschalter usw.
granularity = Wert aus dem Lauf von Digitrace in 10ns-Einheiten (1.22 µs also als 122 OHNE Punkt)
KEINE Leerzeichen im Dateinamen (ist eine Unsitte, dafür ist der Unterstich da), Namen mit Leerzeichen fange ich im Programm nicht ab.

dgtana ist gawk (+ ein winziges Bisschen sh) und steht unter GPL v2only.
Eigentlich ist (g)awk für Stringverarbeitung, aber auch gut als rapid prototyper für ANSI-C (k-Kerningham, der von K&R-C ...).
Es müsste auch unter Win (in der Cygwin-Umgebung) laufen, allerdings könnte es Probleme geben, da ich ganz frech die Datei von 1MByte als eine Zeile einlese. Unter linux geht das...
Wer in den code hineinsieht, rauft sich die Haare. Ist grausam, unoptimiert und aus mehreren Teilen quick'n'dirty zusammengeflickt. Kann nur besser werden... deshalb v0.5!

so, hier das mAF24F28o als Analyse. Es wird der Ablauf beim Andrücken des Auslösers ohne Auslösen im MF-Modus gezeigt:

body=3000i lens=mAF24F28 settings=mfoo lfn=1
block 1
0x00: FF
0x00: 80 20 50 00 18 11 21 28 23 00 FB 41 F8 00 00 48 ED 88 00 00 00 00 00 00 00 00 00 00 00 00 3D 64
0x20:_00_00_00_00_00_00_00_00
block 2
0x29: FF
0x00: 80 20 50 00 18 11 21 28 23 00 FB 41 F8 00 00 48 ED_00_00_00_00_00_00_00_00
block 3
0x00:_67_75_00_00_00_00_00_00
block 4
0x4B: FF
0x00: 80 20 50 00 18 11 21 28 23 00 FB 41 F8 00 00 48 ED_00_00_00_00_00_00_00_00_65_6F_00_00_00_00_00
0x20:_00
 
analysis of the first 32 byte content block:
LensID (last2B): 25661
RomRevision    : 0x80/0
Anfangsöffnung : 2.83
Kleinste Blende: 22.63
Blendenoffset  : 0.00
Makrobit    (7): 0
Byte 0x04      : 0x18 00011000 24
Byte 0x05      : 0x11 00010001 17
Byte 0x06      : 0x21 00100001 33
Brennweite     : 24 mm (0x28)
Byte 0x08 p.unk: 0x23 00100011 35 partly unknown
MF-bit      (7): 0
MF2-bit?   (6): 0
Byte 0x09 p.unk: 0x00 0 0 partly unknown
AFStop-bit  (2): 0
Byte 0x0A p.unk: 0xFB 11111011 251 partly unknown
ROMlen-bit  (2): 0
noAFStop?  (0): 1
Byte 0x0B      : 0x41 01000001 65
Byte 0x0C      : 0xF8 11111000 248
Byte 0x0D      : 0x00 0 0
Byte 0x0E      : 0x00 0 0
Byte 0x0F      : 0x48 01001000 72
Byte 0x10      : 0xED 11101101 237
Byte 0x11      : 0x88 10001000 136
Byte 0x12      : 0x00 0 0
Byte 0x13      : 0x00 0 0
Byte 0x14      : 0x00 0 0
Byte 0x15      : 0x00 0 0
Byte 0x16      : 0x00 0 0
Byte 0x17      : 0x00 0 0
Byte 0x18      : 0x00 0 0
Byte 0x19      : 0x00 0 0
Byte 0x1A      : 0x00 0 0
Byte 0x1B      : 0x00 0 0
Byte 0x1C      : 0x00 0 0
Byte 0x1D      : 0x00 0 0
 

Die Unterstriche VOR den Bytes bedeuten, dass diese Byte übertragen wurde, während SS inaktiv war.

Hier findet ein Handshake statt. Im Ruhezustand ist SS inaktiv (high), MISO high und SCK low. Wenn die Kamera was zu sagen hat, zieht sie SS auf low (aktiv) und legt SCK an, der erste 8bit-Burst wird vom Objektiv mit Stillhalten = 0xFF quittiert. Daraufhin werden die Bytes durchgegeben, SS geht inaktiv (high) und die Kamera sendet 8 weitere 8bit-Bursts, das Objektiv hält solange MISO auf low =0x00. Dann hört SCK auf, bleibt low und MOSI geht ebenfalls high.
Wenn das Objektiv was loswerden möchte, signalisiert es dies, indem es MOSI auf low legt, ohne das SS aktiv ist oder SCK taktet. Die Kamera antwortet daraufhin mit Taktbursts. Die Objektive senden 2Byte, und die Kamera taktet noch 6 Leerbytes hinterher.

Wie ich gerade festgestellt habe, tritt der 4. Block nur beim Andrücken das Auslösers auf, wenn nicht ausgelöst wird. Wenn man durchdrückt (die Kamera steht auf MF!, gibt es einen kurzen MISO-drop von ca. 270µs Dauer ohne Datenübertragung (vor dem Auslösen?) und danach (?) bei SS inaktiv eine vom Objektiv veranlasste Übetragung von nur einem Byte ohne folgende Leer-Taktbursts. (Beim mAF2450F40o hier 0x2A richtigrum). Später folgt dann vom Objektiv angefordert ein 8Byte-Block ohne Inhalt, und dann ein normaler 18Byte-Block mit 8Byte-Leerquittung am Ende wie sonst als 4.Block.

Was ich noch nicht getestet habe, was bei der Erstinitialisierung passiert: durch Drücken der Objektiventriegelung wird die Spannung abgeschaltet und beim Loslassen wieder aktiviert und das Objektiv initialisiert.
Ebensowenig habe ich bisher im AF-Modus probiert, da die Kamera auf dem Rücken liegt und keinen Fokus an der weißen Decke findet.

Grade versehentlich getestet: je AFlock-Pieps wird der 4.Block wiederholt.

Ich wollte erstmal interessantere Objektive auslesen:

body=3000i lens=SAL16F28 settings=mfoo lfn=1
block 1
0x00: FF
0x00: 80 20 50 00 18 11 10 1E 21 00 FB 54 02 00 00 46 E8 89 00 00 00 00 00 00 00 00 00 00 00 00 B5 64
0x20:_00_00_00_00_00_00_00_00
block 2
0x29: FF
0x00: 80 20 50 00 18 11 10 1E 21 00 FB 54 02 00 00 46 E8_00_00_00_00_00_00_00_00
block 3
0x00:_55_54_00_00_00_00_00_00
block 4
0x4B: FF
0x00: 80 20 50 00 18 11 10 1E 21 00 FB 54 02 00 00 46 E8_00_00_00_00_00_00_00_00_55_53_00_00_00_00_00
0x20:_00
 
analysis of the first 32 byte content block:
LensID (last2B): 25781
RomRevision    : 0x80/0
Anfangsöffnung : 2.83
Kleinste Blende: 22.63
Blendenoffset  : 0.00
Makrobit    (7): 0
Byte 0x04      : 0x18 00011000 24
Byte 0x05      : 0x11 00010001 17
Byte 0x06      : 0x10 00010000 16
Brennweite     : 15 mm (0x1E)
Byte 0x08 p.unk: 0x21 00100001 33 partly unknown
MF-bit      (7): 0
MF2-bit?   (6): 0
Byte 0x09 p.unk: 0x00 0 0 partly unknown
AFStop-bit  (2): 0
Byte 0x0A p.unk: 0xFB 11111011 251 partly unknown
ROMlen-bit  (2): 0
noAFStop?  (0): 1
Byte 0x0B      : 0x54 01010100 84
Byte 0x0C      : 0x02 00000010 2
Byte 0x0D      : 0x00 0 0
Byte 0x0E      : 0x00 0 0
Byte 0x0F      : 0x46 01000110 70
Byte 0x10      : 0xE8 11101000 232
Byte 0x11      : 0x89 10001001 137 (Rest 0x00 weggelassen)
 

offensichtlich ist die Brennweitenformel noch nicht perfekt.

body=3000i lens=SAL500R80 settings=mfoo+ lfn=1
block 1
0x00: FF
0x00: 81 37 37 00 34 11 2F 6D 35 00 F9 1A 20 00 04 00 00 ED 20 F4 4C 00 00 2B C3 BD 00 00 F8 00 79 64
0x20:_00_00_00_00_00_00_00_00
block 2
0x29: FF
0x00: 81 37 37 00 34 11 2F 6D 35 00 F9 1A 20 00 04 00 00_00_00_00_00_00_00_00_00
block 3
0x00:_58_63_00_00_00_00_00_00
block 4
0x4B: FF
0x00: 81 37 37 00 34 11 2F 6D 35 00 F9 1A 20 00 04 00 00_00_00_00_00_00_00_00_00_57_60_00_00_00_00_00
0x20:_00
 
analysis of the first 32 byte content block:
LensID (last2B): 25721
RomRevision    : 0x81/0
Anfangsöffnung : 7.66
Kleinste Blende: 7.66
Blendenoffset  : 0.00
Makrobit    (7): 0
Byte 0x04      : 0x34 00110100 52
Byte 0x05      : 0x11 00010001 17
Byte 0x06      : 0x2F 00101111 47
Brennweite     : 512 mm (0x6D)
Byte 0x08 p.unk: 0x35 00110101 53 partly unknown
MF-bit      (7): 0
MF2-bit?   (6): 0
Byte 0x09 p.unk: 0x00 0 0 partly unknown
AFStop-bit  (2): 0
Byte 0x0A p.unk: 0xF9 11111001 249 partly unknown
ROMlen-bit  (2): 0
noAFStop?  (0): 1
Byte 0x0B      : 0x1A 00011010 26
Byte 0x0C      : 0x20 00100000 32
Byte 0x0D      : 0x00 0 0
Byte 0x0E      : 0x04 00000100 4
Byte 0x0F      : 0x00 0 0
Byte 0x10      : 0x00 0 0
Byte 0x11      : 0xED 11101101 237
Byte 0x12      : 0x20 00100000 32
Byte 0x13      : 0xF4 11110100 244
Byte 0x14      : 0x4C 01001100 76
Byte 0x15      : 0x00 0 0
Byte 0x16      : 0x00 0 0
Byte 0x17      : 0x2B 00101011 43
Byte 0x18      : 0xC3 11000011 195
Byte 0x19      : 0xBD 10111101 189
Byte 0x1A      : 0x00 0 0
Byte 0x1B      : 0x00 0 0
Byte 0x1C      : 0xF8 11111000 248
Byte 0x1D      : 0x00 0 0
 

auch das Spiegelchen liegt brennweitenmäßig leicht daneben und hat wie das 200/2.8APO ein 0x81/32-Rom (wobei, gibt es die 0x81/45Byte wirklich?).

body=3000i lens=SAL135S28 settings=mf45oo lfn=1
block 1
0x00: FF
0x00: 81 2C 2C 00 18 11 0E 4F 58 80 04 00 00 DA 00 00 00 00 00 00 00 00 00 26 2F 8B 00 00 53 00 DF B2
0x20:_00_00_00_00_00_00_00_00
block 2
0x29: FF
0x00: 81 2C 2C 00 18 11 0E 4F 58 80 04 00 00 DA 00 00 00_00_00_00_00_00_00_00_00
block 3
0x00:_63_76_00_00_00_00_00_00
block 4
0x4B: FF
0x00: 81 2C 2C 00 18 11 0E 4F 58 80 04 00 00 DA 00 00 00_00_00_00_00_00_00_00_00_60_71_00_00_00_00_00
0x20:_00
 
analysis of the first 32 byte content block:
LensID (last2B): 45791
RomRevision    : 0x81/0
Anfangsöffnung : 4.76
Kleinste Blende: 4.76
Blendenoffset  : 0.00
Makrobit    (7): 0
Byte 0x04      : 0x18 00011000 24
Byte 0x05      : 0x11 00010001 17
Byte 0x06      : 0x0E 00001110 14
Brennweite     : 135 mm (0x4F)
Byte 0x08 p.unk: 0x58 01011000 88 partly unknown
MF-bit      (7): 0
MF2-bit?   (6): 1
Byte 0x09 p.unk: 0x80 10000000 128 partly unknown
AFStop-bit  (2): 0
Byte 0x0A p.unk: 0x04 00000100 4 partly unknown
ROMlen-bit  (2): 1
noAFStop?  (0): 0
Byte 0x0B      : 0x00 0 0
Byte 0x0C      : 0x00 0 0
Byte 0x0D      : 0xDA 11011010 218
Byte 0x0E      : 0x00 0 0
Byte 0x0F      : 0x00 0 0
Byte 0x10      : 0x00 0 0
Byte 0x11      : 0x00 0 0
Byte 0x12      : 0x00 0 0
Byte 0x13      : 0x00 0 0
Byte 0x14      : 0x00 0 0
Byte 0x15      : 0x00 0 0
Byte 0x16      : 0x00 0 0
Byte 0x17      : 0x26 00100110 38
Byte 0x18      : 0x2F 00101111 47
Byte 0x19      : 0x8B 10001011 139
Byte 0x1A      : 0x00 0 0
Byte 0x1B      : 0x00 0 0
Byte 0x1C      : 0x53 01010011 83
Byte 0x1D      : 0x00 0 0
 

Überraschung... Das STF sollte doch die LensID 20 haben?

body=3000i lens=SAL70300F4556G settings=mf70oo+ lfn=1
block 1
0x00: FF
0x00: 81 2B 50 00 23 00 00 40 31 00 FE 66 FE 00 00 64 00 DB 00 33 51 F8 ED 26 5B 25 20 00 E5 00 11 B3
0x20:_00_00_00_00_00_00_00 E0
block 2
0x00: 3F 70 05 0A 60 04 00 00 28 06 C0 DF CC 1F 00 80 0C_00_00_00_00_00_00_00_00_E0
block 3
0x00:_35_06_00_00_00_00_00 F0
block 4
0x00: 1F B8 02 05 30 02 00 00 14 03 E0 6F E6 0F 00 40 06_00_00_00_00_00_00_00_00_E0_45_06_00_00_00_00
0x20:_00 00
 
analysis of the first 32 byte content block:
LensID (last2B): 45841
RomRevision    : 0x81/0
Anfangsöffnung : 4.56
Kleinste Blende: 22.63
Blendenoffset  : 0.00
Makrobit    (7): 0
Byte 0x04      : 0x23 00100011 35
Byte 0x05      : 0x00 0 0
Byte 0x06      : 0x00 0 0
Brennweite     : 69 mm (0x40)
Byte 0x08 p.unk: 0x31 00110001 49 partly unknown
MF-bit      (7): 0
MF2-bit?   (6): 0
Byte 0x09 p.unk: 0x00 0 0 partly unknown
AFStop-bit  (2): 0
Byte 0x0A p.unk: 0xFE 11111110 254 partly unknown
ROMlen-bit  (2): 1
noAFStop?  (0): 0
Byte 0x0B      : 0x66 01100110 102
Byte 0x0C      : 0xFE 11111110 254
Byte 0x0D      : 0x00 0 0
Byte 0x0E      : 0x00 0 0
Byte 0x0F      : 0x64 01100100 100
Byte 0x10      : 0x00 0 0
Byte 0x11      : 0xDB 11011011 219
Byte 0x12      : 0x00 0 0
Byte 0x13      : 0x33 00110011 51
Byte 0x14      : 0x51 01010001 81
Byte 0x15      : 0xF8 11111000 248
Byte 0x16      : 0xED 11101101 237
Byte 0x17      : 0x26 00100110 38
Byte 0x18      : 0x5B 01011011 91
Byte 0x19      : 0x25 00100101 37
Byte 0x1A      : 0x20 00100000 32
Byte 0x1B      : 0x00 0 0
Byte 0x1C      : 0xE5 11100101 229
Byte 0x1D      : 0x00 0 0
 

und das erste SSM. Leider habe ich hier Probleme, in den Handshake-Blöcken fehlen bits. Die ersten 33 Byte sind aber korrekt, der Rest Müll infolge verschobenem Leserasters. Bei mehrfachen Messungen traten die Fehler an verschiedenen Stellen auf, das kläre ich heute Abend nicht mehr. Auch hier stimmt die LensID nicht mit der bekannten überein...

Alle bisher getesteten Objektive verhalten sich an der 3000i absolut identisch, was das Timing und die Blocklänge beim Andrücken des Auslösers betrifft.

schluss für heute, gruesze, thomas

ZITAT(ddd @ 2010-04-25, 2:32)

body=3000i lens=SAL135S28 settings=mf45oo lfn=1
block 1
0x00: FF
0x00: 81 2C 2C 00 18 11 0E 4F 58 80 04 00 00 DA 00 00 00 00 00 00 00 00 00 26 2F 8B 00 00 53 00 DF B2
0x20:_00_00_00_00_00_00_00_00
block 2
0x29: FF
0x00: 81 2C 2C 00 18 11 0E 4F 58 80 04 00 00 DA 00 00 00_00_00_00_00_00_00_00_00
block 3
0x00:_63_76_00_00_00_00_00_00
block 4
0x4B: FF
0x00: 81 2C 2C 00 18 11 0E 4F 58 80 04 00 00 DA 00 00 00_00_00_00_00_00_00_00_00_60_71_00_00_00_00_00
0x20:_00
 
analysis of the first 32 byte content block:
LensID (last2B): 45791
[...]
 

Überraschung... Das STF sollte doch die LensID 20 haben?[/quote]
Ja, laut dieser Liste hier schon:

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

Diese IDs stammen aber aus den Exif-Daten.

Hier im Forum wurde die 20 zweimal für die Sony-Version des Objektivs berichtet:

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

Möglicherweise wurden unterschiedliche IDs verwendet, oder die Lens-IDs in den Exif-Daten sind nicht immer mit den IDs in den Objektiven identisch...

Viele Grüße,

Matthias

So, jetzt habe ich auch eine Minolta 8000i im Dienste der Wissenschaft "geopfert"

Im Anhang ein Trace mit dem selben Objektiv (35-105) wie in meinem vorigen Posting.

Diesmal der Trace als CSV -File, vielleicht ist es jemanden eine Hilfe.

Wenn von einem bestimmten Objektiv ein Trace gewünscht wird, bitte sagen, ich habe einige in meinem Schrank.

Lg
Hans

ZITAT(ddd @ 2010-04-25, 2:32) - 3000i_mAF24F28_mfoo_122-1.dgt = Sample-Datei von Digitrace, 1MByte entpackt. Ansehen ist mit Digitrace (File>Load) möglich![/quote]
Herzlichen Dank, Thomas! Damit konnte ich das DGT2LDMP.DEB-Skript nun ebenfalls überprüfen; es liefert - wie erwartet und trotzdem zum Glück - das gleiche Ergebnis (nur ohne die anschließende Interpretation der Daten). Die resultierende LENSDUMP.BIN-Datei enthält bei diesem Objektiv 109 Bytes (alle Blöcke zusammen) und mit dem Skript SHOW109.DEB kann man sich das Ganze auch blockweise ausgeben lassen.

SHOW109.DEB:

N LENSDUMP.BIN
L 0
D 0 L 1
D 1 L 20
D 21 L 8
D 29 L 1
D 2A L 11
D 3B L 8
D 43 L 8
D 4B L 1
D 4C L 11
D 5D L 10
Q
Q
 

Aufruf (das oben von DGT2LDMP.DEB erzeugte LENSDUMP.BIN muß im aktuellen Verzeichnis liegen):

DEBUG < SHOW109.DEB

Ausgabe von MS-DOS/PC DOS/Windows DEBUG (mit kleinen kosmetischen Änderungen durch mich):

-N LENSDUMP.BIN
-L 0
-D 0 L 1
xxxx:0000  FF
-D 1 L 20
xxxx:0000     80 20 50 00 18 11 21-28 23 00 FB 41 F8 00 00
xxxx:0010  48 ED 88 00 00 00 00 00-00 00 00 00 00 00 00 3D
xxxx:0020  64
-D 21 L 8
xxxx:0020     00 00 00 00 00 00 00-00
-D 29 L 1
xxxx:0020                             FF
-D 2A L 11
xxxx:0020                                80 20 50 00 18 11
xxxx:0030  21 28 23 00 FB 41 F8 00-00 48 ED
-D 3B L 8
xxxx:0030                                   00 00 00 00 00
xxxx:0040  00 00 00
-D 43 L 8
xxxx:0040           67 75 00 00 00-00 00 00
-D 4B L 1
xxxx:0040                                   FF
-D 4C L 11
xxxx:0040                                      80 20 50 00
xxxx:0050  18 11 21 28 23 00 FB 41-F8 00 00 48 ED
-D 5D L 10
xxxx:0050                                         00 00 00
xxxx:0060  00 00 00 00 00 65 6F 00-00 00 00 00 00
-Q
 

Diese Anzeige läßt sich bei Bedarf mit "/X", "D=0" auch bei DR-DOS DEBUG forcieren, defaultmäßig ist sie aber etwas übersichtlicher:

-N LENSDUMP.BIN
-L 0
Read 0000006D bytes from LENSDUMP.BIN to address xxxx:0000
-D 0 L 1
xxxx:0000  FF
-D 1 L 20
xxxx:0001  80 20 50 00 18 11 21 28-23 00 FB 41 F8 00 00 48
xxxx:0011  ED 88 00 00 00 00 00 00-00 00 00 00 00 00 3D 64
-D 21 L 8
xxxx:0021  00 00 00 00 00 00 00 00
-D 29 L 1
xxxx:0029  FF
-D 2A L 11
xxxx:002A  80 20 50 00 18 11 21 28-23 00 FB 41 F8 00 00 48
xxxx:003A  ED
-D 3B L 8
xxxx:003B  00 00 00 00 00 00 00 00
-D 43 L 8
xxxx:0043  67 75 00 00 00 00 00 00
-D 4B L 1
xxxx:004B  FF
-D 4C L 11
xxxx:004C  80 20 50 00 18 11 21 28-23 00 FB 41 F8 00 00 48
xxxx:005C  ED
-D 5D L 10
xxxx:005D  00 00 00 00 00 00 00 00-65 6F 00 00 00 00 00 00
-Q
 

Diese beiden Dumps beziehen sich auf das Minolta AF 2,8/24mm (1. Generation, vgl. auch: http://www.mi-fo.de/forum/index.php?showto...st&p=260173), ausgelesen an der Minolta Dynax 3000i.

Neben LENSDUMP.BIN, das die MISO-Daten enthält, sind unten auch die Dateien LENSDMP3.BIN und LENSDMP4.BIN mit dem SS- und dem MOSI-Bitstrom angehängt. Stellt man die Inhalte mit SHOW109.DEB gegenüber, kann man leicht sehen, ob SHOW109.DEB die Blöcke an den richtigen Stellen trennt.

Um die drei Datenströme gemeinsam zu betrachten, verschachtele ich die Ausgaben mal ineinander (2=MISO, 3=SS, 4=MOSI):

0000@2  FF
0000@3  00
0000@4  FF
 
0001@2  80 20 50 00 18 11 21 28-23 00 FB 41 F8 00 00 48-ED 88 00 00 00 00 00 00-00 00 00 00 00 00 3D 64
0001@3  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
0001@4  FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
 
0021@2  00 00 00 00 00 00 00 00
0021@3  FF FF FF FF FF FF FF FF
0021@4  FF FF FF FF FF FF FF FF
 
0029@2  FF
0029@3  00
0029@4  FF
 
002A@2  80 20 50 00 18 11 21 28-23 00 FB 41 F8 00 00 48
002A@3  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
002A@4  FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
 
003A@2  ED
003A@3  00
003A@4  FF
 
003B@2  00 00 00 00 00 00 00 00
003B@3  FF FF FF FF FF FF FF FF
003B@4  FF FF FF FF FF FF FF FF
 
0043@2  67 75 00 00 00 00 00 00
0043@3  FF FF FF FF FF FF FF FF
0043@4  FF FF FF FF FF FF FF FF
 
004B@2  FF
004B@3  00
004B@4  FF
 
004C@2  80 20 50 00 18 11 21 28-23 00 FB 41 F8 00 00 48
004C@3  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
004C@4  FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
 
005C@2  ED
005C@3  00
005C@4  FF
 
005D@2  00 00 00 00 00 00 00 00-65 6F 00 00 00 00 00 00
005D@3  FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
005D@4  FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
 

Viele Grüße,

Matthias

moin,

die Auslesefehler beim SSM lagen vmtl. am parallel im Hintergrund laufenden MSwindoof-Update-Download. Ich werde das nochmal wiederholen, dann kann ich mehr dazu sagen. Es fehlten Taktsignale, kann also nicht an zu niedrigen Signalpegeln des Objektiv-Mikrokontrollers liegen. Die Bytes nach dem Aussetzer sahen wie erwartet aus, d.h. die 18Byte-Blöcke sind identisch mit den ersten 18Byte des 1. 33Byte-Blocks.

Matthias, ich hätte früher darauf kommen dürfen, dass die *.dgt-Sample-logs gut komprimierbar sind und dann sehr wohl hier als Anhang gepostet werden können. Manchmal denkt man nicht an das Naheliegende.
109 Bytes habe ich auch, dabei werden alle 0xFF und die 0x00 bei SS inaktiv mitgezählt, es ist also die Anzahl der 8bit-SCK-Bursts, welche ja offensichtlich die Bytes darstellen.

Die unerwarteten LensIDs von STF und 70300G können sehr wohl daran liegen, dass diese Objektive 45Byte-Datensätze liefern würden, wenn die Kamera diese denn anfordern würde.
Entweder wird das nur im AF-Modus angefordert (werde ich noch testen) oder die 3000i ist zu dämlich.
Die 3000i ist eine selten dumme Kamera: sie hat genau 3 Bedienelemente ausser dem Power-Schalter (incl. BattInsSwitch), dem 2stufigen Auslöser und der Objektiventriegelungstaste. Und zwar die P-Taste zum Umschalten zwischen P-Modus und P-highspeed-Modus, der Selbstauslöser-Taste, fest 10s Vorlauf und dem Umschalter AF-MF. Das wars. Keine Blendensteuerung, keine Zeitsteuerung, nix. Eigentlich eine Ritsch-Ratsch mit Wechselobjektiv und Spiegelsucher.
Daher kann es gut sein, dass dieses Super-Spar-Modell einfach nur einen Teil des Protokolls implementiert.

Die LensIDs machen auf mich mittlerweile den Eindruck, dass sie mehr als LensChip-ID-Nr. für Debug-Zwecke vorhanden sind. Die Tatsache, dass mehrere Objektive denselben LensChip benutzen und mglw. bei Entwicklungs-Geräten nicht fest verlötet, sondern umgeschaltet werden können, deutet darauf hin wie auch die Tatsache, dass die LensID nach bisherigen Erkenntnissen immer die letzten zwei Byte belegt und nicht an einer festen Stelle im Datensatz steht. Zum Zeitpunkt der Entwicklung wurde diese Info sicher nur für interne Zwecke benötigt, dass es einmal als Anker für die Objektivbezeichnung in EXIF-Daten verwendet würde, konnte keiner ahnen.

Interessant auch die belegten Bytes beim STF nach Byte 0x12. Ich nahm bisher an, dass dort nur noch AF-Parameter folgen. Das STF hat aber sicher keine AF-Parameter...
Also sind die Bytes 0x17, 0x18, 0x19 und 0x1C keine AF-Parameter. Doch AE-Steuerung? Andere Ideen?
Auch ist nicht bit7 von Byte 0x08 als MFbit gesetzt, sondern bit6. Dass bit6 ebenfalls den AFconfirm abschaltet war ja bereits bekannt.

Die bisher mithilfe von PonyProg u.ä. Methoden ermittelten Daten sind zumindest bezüglich der ersten 32/33Byte (ohne/mit 0xFF am Anfang) korrekt, also weiter verwendbar. Aber sie zeigen nur einen Teil der Wahrheit.

Hans@littlelamb:
Schön, dass ein weiterer Bastler mit anderen Methoden darauf losgeht, das sicher die Ergebnisse besser ab.
Deine logs schaue ich mir noch an.
Ich kann Dir aber schon versprechen, dass der SPI-Interpreter-Modus nicht viel hilft, da das Objektivprotokoll nur SPI-artig ist, aber eben kein SPI. Schon die bitorder ist falschrum, und das ein Slave MISO toggelt wenn er nicht mittels SS selektiert ist, ist klar unvereinbar mit SPI.

@matthias: ja, mit Assembler geht die bit-Pfriemelei viel einfacher. awk ist dafür ungeeignet, in C ist das dann auch easy.
Für mich ist x86-asm furchtbar ungewohnt, 68k u.ä. kenne ich wesentlich besser.
Auch hier gilt: zwei verschiedene Methoden mit gleichem Ergebnis sichern dieses besser ab.

Dass das awk-proggi so lahm ist, liegt übrigens an dem riesigen Array, das ich beim Komprimieren der logs verwende. Ich suche genau wie Matthias' asm-Script nach den fallenden Takt-Flanken und lese daraus das bit. Da ich drei verschiedene proggis zusammengeflickt habe, wird furchtbar umständlich erst die falsche bitorder eingelesen und dann umgewandelt und so weiter. Erstmal kommt was sinnvolles raus...

so, jetzt muss das gute Wetter genutzt und ein längerer Spaziergang gemacht werden!

gruesze, thomas

ZITAT(littlelamb @ 2010-04-25, 13:54) So, jetzt habe ich auch eine Minolta 8000i im Dienste der Wissenschaft "geopfert"

Im Anhang ein Trace mit dem selben Objektiv (35-105) wie in meinem vorigen Posting.

Diesmal der Trace als CSV -File, vielleicht ist es jemanden eine Hilfe.

Wenn von einem bestimmten Objektiv ein Trace gewünscht wird, bitte sagen, ich habe einige in meinem Schrank.[/quote]
Ich habe Deine Zeroplus-CSV-Datei mal mit einem (sehr kruden und langsamen) Batchjob namens CSV2LDMP.BAT in ein Lensdump konvertiert. CSV2LDMP.BAT erwartet TRACELOG.CSV im aktuellen Verzeichnis und benötigt in der derzeitigen Fassung einen Kommandozeilenprozessor, der den FOR /F Befehl unterstützt - unter DOS und Windows 95/98/SE/ME geht das nur mit 4DOS statt COMMAND, unter Windows NT/2000/XP/Vista/7 tut's CMD, 4NT/TC und neuerdings auch COMMAND. Außerdem wird auch noch DEBUG benötigt, und der SwitChar muß auf "/" eingestellt sein (aber der ist sowieso nur unter DR-DOS, FreeDOS und ganz alten Versionen von MS-DOS einstellbar). (Mit 4DOS/4NT/TC und unter DR-DOS ginge das alles auch viel komfortabler, aber das möchte ich hier nicht voraussetzen.) Das Skript ist nicht robust in Bezug auf größere Veränderungen der Struktur der in der CSV-Datei abgelegten Daten. Sollte sich die Struktur mal ändern, wären in jedem Fall Anpassungen notwendig.

CSV2LDMP.BAT:
ZITAT@ECHO off
REM R1.04 2010-04-30 MPL
IF "$SELF$"=="%1" GOTO process
IF NOT "Windows_NT"=="%OS%" IF NOT "4"=="%@Exec[2+2]%" GOTO error
SET FILECSV=TRACELOG.CSV
IF NOT ""=="%1" SET FILECSV=%1
IF NOT EXIST %FILECSV% GOTO nofile
SET FILELDMP=LENSDUMP.BIN
IF NOT ""=="%2" SET FILELDMP=%2
IF EXIST %FILELDMP% DEL %FILELDMP% > NUL
IF EXIST LENSDUMP.NEW DEL LENSDUMP.NEW > NUL
FOR /F "eol=/ tokens=3* delims=,;" %%I IN (%FILECSV%) DO %COMSPEC% /C %0 $SELF$ %%~I %%~J
SET FILECSV=
SET FILELDMP=
GOTO eof
rocess
IF NOT ""=="%3" SHIFT
IF ""=="%2" GOTO eof
IF "TimeStamp"=="%2" GOTO eof
IF "DATA"=="%2" GOTO eof
ECHO Processing "%2"...
ECHO E 100 %2 > CSV2LDMP.DEB
ECHO Rcx >> CSV2LDMP.DEB
ECHO 1 >> CSV2LDMP.DEB
ECHO N LENSDUMP.CHR >> CSV2LDMP.DEB
ECHO W >> CSV2LDMP.DEB
ECHO Q >> CSV2LDMP.DEB
@CALL DEBUG < CSV2LDMP.DEB > NUL
DEL CSV2LDMP.DEB > NUL
IF NOT EXIST LENSDUMP.CHR GOTO eof
IF NOT EXIST %FILELDMP% GOTO init
COPY /B %FILELDMP%+LENSDUMP.CHR LENSDUMP.NEW > NUL
DEL LENSDUMP.CHR > NUL
DEL %FILELDMP% > NUL
REN LENSDUMP.NEW %FILELDMP% > NUL
GOTO eof
:init
REN LENSDUMP.CHR %FILELDMP% > NUL
GOTO eof
:error
ECHO Wrong command line processor
GOTO eof
:nofile
ECHO Missing source file %FILECSV%
SET FILECSV=
:eof
REM (Just to work around a parsing bug in an older issue of MS-DOS COMMAND.COM.)
REM[/quote]
(Hinweis: Die aktualisierte Fassung des Skripts akzeptiert jetzt die Angabe von Quell- und Zieldatei als Aufrufparameter. Dateinamen mit Leerzeichen müssen mit doppelten Hochkommata eingeklammert werden - generell sowieso eine schlechte Idee, Leerzeichen in Dateinamen zu verwenden! Das Skript kommt nun auch mit Zeroplus-CSV-Dateien zurecht, die auf dem Umweg über OpenOffice erzeugt wurden, ebenso wie mit diversen Zeroplus-CSV-Unterformaten, die keine Spalte "Name" enthalten oder die vorne einen Kommentarblock enthalten.)

Aufruf am Prompt ohne Parameter:

CSV2LDMP

Hier der Inhalt der daraus resultierenden LENSDUMP.BIN Datei für das Minolta AF Zoom 3,5-4,5/35-105mm New, ausgelesen mit der Minolta Dynax 8000i.
EDIT: Dump gelöscht, da schon im Original fehlerbehaftet und das hier keine Verwirrung stiften soll. Korrekte Dumps finden sich weiter unten in diesem Thread.

Welches Objektiv war das genau, das Minolta AF Zoom 3,5-4,5/35-105mm oder das Minolta AF Zoom 3,5-4,5/35-105m New? Bitte möglichst genau bei den Bezeichnungen sein, da es hier Unterschiede im Details geben kann (die wir ja gerade herausfinden wollen).
EDIT: Es war die "New"-Variante, siehe: http://www.mi-fo.de/forum/index.php?showto...st&p=260713

Es wäre übrigens sehr interesssant, die Daten des gleichen Objektivs auch mit der Minolta 5000 AF als CSV auszulesen und mit denen an der Dynax 8000i gegenüberzustellen.

EDIT: Hier unter Vorbehalt das Dump von Hans' Minolta AF Zoom 3,5-4,5/35-105mm New an der Minolta 5000 AF (Achtung: Mit vielen Lesefehlern!):
EDIT: Dump gelöscht, da schon im Original fehlerbehaftet und das hier keine Verwirrung stiften soll. Korrekte Dumps finden sich weiter unten in diesem Thread.

Viele Grüße,

Matthias

moin,

eine D5 ist im Zulauf, dann wird es besser:
Denn ich kann jetzt sicher sagen, dass die i-Serie, und damit fast sicher auch die AF-Serie, nur die ersten 32 Byte lesen kann.

Ich habe jetzt mal während der Init-Prozedur ausgelesen. Ursprünglich dachte ich, geht nicht, da das Eindrehen zu lange dauert.
Aber die Idee, Drücken der Objektiventriegelung, ist korrekt und funktioniert.

Die 3000i in Stellung MF liest dann nur 33 Byte ein, weiter passiert nix! Keine Taktzyklen ohne SS oder sonstige Sachen.
Die 3000i in Stellung AF liest ebenfalls 33 Byte, und nach ca. 0,5s nocheinmal 18 Byte; ebenfalls ohne Taktzyklen ohne SS.

Das erste Byte jeden "Normalblockes" ist 0xFF, dies zählen wir beim Inhalt nicht mit.
Die Bytes 18..32 (0x11..0x1F) ändern sich also während des Betriebes nicht bzw. die 3000i interessiert es nicht, sie werden nur einmal eingelesen:
beim Einschalten, Objektivwechseln/Drücken der Entriegelung und beim Andrücken des Auslösers, wenn die aktiv-Zeit abgelaufen ist.
Sonst wird nur ein 18 Byte-Block gelesen, welcher nur die offenbar als variabel eingestuften Bytes 1-17 (0x00..0x10) enthält.

Es ist mir nicht gelungen, die möglicherweise längeren Datensätze aus dem SAL-STF oder 70300G-SSM oder SAL1870DT mit der 3000i zu lesen.

body=3000i lens=SAL1870F3556 settings=initmf18oo lfn=1
block 1
0x00: FF
0x00: 81 26 50 00 1F 0F 10 21 31 80 FF 57 14 00 04 4B 00 93 1C F6 33 F4 EF 25 0B 2A 20 00 A5 00 11 B3
 
analysis of the first 32 byte content block:
LensID (last2B): 45841
RomRevision    : 0x81/0
Anfangsöffnung : 3.67
Kleinste Blende: 22.63
Blendenoffset  : 0.00
Makrobit    (7): 0
Byte 0x04      : 0x1F 00011111 31
Byte 0x05      : 0x0F 00001111 15
Byte 0x06      : 0x10 00010000 16
Brennweite     : 17 mm (0x21)
Byte 0x08 p.unk: 0x31 00110001 49 partly unknown
MF-bit      (7): 0
MF2-bit?   (6): 0
Byte 0x09 p.unk: 0x80 10000000 128 partly unknown
AFStop-bit  (2): 0
Byte 0x0A p.unk: 0xFF 11111111 255 partly unknown
ROMlen-bit  (2): 1
noAFStop?  (0): 1
Byte 0x0B      : 0x57 01010111 87
Byte 0x0C      : 0x14 00010100 20
Byte 0x0D      : 0x00 0 0
Byte 0x0E      : 0x04 00000100 4
Byte 0x0F      : 0x4B 01001011 75
Byte 0x10      : 0x00 0 0
Byte 0x11      : 0x93 10010011 147
Byte 0x12      : 0x1C 00011100 28
Byte 0x13      : 0xF6 11110110 246
Byte 0x14      : 0x33 00110011 51
Byte 0x15      : 0xF4 11110100 244
Byte 0x16      : 0xEF 11101111 239
Byte 0x17      : 0x25 00100101 37
Byte 0x18      : 0x0B 00001011 11
Byte 0x19      : 0x2A 00101010 42
Byte 0x1A      : 0x20 00100000 32
Byte 0x1B      : 0x00 0 0
Byte 0x1C      : 0xA5 10100101 165
Byte 0x1D      : 0x00 0 0
 

die hier genannte LensID 45841 ist Quatsch, denn das SAL70300G hat dort dieselbe bit-Folge stehen.

@Matthias, nimm den Vermerk im LensID-thread wieder raus bzw. kommentiere ihn, es ist schlicht falsch.

Mittlerweile bekommen wir jedenfalls einen immer besseren Überblick, was wie funktioniert. Nur komme ich mit der 3000i nicht mehr wirklich weiter.

Zu littlelambs SampleLogs:
ich habe mal Matthias' Analyse etwas anders umgebrochen:

8000i_mAF35105F3545n LensID 25858 = 0x6502 byteorder 02 65
FF 81 26 40 01 1E 21 11 33 23 00 F3 4C F9 00 06 5E 00 AD 01 F0 33 02 E7 20 08 24 00 00 BF 00 00 65
FF 81 26 40 01 1E 21 01 23 3B 00 FB 5C F9 00 06 5E 00 8C 01 F0 33 02 C6 00 4A 24 00 00 BF 00 00 67
FF 81 26 40 00 1E 00 10 32 0B 00 FB 0C F9 00 04 1C 00 AF 01 F1 33 02 E7 20 42 2C 00 00 BF 00 02 65
FF 01 26 50 01 1E 21 11 33 23 00 F3 4C F1 00 06 5E 00 AD 01 E1 23 02 E7 00
FF 81 26 50 00 1E 00 10 32 0B 00 FB 0C F9 00 04 1C 00 AF 01 F1 33 02 E7 20 42 2C 00 00 BF 00 02 65
FF 81 06 50 00 1E 00 10 32 0A 00 FA 0C F9 00 04 1C 00 AF 01 F3 33 00 E7 20
FF 81 26 40 03 1C 21 11 33 2B 00 FB 48 F9 00 06 5E 00 29 01 E1 23 02 E7 20 5A 24 00 00 BE 00 02 44
FF 81 24 10 01 1C 63 13 33 2B 00 FB 48 F9 00 06 5E 00 29 01 F1 33 02 E7 20
FF 81 06 70 01 1E 21 11 33 23 00 F3 4C F1 00 06 5E 00 AD 01 F0 33 02 C6 00 4A 04 00 00 BF 00 00 65
FF 81 26 40 01 1E 21 01 23 0A 00 FA 4C F8 00 06 5E 00 8C 01 F1 33 02 E7 20
FF 83 24 10 01 1E 21 01 23 2B 00 FB 4C F9 00 06 5E 00 8C 01 F3 33 00 E7 20 08 20 00 00 3F 00 02 61
FF 81 26 40 01 1E 21 00 22 0A 00 FA 4C F8 01 06 5E 00 AD 01 E1 23 02 E7 20
FF 01 26 50 00 1E 00 10 32 0A 00 FA 4C F9 00 04 1C 00 AD 01 F1 37 06 E7 20 42 24 00 00 BF 00 02 6D
FF 01 26 D0 01 1E 21 11 33 2B 00 FB C8 F9 00 06 5E 00 29 01 F1 33 02 E7 20
FF 81 26 50 00 1E 21 11 33 2B 00 FB 0C FB 00 04 1C 00 29 01 F1 33 02 E7 20 42 2C 00 00 BF 00 02 65
 

edit: N-Version von Hans bestätigt.
das sieht für mich nach einer recht hohen Zahl an Lesefehlern aus. Sind die in den Rohdaten oder ein Analyse-Artefakt?

gruesze, thomas

ZITAT(ddd @ 2010-04-25, 20:55) @Matthias, nimm den Vermerk im LensID-thread wieder raus bzw. kommentiere ihn, es ist schlicht falsch.[/quote]
Done.
ZITATZu littlelambs SampleLogs:
ich habe mal Matthias' Analyse etwas anders umgebrochen:

[...]
das sieht für mich nach einer recht hohen Zahl an Lesefehlern aus. Sind die in den Rohdaten oder ein Analyse-Artefakt?[/quote]
Ich habe die Daten nicht analysiert, sondern bewußt erstmal nur 1:1 aus Hans' CSV-Format in ein binäres Lensdump konvertiert und dann als Hex-Dump ausgegeben, damit wir's lesen können. Mir kommen die Daten auch spanisch vor. Vermutlich liegt das an SPI-Einstellungen in Zeroplus, das diese Daten letztlich erzeugt hat und sie entweder als XLS- (oder direkt als CSV-Datei?) ausgegeben hat.

Viele Grüße,

Matthias

@ Matthias und Thomas,

Ihr habt vermutlich recht, dass in den Log's von mir Lesefehler sind. Ich muss mich noch ein bisschen mit dem Analyser und seinen Einstellungen spielen.

Das Objektiv ist die neuere Version 35-105/3,5-4,5 (die Plastikvarante).

Wenn ich zuverlässigere Daten haben, rühr ich mich wieder.

lg
Hans