A service manual containing the schematic of a V200 using the same type of CCD was found which contains the labeled pinouts of the FFC connectors and part numbers of the CCD board.

Datasheets of the ILX561K CCD and Epson S7R77S14F00A100 are not public so some reverse engineering and data sniffing with a working unit is required.

Note that the D7 and D6 pins are also labeled SDCLK and SDATA. 
These pins are used as half duplex SPI when the CS pin is low to transfer control data to the CCD interface and this is going to be very important to analyze for operation as this chip can not function unless the right CCD clock pin sequences are provided.

The now working v370 was modified by soldering wires directly to the FFC connectors and connecting them outside to a logic analyzer.

Data is being sent on 8 parallel lines with a 6MHz reference clock with data sent at both edges for a 12MB/s data rate and a TG line that seems to capture a new line and its frequency depends on the resolution setting. At the highest resolution it is only 46Hz transferring ~260000B (Full res sensor at 16b).

One notable command on the SPI control channel is 0x600081 and 0x600080. These start and stop outputting image data.
The first bit indicates R/W operations. Because the data rate is low and i am intending to capture data using a PIO program i chose to use software bitbanging to read and write control data. The timing doesn't matter in this case.
Comparing it to register maps of a similar chip (s7r77021) with a public datasheet the last bit seems to start the timing generator and data sampling. The register numbers are slightly different in this case but it was later found out that quite a few of the other registers seem to match.

A raspberry pi5 will be used to aquire image data due to its new piolib allowing PIO access to the RP1. After a lot attempts to decode colors from the image data of the existing scanner i noticed that the PIO DMA is not able to transfer data fast enough despite being connected via PCIe... Images were recognizable but it seems like the pi5 skipped at least every second byte with random pauses so the data is unusable to find out RGB offsets.

The TG pulse must be captured with the data to allow alignment later. Instead of capturing data at both edges of the clock only the first edge is captured and 3 samples with clock data are packed into one 32b buffer and decoded later. This did the trick and allowed a full line to be captured without missing too much data.

A color image of a random piece of paper could finally be decoded in 1200dpi mode which only contains the main lines and makes it easier to see. Yes there are random glitches and the colors are shifted due to the sensor layout but this is supposed to be a "Made in germany" icon.

You can make out the flag and the text. On the "100%" text you can also see how the sensor moves its 3 distinct lines over the white text causing 3 ghost images.