Software

Although the "Blue Pill" is much faster than most Arduinos, it is only barely fast enough for the task at hand. The reading of the Z1 data and control lines especially is time sensitive and requires efficient code, optimized for speed.

Three points worth mentioning:

  • The Arduino IDE's normal IO routines are too slow and cannot be used in this project.
  • All interrupts need to be disabled as the background processes the IDE inserts into the code interferes with operation, resulting in an unstable LCD image.
  • When compiling the code, the compiler needs to be changed from the default setting of optimized for size, to optimized for speed.


Initial plans for interrupt driven logic had to be abandoned when the data rate of the M66271FP proved too fast for the interrupt response times of the "Blue Pill".

Fortunately the M66271FP's consistent, fixed period cycling between active and passive cycles made possible a relatively simple workaround.

Operation can be summarized as follows:

  • While the LP line is low, on every falling edge of CP, read a data nibble into the next nibble position in the LCD data array. LP stays low for the duration of one line, resulting in a total of 60 nibbles (30 bytes).
  • When LP goes high, read, process, and write 32 bytes from the LCD array to the ST75256. The 32 bytes will be done before LP goes low again.
  • Wait until LP goes low and repeat the process.


Latency

A certain measure of delay is inevitable.

It would have been ideal if, in a line write cycle of the the M662751FP, the 30 bytes read, could, in the passive period, be written to the corresponding pixel locations of the replacement display. That would have meant virtually no delay, as the data would have gone into the replacement display even before the start of the next line.

This unfortunately is not possible due to a difference in byte orientation between the M662751FP and ST75256.

In the case of the M662751FP, a line could be thought of as 30 horizontally arranged bytes, sitting end to end, with each bit representing a pixel as shown in red below.

Relative to the above, the bytes in the ST75256, are arranged vertically as shown in yellow.

The first byte of the ST75256 is there fore made up of the first bit of the first byte of the first eight rows. The second byte of the ST75256 consists of the second bit of the first byte of the first eight rows and so on.

For every 30 bytes written from the Z1 into the adapter, the adapter writes 32 bytes to the replacement LCD.

The output process is therefore slowly lapping the input process, resulting in an ever changing time difference between the two. That, combined with the fact that a "read" spans across eight write lines, makes it hard to quantify the amount of lag introduced at any specific point in time. At worst, the delay can be estimated at 1 frame. Frame in this case refers to the rate at which the M662751FP is refreshing the XY drivers of the LCM24064YGF LCD and is not a reflection of the module's actual refresh rate.

This "frame" rate equates to a surprisingly high 132 frames/second, which means a delay of 1 frame equals 7.57 milliseconds.

No longer having a working original display rules out a side by side comparison, but I doubt such short a delay would be noticeable.

Splash Screen.

The adapter and LCD is up and running well before the Z1 is rendering any output. Rather than leaving it with a blank screen, I replicated the Z1's splash screen into the adapter , to be displayed until the Z1 is ready with its own splash screen. The only difference between the two, is that the fake screen is labeled "LOADING..." in its lower right hand corner.