All This to Get Back Where It Started

 All This to Get Back Where It Started

Storing scrap PCBs is all well and good but what do you do with them? After buying a vacuum desoldering machine (wonderful piece of kit), I decided to dismantle the scrap PCBs that I'd been holding on to for years. One of the PCBs I removed components from was a VCR which had a large vacuum fluorescent display on it:

Underneath the display was a controller chip:

It is a Mitsubishi M50957-199SP. I didn't know what that was, but fortunately there is data on the web about it, and it turns out to be a 6502 micro-controller that goes by the family name of MELP. It's a mask-ROM device (the 199SP denotes the actual code loaded into the ROM) and has several peripheral devices embedded in the package as well as the 6502 processor. It's in a slightly odd 64 pin package with a smaller than 0.1 inch pin pitch. It has built in high voltage drivers for the VFD, which would be nice, if it wasn't mask-ROM based. That is a real show stopper if you want to do anything with these chips. Mitsubishi, though, built in a 'microprocessor mode' which can be set up at reset by pulling a pin high. That then causes the address and data busses to be sent out of what would have been IO ports, together with a couple of control lines (RW and SYNC). That allows the device to run off entirely external memory. OK, we can do something with this device now...

I really only wanted to fiddle with the chip, so started thinking along the lines of a 'trainer' or development board, something like the Sinclair MK14 microprofessor or AIM 65. After a few days of musing and then a couple of weeks of PCB layout I came up with this:

Well, yes, there's two of them. The one of the left is the first populated PCB, and it has the VFD and MELP from the VCR. There's a keypad made from MX style keys, they are much nicer to type on than tactile switches. The VFD requires a high voltage to run, so there's a DC-DC converter for that. The VFD filament requires a driver circuit so I included that, but ended up just using 3V3 on this VFD. The high voltage is switched to the VFD using two MAX6921 driver chips. There's an SD card reader for storing programs and an OLED display for extra information when a VFD is fitted and as the only display if a VFD isn't fitted. I only have one of these VFDs, after all. The VFD is mounted on a plug-in adaptor board (perfboard here) so in theory you could attach a completely different VFD if you had one. 

