Sony MZ-R37 LCD Reverse Engineering

Sony MZ-R37 LCD Reverse Engineering

I'd had a Sony MZ-R37 in the workshop for quite a while. I can't remember where I got it, I think it came in a job lot of something. It had battery leakage so I left it for later clean up. Unfortunately when I recently came to look at it again I found that the batteries had leaked out of the device and onto my shelf. It had turned from a possible recovery situation to a tear down and parts salvage. There's a video of the strip down here:

During that process I found that the display was an interesting little PCB with what looked like a serial interface. What made it particularly interesting was that it has a six character dot matrix display as part of the layout. This means that it could maybe display arbitrary character on it and make it a useful part to repurpose.

A very nice discovery was the service manual for the MZ-R37. This is very complete and had the pinout for the LCD controller flexi cable. It is indeed a serial interface. The interesting signals are:

DATA

CLOCK

STB

A0

DATA and CLOCK are serial data and clock respectively. STB is a strobe or chip select signal. The A0 line is a command/data selection signal. With this information it was easy to scope the signals up and see how the dot matrix data is transmitted. There's a block of 30 bytes clocked out with a preceding command byte of 0x0A. The bytes are columns of each 5x7 character, in sequence from left to right. The row order is not logical and has to be reordered from a standard top to bottom order. Only seven of the 8 bits in each byte is a dot matrix segment, the remaining bit (bit 0) controls an icon in the top right of the display.

I grabbed a trace of the matrix data for the Vr1.20 display, it is:

0x0a,                                           // Command code (A0 low)
0xe2, 0x14, 0x08, 0x18, 0xe2,                   // First matrix character data
0x7c, 0x20, 0x40, 0x40, 0x40,                   // Second matrix character data
0x00, 0x80, 0x80, 0xfe, 0x00,
0x00, 0x08, 0x00, 0x00, 0x00,
0x8c, 0x1a, 0x2a, 0x2a, 0xc8,
0xf4, 0x1a, 0x2a, 0x4a, 0xf4

As the data is jumbled it was difficult to decode this. I wasn't even sure that the matrix data was segment data, but 30 bytes was a bit too much for 6 characters of text if it was ASCII data. Counting the number of 1 bits in the data gave the same number as the number of segments in Vr1.20: 66 bits.

So it was definitely segment data. It took a lot of fiddling and test programs to work out the jumbling, but I did manage to work out the row order. 

I attached a Wemos D1 to the LCD PCB and replayed the 30 byte packet I captured earlier and the Vr1.20 appeared in the dot matrix area. I used voltage dividers on the GPIO lines and supply to drop the 3V3 to 3V0, just in case the display can't handle 3V3.

Once that was working I wrote a small test program that sent the 30 byte packet using a 5x7 font and jiggled row data. This allows arbitrary data to be displayed in the matrix characters. I also sent a second burst of data which is segment data for the left hand side of the display. The icons on the top right of the display are sent in bit 0 of each byte of the 30 character burst as mentioned above.

The switches are wired up with two signals that use voltage dividers to give different voltages for each key press. There's also a signal (WP) which pulses low when a key is pressed. Another signal (HOLD) is pulsed by the controller, but at the moment I'm not sure why. There's only one analog channel on the WEMOS D1 so I can't read both signals. At the moment the keys don't return different voltages when attached to the WEMOS, but do when attached to the MZ-R37 processor. I'm not sure why at the moment, but I'm not too worried about the switches, it was the display I was after.