rainer@buchty.net

The display unit comprises three controllers, with an HD44350 being the main controller and two HD44351 as segment drivers. Looking into the user and service manuals reveals the following:

• 96*64 pixels arranged into 8 lines per 16 chars (i.e., 8*6 char matrix)
• Controller-wise, it's treated as two (16+80)*32 displays
  • The HD44350 delivers the row signals X1-X32 and two sets of segment driver signals W1-W16 and Z1-Z16.
  • The two HD44351 are "extending" the HD44350, each providing a set of 80 segment driver signals Y1-Y80.
• The whole mess is controlled by two clock signals (Phi1/2), chip select (CS#), and the OP# signal.
• The entire setup looks awfully similar to that of Casio's line of 1980s graphics calculators. Luckily, in the FX8000G service manual, some more information is given:
  • CS#/CE# is the enable signal. Low indicates a valid data transfer.
  • OP# is the "data operation" signal. It seemingly differentiates data transfer from command codes (presumably like RS with the HD44780 display). but unfortunately no further information is given.
  • Data needs to be stable during Phi1=1 or is sampled at the 0->1 transition. Unfortunately, the datasheet is not clear here (whatever "signals vary by pulse" means).
  • Control signals need to be stable during Phi2=1 or are sampled at the 0->1 transition -- same problem as with Phi1 applies.

The display circuitry is complemented by "GAL" (65012C046) which, according to the service manual, "converts the CPU data language into LCD driver's data word". Actually, it does a little bit more:

• Generating the two LCD timing signals (Phi1/2) from a 2MHz input signal. The FZ-1 OS sets a divider of 8, so they are 250kHz and hence match the waveform plots depicted in the FX8000G service manual.
• Generating the READY signal to indicate whether or not GAL is still busy shifting out the input data.
• And, of course, it translates that CPU representation into proper LCD commands and according signaling (OP, CS#, data placement according to Phi1/2)

From the FZ-1 OS perspective, the display protocol itself is stream-oriented -- a stream of 32 bytes is fed into GAL which subsequently translates it into corresponding display controller messages. So how does such a message look like?

• A display message comprises a maximum of 32 bytes, including marks.
• Message start is signaled by the command marker 0x1f followed by the command itself and its (varying) number of parameters as nibbles.
• Following the command block is a data block, signaled by 0x10, followed by up to 5 parameters such as to be printed characters or graphics patterns, again represented as nibbles.
• Message end is signaled by the end marker:
• 0x80|data mark=0x90 if the message is less than 32 bytes
• 0x80|data nibble=[0x80:0x8f] for the last data item of a 32-byte message.
• Translation of OS representation to a GAL message stream is done via the lcd(s) routine which does the following:
• Emit command marker 0x1f
• Output command/parameter stream until 0xff is hit.
• Emit data marker 0x10
• Output data stream until either 0xff is hit or message length is exceeded. Emit 0x90 in the first case, 0x80|data in the second.
• This is interesting insofar, as
1. The init command strings for setting up the display and drawing that funky greeting screen overlap, i.e. the following init command string is appended as data to the previous init command string. These commands don't take any data, though. Seemingly this extra data is ignored by the display controller.
2. The high-level routines like print, cls, and pset actually all show the error of embedding the data mark 0x10 directly into the command string handed over to lcd(s) instead of separating the command and data blocks by a 0xff marker. Such is only placed at the data payload end, leading to a command string that has no 0x90 end marker but a 0x10 one. Presumably, GAL takes that second data mark also as a stop marker.

Now, what's the command encoding? Picking them from the OS source turned out to be quite interesting. Luckily, others did some serious reverse-engineering based on the graphical Casio calculators.

Here's a copy of their LCD command documentation that sheds significantly more light onto the protocol than the FZ-1 OS would reveal.

It must be noted that the description pair nibbles into bytes, hence most notably, combines parameter 1 and cmd into one byte (and of course any remaining parameters also).

One thing is somewhat interesting from a hardware perspective: While the FZ-1 schematics show that the display is technically organized (80+16)×(32*2), logically it's organized as (48*2)×64 judging from the command documentation (and confirmed by the FZ1-OS). Even more interesting is that these two halves are called upper and lower half in the command rather than left and right. This probably means that the display originally was conceived for portrait use, not landscape.