The whole thing is pulled together with an ARM STM32H742, which attaches to the external address and data bus of the MELP and emulates external ROM and RAM (I suppose it actually only emulates RAM, but the MELP doesn't know that). This ARM is a bit of a beast, it runs at 480MHz, has 2MB of flash and 1MB of RAM. It was a bit of a pain to get going as it doesn't have very good (or indeed any) support in the Arduino IDE. I ended up adding my own board definition to the IDE for this PCB. It's odd that there's no generic STM32H7xx board as there is for the STM32Fxxx devices. I suppose they are more common due to the blue pills. This device is also quite pricey, at about £9 each. I noticed the price when I inadvertently ran one chip at 5V for a few days. It turns out that they will run at 5V, but not for long... Then you have to spend an hour or so desoldering a 100pin QFP before fitting a new one.

The VFD has a lot of segments, and so I had to fit two MAX6921s. 

It means there is plenty of scope for displaying useful information about the address and data buses.

So far I've built some code that drives the 6502 through a short program. This program sets some configuration bits and then dumps memory to a fixed address. I wanted to see if I could change the MELP mode to one that would allow access to the mask ROM within the device, but it does look like the internal ROM is not accessible in any mode that 'microprocessor mode' can access.

The code does, however, drive the MELP and supply data from emulated memory when it needs to. You can see the program running in this video:

As I had five PCBs I had a look on eBay for more MELP chips, and did find some. They are slightly different, M50959-133SP, which has more on-board RAM and a different mask ROM. They do work though, so I have enough for the other PCBs.

I can also use this PCB to test VFDs as it has segment/digit drivers and a high voltage adjustable supply and a filament driver. All I need to do is make an adaptor board for each different display type.

As well as a trainer for the 6502/MELP, I'm thinking of adding code that allows this to be an ARM trainer as well. It's probably not going to be as simple to look at ARM peripherals and do a spot of machine code programming as the 6502, but could be fun fiddling with a 480MHz processor at machine code level. The SD card reader means that you don't lose anything you've done, and you can even build large programs on a PC then transfer it over on a card.

DIY DRO

All Gauges Attached to DRO

The remaining gauges have been attached to the DRO. There's now 3 gauges on the lathe and three on the mill. All of the gauge channels are now populated and attached:

Each card has a PIC on it that converts from the gauge serial protocol to I2C. The main ARM processor then interrogates each of the relevant gauge channels over I2C and displays the values.

Each of the gauge channel PCBs is identical, the firmware is almost identical, the only difference is the I2C slave address, which is 0x30 and 0x40 for each pair of PCBs on the same I2C bus. There's three I2C busses.


The main DRO PCB has an ARM processor on a commercial LPExpresso card:

The TFT screen is a touch screen and there's a menu system running on it. The DRO can be set to display the lathe channels or the mill channels. The smaller OLED displays then show the appropriate axis tags. When running in lathe mode the two X axis values can be added together.

The gauges have been attached with 3D printed plastic mounts. I may re-make them in metal if they aren't rigid enough.

The gauges are held in clips that can have screws clamping them from the sides:

 I've removed the buttons from the gauges if they were pressed by the clips. The buttons aren't needed and you also don't need to read the displays as the DRO does that.

The batteries aren't needed either as the DRO channels all have a 1V5 power supply. The gauges run from that and are powered all the time the DRO is powered. The power down of the gauge display doesn't stop the serial data stream, either, which is nice.

 The mill X gauge is mounted in a similar way:

The Y as well:

And the Z gauge:

The lathe bed gauge was one of the more complicated mounting arrangements.

I've started to use the DRO and it certainly makes measuring things much easier. I need to check that the gauges are working correctly by comparing with a dial indicator.

Gauges Working on DRO

I've got gauges working again on the DRO, currently two of the cheap Chinese calipers using the 24 bit data output have run on two axes of the ARM based DRO. There's a few minor PCB errors but nothing major. The switches should work soon. The only major part not working is the TFT display and that could be a code problem, or a non functional display. I've switched to an SPI TFT display, and I only had a non touchscreen version. I'm waiting for the touchscreen ones to arrive. Based on the parallel display experience, I think about 50% of these displays don't work out of the box and of the remaining 50% only half have the advertised display controller chip on them, the other half have whatever chip was hanging around when the displays were built.

Here's the ARM DRO with a channel working:

The daughter board is plugged in at the bottom left. That has a PIC 12F1822 on it that converts the data form the gauge into I2C which the main board polls in its idle loop. There's room for five more boards across the bottom of the main board.  As you can see the gauge reading is on the Z axis in this picture.

I've had two 24 bit gauges working, the third one I had wired was of the 2 x 24 bit packet format, which did work in the past but failed for some reason when I tried it. I'll make some more daughter boards and debug the problem..

The more expensive gauges I got as a trial are ironically less stable when powered off the DRO 1V5 supply so I may move to cheap Chinese gauges as they are also 0.01mm resolution and seem more tolerant to my 1V5 supply.

Change of DRO Direction

 I've spent a lot of time recently trying to get the PIC16F18875 working as the main controller on the DRO. It's sort of working but there's problems. Whenever I make a simple code change (something like changing a /1000 to a /10) the code sometimes just fails to run. This would be fine, as it's probably a bug, well maybe, but as the Microchip debugger also doesn't seem to work, it's all a bit of a disaster. Looking on the web it seems this is a fairly common experience. It's a shame as I've used PICs a lot in the past and they were useful little devices. Anyway, I've decided to ditch the PIC and try something else. At the moment he plan is to use an LPC1114 ARM based device. This has the added advantage of more flash (32K), similar clock speed and lots of GPIO. Unfortunately it is a 3V3 device and that means I will have to deal with level shifting and add a regulator.  Anyway that's all OK, just a bit more complexity and if it works I can lay out a mostly 3V3 PCB with the LPC on it.

The other thing about the LPC chips is that they don't come in any DIP packages. Not that are available to buy anyway. So I have tried to mill a QFP48 footprint that is one of those used by the LPC1114. Once I used a 0.1mm cutter and a shallow depth of cut, I managed this:

It's not perfect, there's a bit of copper that hasn't been milled away. I think I may be able to sort that with either a second milling or slightly more depth. Anyway, it looks to be possible, so that's the plan.
Those pads are 0.5mm between centres, by the way.