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.

Sharp PC-G850 Gadget

Sharp PC-G850 Gadget

The PC-G850 is one of the last pocket computers. It is an impressive machine and has a lot of interesting features.

And a nice keyboard. The features include:

• BASIC programming
• C programming
• Z80 assembler
• CASL (Japanese assembler)
• PIC assembly
• 11 pin interface with PIO mode
• Support for PIC 16F84 programmer attached to 11 pin interface
• Serial I/O on 11 pin interface

The PIC programming interested me, and the 11 pin interface means the machine can interface to all sorts of things. The first problem, though, is that I don't want to type in programs and lose them when the batteries drain. So, I decided to make a gadget that attaches to the 11 pin interface and gives me some storage. I've done a couple of these gadgets in the past (one for the fx502p cassette interface and one for the Microtan computer using TTL levels) so I based it on those.

It's a 'blue pill' ARM processor board together with an SD card module and an OLED display. Three buttons allow the gadget to be operated with no computer attached. If a computer is attached then the Arduino IDE serial monitor can be used to issue commands.

The board is plugged in to a series resistor interposer that provides a degree of protection to the PC-G850 when the board is attached. If a PIO line is set as an output and drives an output on the gadget then the resistors limit the current and hopefully the damage.

The OLED display has a menu system that allows files to be sent from an onboard RAM buffer, received from the Sharp into a RAM buffer and read and written to and from SD card.

The code uses interrupt routines to receive data from the PC-G850, the USART on the ARM is also attached but I haven't written any code to use it yet. There is also the possibility of using handshaking while receiving data which should allow the gadget to pause the Sharp while writing directly to SD card. That would allow large downloads. At the moment everything sent or received has to fit in an onboard 10K RAM buffer.

I used the ST LINK programmer for the first time on this board and it is much faster than the serial programming method I used before.

I'll probably create a PCB for the gadget, it'll be a bit more mechanically sound.

Trust Your Tools (Well, Sometimes)

Trust Your Tools (Well, Sometimes)

One of my rules of thumb is 'Trust Your Tools'. If your multimeter says it's 4V then it probably is. If your debugger says that a variable is a certain value, then assume it is. Don't assume your tool is faulty. Most of the time it isn't.

So, when I needed to program a PIC16F84A for my Microtan, I immediately went for my newest programmer, a PICKit4 from Microchip. After installing MPLAB, which I didn't have on my laptop for some reason, I built a small circuit on perfboard which has the required bits and bobs needed to program a PIC.

I popped a 16F84A into the adapter, attached the PICKit4 and, oh dear, the bank check has failed. OK, try another chip. Same thing. OK, check wiring, all OK.

OK, get the PICKIT3 out as well. I tried programming the two initial chips and had no luck. Not good.

I had bought three chips from China, so decided to try the third chip with the PICKit3 and no luck. I decided that the chips had to be bad, so after trying them with the PICKit4 again, just to make sure, I bought some more chips from a reputable supplier and waited for them to arrive.

When they turned up I had another go with one and the PICKit4. No luck, exactly the same as the Chinese chips. Maybe they weren't bad after all. I checked the programming circuit for the PIC16F54 and found that I'd left out the capacitor from MCLR to ground and the Schottky diode from the RC circuit to the MCLR line. I added these and tried again with the PICKit4 and still no luck.

I then decided to go back to the PICKit3 with the new circuit and a fresh chip. It worked. Finally I had a programmed chip. A quick test in the Microtan keyboard PCB confirmed that it was working fine.

So, what happened? Looking on the internet it seems that the PICKit4 destroys PIC16F54A chips (unless, maybe you have a series resistor in line with the MCLR line, I haven't tried that). It is also reported that you may destroy the PICKit4 as well.

I'm not happy about that. The PICKit4 has the device in it's list of supported chips and lets you program it. Destroying them is not an acceptable outcome. I'd prefer it if they dropped the device from the supported device list.

Here's a picture of the 5 destroyed chips I ended up with, they seem to be permanently damaged as I can't program them even with the full circuit and the PICKit3.

In the 'olden days' the PICs were excellent little things and they worked. As well as the PICKit4 problem, I've had trouble with a PIC16F707 that simply seemed to not work, and a problem with MPLAB a couple of years ago where it just did not work on my Linux laptop, that appears to have been fixed now, but that's quite a lot of problems, especially as I don't use the PICs that much.

Oh well. I'll have to check on the interweb before I use the PICKit4 in future...