The mapping from the parallel port I/O ports to the pinout of the parallel port connector: Note that the IRQ bus line (5 or 7) is connected to the acknowledge pin if and only if bit 4 of port 2 (I denote ports by the offset from the first port) is set. Also note that the hardware inverts pin 11. |7|6|5|4|3|2|1|0| ports 278, 378, 3BC | | | | | | | \---- data bit 0, hardware pin 2 | | | | | | \----- data bit 1, hardware pin 3 | | | | | \------ data bit 2, hardware pin 4 | | | | \------- data bit 3, hardware pin 5 | | | \-------- data bit 4, hardware pin 6 | | \--------- data bit 5, hardware pin 7 | \---------- data bit 6, hardware pin 8 \----------- data bit 7, hardware pin 9 Port 3BD printer status register (Parallel Printer Port) |7|6|5|4|3|2|1|0| ports 279, 379, 3BD | | | | | | | \---- 1 = time-out | | | | | \-+----- unused | | | | \-------- 1 = error, pin 15 | | | \--------- 1 = on-line, pin 13 | | \---------- 1 = out of paper, pin 12 | \----------- 0 = Acknowledge, pin 10 \------------ 0 = busy, pin 11 Port 3BE printer control register (Parallel Printer Port) |7|6|5|4|3|2|1|0| ports 27A, 37A, 3BE | | | | | | | \---- 1 = output data to printer, (pin 1) | | | | | | \----- 1 = auto line feed, (pin 14) | | | | | \------ 0 = initialize printer, (pin 16) | | | | \------- 1 = printer reads output, (pin 17) | | | \-------- 0 = IRQ disable,1=IRQ enable for ACK | | \--------- 1 = bi-directional parallel port \-+----------- unused
Seems that the little connector shell has a Microchip 16C65 in it. There are only nine pins coming down from the camera. That's enough for power, ground, six pins of gray, and one pin of composite sync. That processor has a serial port in it, but the design doesn't seem to use it. Oh well, that's all internal stuff that we don't need to worry about.
Pins 2-13, and 15-17 seem to be used.
When the processor is not actively managing the QC, the QC emits a 5 Hz stream of ones and zeroes. This is probably how they detect which parallel port has the QC -- just monitor all of the parallel ports and pick the one that's wiggling.
In 4-bit mode, the average levels on pins 11, 12, and 13 correspond to the light levels. Not so in 6-bit mode.
Doesn't seem to use interrupts, as the ACK pin doesn't have a signal anything like what would be needed for it. That means that it runs in the foreground. Must have some way to detect a bad frame receive.
They don't use EPP. They only seem to use uni-directional (5 bits of input on the status pins) and bi-directional (5 bits of input on the status pins, and 8 bits of input on the data pins). This makes sense because it's the easiest thing for them to do. Dealing with EPP ports also would be a nightmare.
Ongoing values that appear on the output pins:
x64 x16
80x60: 1010 1000
160x120: 0110 0100
320x240: 0010 0000
Check this out -- this is what you see when you switch from one mode
to another. Very consistent changes. Note that 0x50 is 80 decimal,
0x28 is 40 decimal, and 0xa0 is 160 decimal. That's half the
horizontal resolution in every case.
320x240 to 160x120
00 ... AF ... 50 ... 04 ...
160x120 to 80x60
04 ... af ... 28 ... 08 ...
80x60 to 320x240
08 ... af ... 13 a0 ... 00 ...
Here's another interesting thing: when you hold your hand over the
camera so the entire image is black, one of the printer control
register pins is getting twiddled, and one of the printer status pins
is getting twiddled. And the printer status pin is delayed by 1.2us
from the printer control pin change. Pretty sure that each transition
of the control pin tells the camera to output another word, and after
it does, it changes the status pin.
The PC is definitely telling the camera what its brightness should be.
A scan line seems to start with the PC outputting 07. Then it raises
the printer control pin and waits for some data (two nibbles?) from
the camera. After it gets the data, it outputs 00 (this is 320x240
mode) of course.
Sequence to output brightness of 51h:
(first nibble is top four status lines, first bit of next nibble is
handshake from QC, next bit is handshake from PC, last two digits are
data port.
8360 - previous command's data
730b - output brightness command
830b - QC changes its output (probably outputting high nibble)
870b - PC raises handshake
8f0b - QC raises handshake
8b0b - PC lowers handshake
3b0b - QC outputs low nibble
330b - QC lowers handshake
Pin fifteen seems to go low once, and only once, when the camera gets
initialized by sending it a 75. But the camera also has to have the
control pins set right. Pin fifteen goes low when pin sixteen goes
low. The data doesn't start twiddling until pin seventeen also goes
high.
Pin sixteen is used as a handshake coming back from the PC.
The camera ball has Texas Instrument TC255 chip in it, few supply voltage
converters and signal level shifters. Those nine pins coming down from
the camera are (in order of the connector inside the ball):
The actual A/D conversion is done inside the parallel port connector housing (using SONY A/D, obsolete now). The timing for the CCD chip is done by the PIC.