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.

Protocol Description

Reset sequence
Output 08h to control port. Output 75h to data port. Output 00h to control port. Pin 16 seems to be the initialization line. After about 250us, output 04h to control port. Output 02h to data port.
Command output
Output the command to data port. Output 4 to control port to indicate that a command has been output. Wait for handshake (port 1 & 08h) to go high. Input status port and save it (it's the high nibble of the command). Output 0 to control port. Wait for handshake to go low. Input status port (low nibble of command).

Command list

Set brightness
0Bh followed by brightness value.
Start a scan
07h followed by scan type. 00h = 320x240, 04h = 160x120, 08h = 80x60. Add 2 to these values for 64 graylevels instead of 16. Following this command, the camera goes into scan mode, and will give you one scan in the format you've requested.
Set vertical resolution
0x11 followed by resolution.
Set horizontal resolution
0x13 followed by half the desired resolution.
Set contrast
0x19 followed by contrast.
Set Y starting point for zoomed images.
Set X starting point for zoomed images.
Set white balance
0x1f followed by white balance.

Hardware Description

 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

Random notes

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.