>
>         While I'm shooting in the dark, does anybody have the serial
>         protocol used by the Kodak dcXXX series of digital cameras? Judging
>         by a flash update I pushed in to it, strings is your friend, it's
>         running an emmbedded version of MessyDog and uses stock rs232
>         serial at 9600,19.2,38.4,57.6,115 and 230K. Looks like a binary
>         protocol from the simple terminal hookup I did to the driver software
>         under windoze. I signed up for the Kodak developer area but all that
>         is is a bunch of Wintel/Mac API librarys, the good stuff is
>         hidden in the Kodak librarys provided. 

I got about as far; but used some linux tools to talk to the dc25
and the chinon; and used a bit of sniffing with a second machine. It
is indeed a serial protocol; and not that easy to second guess.

ftp://ftp.digipri.co.jp/pub/free-software/Kodak/

(Just ignore the 0xa0 vs 0x80 return codes for now; and you have
to hack the serial code a little bit; just remove the 4 lines 
which do not compile; and leave the serial port setting in place.)

Playing with the flashcard gave me some more joy; using a pcmcia
adaptor for the kodak 10Mb card; and the pcmcia drivers from
the nomad group on freebsd 2.2 I could just mount the card as
an ordinary wdc1 controller ran ms dos disk.

I've emailed the signature of the card to the maintainers of
the pccardd.conf file; it is just a normal 

The disk contains a directory called dc120img with the images;
however there is some fun and games with case; which is contary
to what one would expect on a Dos disk. As the flash ram also
works just fine on a Psion 5, which does care about case, I
could confirm this; and have edited the msdos driver in the
kernel to cope with it.

This gives one access to the files; but sadly enough they are
in the internal kdc format; Kodak's hacked version of Tiff,
essentially TIFF wiht some special extended/propetarial tags.

The little quick look is easy to decode, at 1024x and 60x80
xRGB 8 bit. So something like

	mrawtorle -depth 8 -order RGB -b 3 -h 1408 \
		-w 80 -h 60 | rletogif | xv -

or

	rawtoppm -headerskip 1408 80 60 $1 | ppmquant 256 | ppmtogif > $2

does nicely. (or likewise for the netpbm toolkit).

Sadly the actual hi-res image is in a very funny compressed
format.. well it seems like that anyway. I've talken the
windows DLL apart; and it seems that the code is not
trivial at all; which surprizes me; because the camera
contains a very simple processor; hardly capable of anything
clever; so it might just be a bit of obviscation somewhere;

If you use tiffdump you get an idea of the data in there
and the bulky block of image data is easy to spot. But
it does not seem to bee RLE or some huffman or Lempel-Ziv
encoding wich is easy to recognize; but if one would
fiddel with the adaptive part and write it out later
and/or swap the order; it would be very hard to decode
anyway. The windows DLL spends a lot of time/code during
the _read_ to actually decode the format. And seems to
produce the file from the stream without jumping or pre-
fetching a token expansion block or some kind of
binary tree with the decompression scheme insofar as 
I can see.

Just for your information. Keep me posted if you get anywhere;
I'd love to have an all-unix solution :-)

Dw.