received 10000 bytes in 721 ms (13869 Bps)
received 10000 bytes in 720 ms (13888 Bps)
received 10000 bytes in 783 ms (12771 Bps)
received 10000 bytes in 875 ms (11428 Bps)

received 10000 bytes in 1546 ms (6468 Bps)
received 10000 bytes in 1415 ms (7067 Bps)
received 10000 bytes in 1582 ms (6321 Bps)
received 10000 bytes in 1417 ms (7057 Bps)

Bad news, however, as plip seems to be bOrken on my 2.6 box.

The following is an example output of this tool:

PLIP WIRES STATES
    local | remote   | value
----------+----------+-------
       d0 | error    | 0
       d1 | select   | 0
       d2 | paperout | 0
       d3 | ack      | 0
       d4 | busy     | 0
    error | d0       | 1
   select | d1       | 1
 paperout | d2       | 0
      ack | d3       | 1
     busy | d4       | 1
control: init select

It demonstrated I can successfully read and write to the parallel port on my indigo2. Plip should work, then.

--- 10.0.0.2 ping statistics ---
244 packets transmitted, 40 packets received, 83% packet loss
round-trip min/avg/max = 11.8/446.0/4013.3 ms

As seen from the pc:

plip0     Link encap:Ethernet  HWaddr FC:FC:0A:00:00:02  
          inet addr:10.0.0.2  P-t-P:10.0.0.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
          RX packets:616 errors:0 dropped:0 overruns:0 frame:0
          TX packets:324 errors:390 dropped:0 overruns:0 carrier:390
          collisions:0 txqueuelen:10 
          RX bytes:53011 (51.7 KiB)  TX bytes:26221 (25.6 KiB)
          Interrupt:7 Base address:0x378

...and from the sgi:

plip0     Link encap:Ethernet  HWaddr FC:FC:0A:00:00:01  
          inet addr:10.0.0.1  P-t-P:10.0.0.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
          RX packets:324 errors:0 dropped:9 overruns:0 frame:0
          TX packets:616 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10 
          RX bytes:26221 (25.6 KiB)  TX bytes:53011 (51.7 KiB)
          Interrupt:255 Base address:0x9803 

Yes, there is something wrong. It seems the indigo2 fails to see some packets, but the sgi -> pc path seems correct, at least. That must be that damned ACK again...

dmesg on the pc contains loads of:

plip0: transmit timeout(1,80)

...and on the sgi:

plip0: receive timeout(2,80)

...which means basically that the pc waits for an ack to come back, while the sgi waits for the first half of the transfer size. Looks like they missed each other :)

Sep  3 07:43:51 mood-indigo kernel: parport0: SGI Indigo2 built-in port
Sep  3 07:43:51 mood-indigo kernel: parport0: Printer, Canon BJC-3000
Sep  3 07:43:51 mood-indigo kernel: lp0: using parport0 (polling).

Now for the somewhat bad news: I am almost able to print. Almost. This reads: I can print maybe 1cm, then it stops, in the middle of the page (by the way, not re-initing the printer between each write helps :).

Experiment 7

• BUSY goes low.

Experiment 8

• Other registers unchanged
• PE goes low

Experiment 9

• Other registers unchanged
• ONLINE goes low

Experiment 10

• Other registers unchanged
• ERROR goes low

So, all our input bits are non-inverted.

          4.7K      
Sn ----+--^^^^-- +5V
       |            
        /  ON/OFF   
       |            
GND ---+-------- GND

...but in my case, this is sufficient:

Sn ----.
       |
Dn ----'

Experiment 6

• ACK goes low as expected. It seems input bits are non inverted.

I need more method in the tests. A friend of mine was right: time to grab the multimeter (hi Christian !)

Experiment 1

• pin 25 taken as voltage reference
• pin numbering and names as described here
• input pins are in red

• We see the data on the wire, so the parallel port is actually in "forward" mode after reset. Good.
• strobe is inactive. so control bit 0 is non inverted.
• idem for autofeed (control bit 1)
• idem for init (control bit 2)
• idem for select input (control bit 3)

Experiment 2

• Changes are in yellow
• ok, it seems we are done for strobe
• no doubt for data

Experiment 3

• Ok for AFD

Experiment 4

• Ok for INIT

Experiment 5

• Spurious status change ? Corresponds to NOINK ?
• We know more than enough about the outputs to try SPP again without checking the inputs (I lack a small resistor). My best guess is that no input is inverted.

No printer connected:
data = 0x4
status = 0x7f
control = 0xcc

Printer connected, no paper:
(Only status changes)
status = 0x5f

Printer connected, with paper:
(nothing changes)

Now for the meaning of the values:
strangely, the only bit, which has changed is paper out !

Anyway, I put my first patch online here. It is against the cvs tree at oss.sgi.com, on the linux_2_4_branch.

I wonder if I got hpc3/pi1 BUSY polarity right or wrong. My information are contradictory... It seems to be normal (high-active) after all.

Note that slashed (/) signals denote 0-active signal

First, a brief summary of the available documentation:

The chip responsible for the parallel port is called IOC. It also handles serial, and much more.
Inside this chip, a macro named PI1 handles the parallel port specifically.
This chip is controled by 10 32-bit hardware registers. Their physical addresses range from 0x1fbd9800. The three first registers are: data, control and status. Unfortunately, their bit description is unknown (to me at least !)

Ok, what do we have now ?
The 3 first registers are promissing, from an SPP mode point of vue. All we have to do is guess the function of each bit of those registers. Data should not be the most difficult, if it is named correctly :)

Here are the values I have measured in three cases.

No printer attached:
data = 0
control = 0x3f3f3f3f
status = 0xfcfcfcfc

From this, I guess that our 32-bit registers are in fact 8-bit registers. Copies should have been made to avoid endianess' troubles. I also hope that, by default, data is in output mode.

Printer attached (only status changes):
status = 0x5c5c5c5c

Printer attached, no paper (only status changes):
status = 0xdcdcdcdc

I suppose that bit 7 means "no paper" when true, and that bit 5 means "error" when true. My guessing is largely inspired by the PC parallel port implementation, as the SGI people had no reason to change thinks completely.