For those of us whom source distribution is essential, the QuickCam NDA was not acceptable, because it denied source distribution rights. So we set about reverse engineering the QuickCam. Since the current QuickCam disclaimer allows source distribution, these pages will not be updated.
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.