| Introduction |
| In an effort to automate the storage of large data and mass duplicate small sets of data, I purchased a Kodak Disc Transporter along with a PCD writer 600. The PCD Writer 600 is Kodak's 6 speed CD-R that compliments Kodak's Disc Transporter. My PCD 600 arrived dead. It was killed by UPS, or the not so great packing job from the eBay seller. Not a big loss, as I was searching for a Disc Transporter without the CD-R to begin with. I did take apart the PCD 600, within 3 hours of it's arrival. Either the PCD 600 is really old, or over-engineered. It uses an i960 CPU and has 8 72pin SIMM slots (mine had 2 SIMMS in it). A digital control board (looks like it has serial ports!) and an analog board. Looks like there is a bunch of ADC / DAC stuff on the lower board with the MPU and SCSI stuff on the top. Very Wierd. Maybe sometime in the future I will see what the serial port has to offer. For now, a 2x SCSI CD-R and some books to situate the drive properly are taking it's place. In the end, I'm thinking a 10x Sony SCSI CD-R. The disc transporter is a SCSI connected automatic CD loader. It has an input spindle on the right, and output spindle on the left. The discs are loaded into the CD-R drive in the middle. It's design is quite a bit different from units like the Rimage Autostar. The quality is good, but it should be -- as it originally sold for nearly half the cost of a BMW M3. The Kodak Disc Transporter relies on a microcontroller to control functions. There is a reset button and a test button hidden inside of the top cover. The unit uses two stepper motors to move CDs. It uses a threaded rod driven elevator for the input spindle and a belt driven transport sled to move the disc pick-up mechanism. Three solinoids fire the disc grippers. A bit odd, the solinoids do not travel with the transport. The solinoids are fixed in place and fire downwards to activate the CD grip, when they are in the proper position. There is even a mechanical counter that increments every time a disc is loaded. Mine had 19,750 miles on it or so before it arrived in my driveway. Unlike more modern units, there is no rejected CD hopper. Another distinctive reason it may have been discontinued is the fact the mechanism will only service one CD-R. Well, almost only one. I have seen at least one configuration where someone mounted a printer in front of the unit facing inward. At some point the printer was told to eject instead of the CD-R, allowing the transport to drop the disc in the printer's tray instead of the CD-R. Thanks to this idea, it would be possible to mount a 2nd CD-R or DVD-R in front of the unit and cut the time in half. If the SCSI control over the unit is separate from the cd recording software, this should be possible. |
| So what is the problem? |
|
Support. Kodak discontinued this unit a while ago. Kodak has failed to leave any information about programming this unit on their website. Their tech support people refer customers to the website, which contains no useful information. When someone calls looking for the programming information (SCSI commands) you would think that they would have already checked their support site. Nonetheless, it is indeed an old unit. After this web page, they will most likely receive no more requests for the information. So what will drive this thing? To date I know of a handful of Windows and DOS programs that will drive the Kodak Disc Transporter off the shelf. There is one commercial Unix program (Solaris, IRIX, Linux?, and others). There is one commercial Unix based implementation that I know of. There doesn't seem to be any public information about the unit. Windows 95 and up Golden Hawk CDRWin has always supported the Disc Transporter. Easy CD Pro is rumored to have a version that supports it. Disc Juggler (the expensive version) supports the Transporter. Unix Gear Pro for Unix supposidly supports it Young Minds, Inc. developed systems that used it from unix. Dos DAO by GoldenHawk Technology supports it. Searching the internet I have stumbled across one Linux hack to trigger the unit. This particular person used a data line on the parallel port to trigger the test button. This way the user could force the unit to move the discs without using SCSI commands. You can view it on his homepage at http://www.umr.edu/~amlmr2 Hopefully he will be able to put that interface to rest soon.... . . |
| My plans... |
|
My plans are fairly straightforward. I'd like to strap a 10x SCSI CD-R in a custom mount to the back of my Kodak Disc Transporter. I want to use cdrecord for now, and in the future consider a SCSI DVD-R and the DVD version of cdrecord. I hope to use a spare Silicon Graphics Indigo^2 with FDDI, and without a video card to run production. The external SCSI connector on the Indigo^2 runs on a separate bus from the internal disks. I want to have a web interface, so that there is no console. Alot of what I'm trying to do is to back up digital video files produced on a PC with a DV editing rig. These files often hit 3gb to 4gb in size for the video, and then it shoves the 48khz PCM audio in a 2nd file. So if Samba is running on the Indigo^2, I could make a share called "staging." An option in the web interface would allow me to assign a filename structure and launch a process to break up the files, and use mkisofs and other utilities to generate ISOs. If the directory will fit on a CD, it could just prep it into an ISO. The disc transporter could be used to feed these back thru, to extract the data. Another part of the interface should allow tagging of availible ISO files for burning. The job is shoved off, and the unit should produce the disc set (or 3 sets of the set if needed). The ability to store an ISO collection on the Indigo^2 or another host is desired. This way a collection of often duplicated discs can be held until needed, and burned off when needed. Since I plan to donate use of my Transporter to the local unix users group, it would be nice to be able to enter "25 copies" of "FreeBSD current ISO set" and wake up the next morning to a nice fresh pot of Penguin or Daemon or whatever. Set it then forget it. It should be possible to use the output of cdrecord and the magical control program to write out a HTML file as the job is being run. The HTML file would be called with a meta refresh, to offer status to the user. Thanks to cdrecord being very portable this system should function on IRIX, Solaris, Linux and FreeBSD in addition to other OSes. Apache, Samba and Perl should be the only other requirements in addition to the scripts and web pages. It shouldn't be hard to come up with an ISO storage and retrieval system along with ISO creation. Just these features alone should blow past alot of the commercial foo on the market. For free! It should also be able to make audio CDs for band demos or promotional discs. |
| Problems... |
|
Kodak won't give up the commands. So what is a person to do? I don't want to use the parallel port hack. So the SCSI commands are the mission, and the mission only took two nights. I tried a utility called SCSIToolBox32. It has lots of promise, but locked up every time I would execute. DAO and CDRWin drive the transporter fine. So I tried a modified version of winaspi.dll to redirect the output to a file. It came from people reverse engineering scanners for SANE. CDRwin uses 32bit ASPI. No go there. DAO 16 bit seems to not use windows ASPI either. No go. Finally I found some source code on www.cdrlabs.com. A wnaspi32.dll redirector! But no binary version! I contacted the author, Boone, and the next day I had the binary version. Perfect. A quick hex edit of CDRwin.exe and a bit of reading the source code to figure out the .ini structure, and bsaspi32.dll was in place. And it worked. I've got the SCSI commands for the Kodak Disc Transporter. VIEW THE SCSI COMMAND DUMPS HERE I used Bart's scsitool.exe utility to send part of the command data block that I captured to the Kodak, and it moved. But without the last two bytes it didn't seem to complete the desired operation. It missed the very last part, where it releases the CD from the transport into the CD-R tray and retracts the plunger. Next step is to come up with a utility to test the commands to see what kind of response is gathered. Another thing I received with the Kodak was the manuals. There was a bit of hope when I first opened the Transporter manual, as it had a list of SCSI errors! It had the errors, but no commands. In case it might help others I have typed up the errors. It says there are 8 commands for movement. No leads to what they are specifically. The test button requires about 8 button presses to complete a cycle, so most likely those are what it supports. VIEW THE SCSI ERROR LIST HERE So the next step is getting the SCSI commands to the unit, and to verify their response. |
| Sept 2002 Update!!! |
|
"Yossarian" was kind enough to email me all the information anyone could
ever want about the Kodak Disc Transporter and the PD units. I have made
all documentation availible online. Something I wanted to do but haven't had time: A web interface that runs on FreeBSD or IRIX. The system would have a NFS mountable and Samba mountable storage disk for staging. The web interface would allow the user to click either an ISO image, or click an text file that has a list of ISO images that form a data set. The user could then type in the # of copies of the ISO image or ISO image sets (for instance, if you had 4 ISO images that make up one data set). The system would burn the discs. Using HTTP metarefresh, it should be possible to have a window that shows the progress of the recording session, # of discs left, etc. Just an idea if anyone gets bored. If you do embark on the journey, cdrecord and apache could do wonders backed by a simple Perl script and unix C utility. The X-Windows CD player utility I believe is capable of sending CDB blocks and has alot of information about MANY different operating systems, so using that as a basis it should be possible to roll out something compatible with IRIX, Solaris, FreeBSD and Linux. Mainly, the 4 OSes that count. GO TO THE FILES LISTING! Big thumbs up to Boone / CDRLabs for the ASPI redirect utility. Big thumbs up to Yossarian for the doc CD. |