> This brings to mind a question I posed a while back that no one seemed to
> want to deal with. Why are there no drivers for the parallel port tape
> drives? These are some of the least expensive drives around. Is anyone
> working on anything like that? Or is the parallel port so (un)standard
> that you can't match hardware for a stable driver?
I'm not sure that it is fair to say that nobody wants to deal with it.
I get several letters a week from people who'd like the ppa driver to
work with the Ditto drives. Many of them even ask me for tips about how
to start work on such a project. It would seem that the methods I used
to build the ppa driver for the ZIP just won't work.
First of all, these tape drives are based on QIC-80 "floppy tape"
technology, they are not SCSI devices. If you look at the ftape
module you'll see that these tapes are primitive devices requiring complex
programming. The floppy bus itself is basically analogue, so I would
conclude that the parallel port versions are probably made by
incorporating an actual floppy disk controller together with some
buffers and some ASIC glue that implements a protocol for controlling
the FDC and accessing the buffers via the parallel bus.
So, a driver for a parallel port tape drive would have to incorporate
all the code in the ftape driver, but with the low level access mediated
via another layer of code that implements the host side of the parallel
bus protocol.
But all this requires that one know what the protocol is. There are
two ways to get it. You can ask politely - and probably get no response.
Or, you can try to reverse engineer the protocol, as I did for the ZIP
drive (and am now doing for the EZ135 parallel drive). Doing that requires
two things. First, you need an idea of what you are looking for - some
high level model of what the protocol is trying to do - in this case I'd
look for things that appear to be accesses to the FDC registers (but it
will be difficult, I think the FDC uses sequential writes to a single
port to access several registers). I'd also look for obvious "wake up"
sequences, rhythmical bursts characteristic of data transfers, and
blocks of repeated access patterns. Secondly, you need a tool to
capture traces of the protocol to use as input to the analysis I just
outlined.
The Linux DOS emulator can be modified pretty easily to provide the
tracing tools - if you can get the DOS drivers to work under the emulator.
You have to be able to run the driver without interrupts or dma.
(Since you need a synchronous trace.) As far as I know, nobody has
succeeded in getting any of the tape drivers to work under DOSemu.
Can anybody in the ftape project add any additional perspective to this
picture ? (I believe there were some failed attempts to support the parallel
Colorado tapes a few years ago - can anyone remember anything ???)
--------------------------------------------------------------------------
Grant R. Guenther grant@torque.net
--------------------------------------------------------------------------