On 6/29/01 at 9:49 PM Robert Newson wrote:
What's wrong with using a parallel port to access a storage device? Or
is this based on the misconception that parallel port = printer [output]
port (as that's for which they're generally used [by most PC users] and
only that driver is installed)?
My first meeting with a parallel port was on the Commodore Pet (3032) -
an IEEE 488 interface (aka HP-IB; a parallel port)
IEEE488/HPIB/GPIB is NOT the parallel port regular printers are attached
to, that one also being known as 'Centronics'. In fact, by function, and
'parallelness' the closest relative to IEEE488 would be SCSI, except that
IEEE488 was planned as a more general purpose peripheral bus from the very
start.
The difference between a regular 'Centronics' and IEE488, or for that
matter, SCSI, which, hardware-wise could also be called a kind of a
parallel port, is that it does not, in itself, implement any kind of
protocol - it is actually the device attached to it that does. When there
is nothing attached, there are no signals. With IEEE, SCSI and similar
interfaces, the protocol exists regardless of devices attached, it only
returns an error if you are trying to communicate with a non-existing
device.
There is nothing wrong with having storage devices connected to a port that
was originally only a collection of buffers to get signals over long wires.
As a matter of fact, that's how IDE started. Both have evolved somewhat
from the time they were concieved. For instance modern 'printer port'
implementations have modes where they DO implement a protocol of their own,
even with nothing connected. IDE still doesn't, though. But that's beside
the point - in theory you only need two wires to connect to anything
anyway.
What IS wrong is that many computers can communicate with devices that
connect to parallel ports, and that are not printers, but the QL supposedly
'can't'. In some cases, there are hardware limitations, but in others, for
instance, Q40, there are none, so what is the problem? It is exclusively a
driver issue, and because the way QDOS/SMSQ defines drivers is largerly the
same for all of them, the problems are by no means restricted to parallel
ports!
In particular, QDOS/SMSQ does not enforce a speciffic internal structure
for drivers, it just defines how the 'top end' - the TRAPs it needs to
support - must look, and provides some resources for the 'bottom end' -
interrupts and queues. How one gets from handling interrupts and moving
data to and from IO registers, to traps, which do things like 'move file
pointer' or 'read string', is entirely left to the 'internals' of the
driver.
At first glance, there is nothing wrong with this. However, the consequence
is that the driver writer does not feel compelled to think about a
possibility that someone else may want to attach hardware onto an interface
his driver handles, that he did not plan for, or that other interfaces may
use the same protocols he used in his driver.
So, when someone decides to add the new capability, in the first case, the
only way to find out if a driver can use hardware already used by another
driver, is to dissasemble the other driver, or have the source - and then,
in 99% of all cases it will be determined that without modifying the
existing driver (not always possible), adding the new functionality is
simply not possible.
In the second case, you may have to reinvent the wheel and do your own
version of something that has already been done. In the interest of
compatibility, you may have to actually again either dissasemble existing
code, or have the source. In the best case, even if you were just given the
required 90% of already existing code, it would be needlessly duplicated.
In the worst case, you'll spend 90% of your time doing things that were
already done, based on rather unreliable knowledge of how there were
supposed to be done. Even worse, you may be copying someone elses bugs!
This is NOT the way to write drivers!
Nasta
