grant@torque.net
Sat, 31 Jul 1999 16:26:16 -0400 (EDT)
> First of all, my posts lately have all been met with thunderous silence.
That's probably because there's only one of me and I don't always have the
time to respond during the week.
> Have I offended y'all? Broken some rule of which I was unaware? If
> so, my apolgoies.
Well, you could turn off the HTML in your postings - it makes them even
more formidable than they already are.
I'll try to deal with some of your recent mails ...
> Ok, I have made some progress. I can get away from the "device busy"
> (general probe failure, really) messages if I turn *OFF* EPP mode.
> Either ECP or SPP or "non-extended" mode seems to work for probing
> the device. Using non-extended mode I can successfully burn small
> disks.
Well, that seems to suggest that there is something odd about the EPP
port on your laptop. I don't know anything about Hyperbooks - do you
know what sort of parallel port chip it uses ? Try getting the
"testport" utility from www.micro-solutions.com and running it under DOS.
It might identify your port.
> insmod pg drive0=0x378,0,0,1,-1,0
> but it seems to be slower than with the delay of 1! Moreover, it still
> seems to be lots slower even when I default it like I was doing before.
> So I'm really lost.
Are you getting I/O errors with the delay at 1 ? I can't otherwise
imagine how it could be "slower".
> Ok, I've played around even furhter, and determined that EPP mode does
> seem, in fact, to work, as long as I can get pg to ignore the fact that
> it says it doesn't. Under Windows, the "Shuttle" program recognizes
> that it's in EPP
Quite probably the Shuttle driver knows something about your parallel port
and how to adapt for its peculiarities.
> If I burn a disk I get a couple errors [they say
> "D0100 error (05/64/00) Command error - illegal mode for this track",
Or more likely, the Shuttle driver is adjusting some timing to adapt
for errors it detects, but from this it would seem that there driver is
not entirely successful, either.
> *So* what I really want to do is create my own hacked version of the pg
> driver that is hard-coded to know whatever it needs to know about the
> HP-7500 and ignore error codes from the parallel port since it is a
> known liar.
That's utter stupidity. If the tests fail, its because my driver is
not able to talk to your adapter in that mode. This isn't something
like overclocking a CPU, its a matter of changing the actual on-the-wire
protocol that the driver uses to transfer information. For whatever
reason, the protocol is not working with your port.
> Also, how do I know if my EPP is 8-, 16-, or 32-bit? When I use
> SPP mode, I'm simply informed that it connected in mode 1 (3/5), which
> I guess means that it's either 8- or 32-bit, but how can I tell which?
> I can't use mode 1 if I'm hacking "pg" to not be allowed to ask the
> device which one works . . .
The way you know if you port is capable of EPP-8, 16 or 32 is to do a
data transfer and see if you get the right thing. Of course, you have
to use the EPP protocol to do that.
What you've told us so far is that NONE of the protocols work when your
port is set into EPP mode, and only modes 0 and 1 work if you set it
to SPP mode. As far as writing goes, modes 0, 1 and 2 are all the same.
They differ in the way data is _read_ from the device. Mode 0 uses
(at least) 2 i/o cycles for every 4 bits. Mode 1 uses 3 i/o cycles for
every 8 bits by reading 5 bits from one port and 3 from another (hence
the 3/5 designation) and mode 2 uses two i/o cycles for every 8 bits
(so called "bidirectional" or "PS/2" mode).
> 2. How can I make just the parport modules? When I try this, I get:
>
> [paride]# make
> Makefile:174: /Rules.make: No such file or directory
> make: *** No rule to make target `/Rules.make'. Stop.
>
> I can go up to the kernel root and "make modules" from there, but then
> it re-compiles *everything* (which seems to obviate the whole purpose of make,
> but that's another story). This makes using printk for debugger *very*
> tiresome. How can I get it to compile only the paride pieces?
Try upgrading to a current kernel - there were bugs in the makefiles
(both PARIDE's makefile, and in the handling of MODVERSIONS, in 2.0).
> 3. The structures in paride.h are shared only among paride and its
> minions, right? (I changed the pi structure in paride.h and that's
> safe so long as I insmod only my hacked versions of paride, epat,
> and pg/pd/pcd, right?)
Yes, but why ?
--------------------------------------------------------------------------
Grant R. Guenther grant@torque.net
--------------------------------------------------------------------------
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2.0b3 on Sat 31 Jul 1999 - 16:27:15 EDT