Well, I have one of the modules connected up to my general purpose FPGA reverse engineering / ROM emulation rig.  There's no ROM emulation yet but I can feed it arbitrary data and receive data from the display.

For testing, I sent it LFSR data (41 bit LFSR) at various speeds from 100KHz to 10MHz or so and so far nothing happened.  This isn't too surprising I guess.  It most likely has some kind of complex packet structure to turn the display on and configure it.

I also hooked the FPGA's programming pin up that reconfigures it so I can reboot the board without having to power it down and up again.   This lets me catch anything that happens on startup.      While I was soldering wires, I connected the I^2C bus to my board as well.

I will record the entire I^2C startup sequence (it's long and takes a few seconds) along with the data that comes back out of the chip on startup.   There's 4mbytes of RAM which should be plenty for this application.

Eventually I want to replace the RAM/ROM on the board with an adapter for this emulator board and probe memory as it runs.

One interesting thing is if you reset the board, some random rows of LEDs will flash on and off quickly as the CPLD is sent the control signals.  This doesn't happen from poweron, just if you reset the FPGA.

The data coming back from the display seems to be boring and so far not too interesting.  It's the same data that it spits out of the output jack.   It is a 10 bit repeating pattern: 1111111111111111_0001110101_0001110101_0001110101.    If the data is interpreted such that the initial 0 is a start bit, the data becomes 0011_1010 with an extra "1" stop bit.  This is ASCII for the backslash (\) character.  I guess the data format might be basically RS-232 like in nature but synchronous instead of asynchronous.

Changing the input clock over the entire 10KHz to 10MHz range resulted in the same exact synchronous data stream coming out.  Maybe the display is looking for text/data strings?  That'd be pretty interesting if so (and I suspect they will be present in the parallel flash).   It most likely is packetized format, and there will be commands to turn it on, check the calibration, read the temp sensors, etc.  As it is, the I^2C is not accessed again after startup so it is obviously sitting and waiting for commands before it starts doing stuff (tm).  If it is packetized it probably is checking for a hash/checksum too and it will not accept the data unless this is present.

Here's a quick dump from signaltap.   GPIN10 and GPIN11 are the differential output from the display's input connector, GPIN12 and GPIN14 is the I^2C.  There was a gap in the I^2C data so I moved the time slider to the point where a new I^2C transaction starts.  The differential return data idles with GPIN11 high and GPIN10 low (the 111111 part above).  The data logging was triggered on the rising edge of the clock I am feeding the board so it just looks high all the time (GPOUT2 and 3 is the clock,  GPOUT 0 and 1 is the data).