Search This Blog

Follow by Email

Saturday, 12 September 2020

Casio CQ-1

 Casio CQ-1

A long time ago, I had a Casio CQ-1. 

It was a weird machine, I suppose, but it was a clock, and a stopwatch, and a calculator, which makes it pretty useful. And the calculator could tell you what day of the week any date was (well, in it's date range). It could calculate the number of days between two dates. And it was an alarm clock.

Not so long ago the batteries leaked and the CQ-1 was binned. This was a shame and I decided to get hold of another one, so bought one on ebay. This didn't turn out too well, as the device would only start up if I held my finger on one of the clock oscillator pins. I tried simulating a finger with various components, but the little chip seemed only happy with my finger. I never found out why, so I bought another CQ-1, hoping to either get enough bits to fix my original CQ-1 or get a unit I could fix. That didn't work out too well either, as it was utterly dead, and no amount of fingering could get it going again.  Aargh!. Third unit and this time all was well. It calculated dates and the stopwatch worked.

At least all was well until I came to use it after a day or two and the AA battery was flat. Aaargh! again. This CQ-1 has a strange fault where the supply that powers the VFD display seems to power up repeatedly even when the unit is off, and that eventually flattens the battery.

So, I decided to have a go at designing a replacement for the CQ-1 main PCB. This is the one that has the circuitry on it. This is a partially stripped PCB:

It attaches to a keyboard PCB which has one of the AA battery connections on it. The wire tabs connect to two 1.5V watch batteries that power the clock circuit. 

The first attempt at recreation is this:

There's a prototyping PCB (one of Mike Harrison's prototyping boards) with all the circuitry to create the voltages to run the ARM processor (3V3)and the higher voltage needed to run the VFD segments and digits (about 23V). The filament drive is conveniently 3V3 (ac). The PCB is attached to the front half of a CQ-1 which provides the switches and keys. All this circuitry runs off a single AA battery, or USB. As batteries are an evil that has to be tolerated, I did consider running this off just USB, but decided that it was too limiting. i didn't want to use the original CQ-1 PSU as I've never seen one, and USB is just so convenient. I haven't carried over the silver oxide batteries that run the clock, instead the RTC chip runs directly off the battery. It is a low power chip so that's not a problem. If there's 3V3 then it runs off that too, so you can plug a USB cable in when changing the AA battery.

This is a close up of the prototype PCB.

There's a blue pill providing an ARM processor, programmed with an ST-LINK. There's two dc-dc converters, one to go from 1V5 to 3V3 and one to go from 3V3 to 23V (-ish). The 23V supply is switchable from the processor and turns the display on and off. The VFD is driven from a MAX6921 chip which has a serial connection to the processor. The timekeeping is provided by an MCP7940 chip with it's own crystal. This is attached over I2C to the processor. i took a VFD tube from a donor CQ-1 and that is used as the display. The beeper is also from a CQ-1. Due to the STM32F103C8 on the blue pill not having enough GPIOs to handle all this hardware and scan the keypad, a GPIO expander is used on this PCB to provide more GPIOs. This is accessed using I2C.

Of course, this doesn't fit in the original case, so a V2.0 PCB has been created that does:

This is basically the same circuit, but the dc-dc converters are now in component form on the PCB, and the GPIO expander has been dropped as a larger STM32 chip with more GPIOs has been used. This is capable of all the IO and keypad scanning. It also has more flash and RAM (512K of flash and 64K of RAM). As the STM32F103 chips are all very compatible there are a few options for flash and RAM simply by fitting a different variant of the chip.

I've also added the connections for an OLED display on this PCB so if the CQ-1 VFD is broken then you can use a dot matrix OLED display. The 23V dc-dc converter can be left out if the OLED is used, as well.

Here's the first populated PCB in a case:

It fits nicely, the wires coming out are the ST-LINK programmer wires. The USB power goes in through the battery cover latch hole which I filed out so the USB socket was accessible. The circuit should run off a single AA battery as well (the prototype did, but I've not tested the new PCB yet). I'll need to print a connector for the positive terminal of the battery, the negative is a spring on the keypad PCB.

Here's the front side of the PCB:

Again the beeper and VFD tube are from a CQ-1. The keypad PCB is mounted using 0.1" plug and socket connectors, the spacing was perfect, even though the original CQ-1 uses copper strips held together with plastic.

The PCB needs a modification as I got one signal wrong, the keypad connector is out by 0.1" for five connections, the 23V dc-dc converter inductor whistles, and the mounting hole for the beeper is too small, but other than that I'm very happy with it. It fits the case well.

There's a few things left to do. The display is a bit dim, which is probably the 23V dc-dc converter needing to be 26V or so. There's a lot of code to write if this is going to be the same as a CQ-1 but there's a rudimentary stopwatch and integer-only calculator, together with a clock you can't set, but writing the code is the fun bit...

See it working here:

Some pictures of it operating:

The USB cable that is powering it and the programming wires that come off a header on the PCB:

And displaying some characters that the original just can't manage:

Saturday, 18 July 2020

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 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.

Monday, 13 July 2020

Sharp P-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.

Thursday, 9 July 2020

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...

Tuesday, 26 May 2020

Word Die

Word Die

After being shown this:

I decided to make a wooden version:

Saturday, 23 May 2020

Inhaler Cover

Inhaler Cover


Should Have Checked Thingiverse First

If you have an inhaler you may find that you press the canister in your bag or pocket. This isn't good, so a cover or box would be a good idea. years ago I made a wooden cover for an inhaler. It had a swivel lid and was quite large as it held the instructions as well. Unfortunately it has broken so I had a go at a 3D printed version. This is a simple push on cover that prevents the mechanism from actuating.

I printed four test parts that were only 10mm high to check that the part would actually slide onto the inhaler (the first two wouldn't and the last was a slimming down of the outer profile). I then printed the full height version and it slides onto the inhaler nicely, with enough friction to stop it falling off.
All good then. 
Then I wondered if someone else had done something similar and, well, yes, they have. Oh well. I should have checked Thingiverse first...