Memotech MTX RAM Fault Diagnosis / Repair

Courtesy of Martin Allcorn

System Description : MTX 512 Serial No.?????, 4000-?? computer board with 32k DRAM chips.

Problem Description : Unbricking a brick

There have been a couple of failed attempts at upgrading an MTX500 (32kb) to an MTX512 (64kb) by removing the 32k DRAMs and replacing them with 64kb ones. Both Andy (see here) and myself (see here) have tried, and failed, with this upgrade, but, other than poor workmanship, there does not seem to be any reason why an upgrade like this can't be done.

Martin Allcorn has recently (July 2014) managed to recover a faulty MTX500 and upgrade the memory to 64kb by doing just that.

It is encouraging that Martin has been successful in replacing the RAM and should give me the impetus to revisit my failed upgrade and see if I can recover the situation, Martin has kindly documented his MTX problems and fixes, it is posted here in the hope that others will find it useful - particularly if you have bodged a memory upgrade like me :-(

MTX500 to 512 memory upgrade and repairs

   -   the saga of the Bricked MTX

Background

Back in the 80's early 90's, I had an MTX500 that was upgraded to 64k and RS232 so I could run CP/M and the FDX. When the FDX died in the mid 90's, the MTX went to a family member for their children to play on. Eventually it went out of use and ended up in a loft.

After my Grandfather died, I inherited his MTX500, but that had no software. A few years back the upgraded MTX and one box of software was located and returned to me. However, when I went to try the software out, the expanded system would only work with the expansions removed.

At that point I decided to upgrade one of the 2 500's to 64k on the motherboard. I de-soldered all the RAM and the LS157 multiplexers. The idea was to use 2 32k Static RAMs and some HCT logic on a small daughterboard to make up the 64k RAM.

For whatever reason that didn't work, it looked ugly too. So I went to plan B and removed the PAL and ROMs and put all the memory on an external card. I worked around Memotech's paged ROM system by using a 128k flash chip divided into 8, 16k pages, with the OS ROM programmed into the lower half of each page.

The RAM was initially the 2, 32k static RAMs. That's the red function keyed MTX on the MAGROM development page. The red keys were to remind me which MTX needed the expansion card plugged in to work! The final version of that card has 4 RAM (2x 32k and 2 x 512k) and 1 ROM sockets and gave the system 784k RAM and 128k ROM. Obviously the card sticking up from the side like that wasn't a long term solution, but did lead indirectly to the development of MAGROM.

Initial Fault Diagnosis and Repair

At this point the MTX display started to distort and wobble after being on for a while, the same symptoms it had with the original 32k expansion board fitted. With a CMOS Z80 and CTC fitted things got better so I thought it may be a power related issue. I replaced the 5v and 12v regulators and both 4700uf capacitors which improved the situation, but didn't quite fix it.

The next step was a much simplified 64k only RAM card, but to return to using the original EPROMs, this particular MTX was factory modified to use 2564 EPROMs instead of mask ROMs, so there were some cut tracks and yellow wires to accommodate the different pin-outs.

Fault no. 1. occurred at this point, I managed to put the PAL back in the wrong way around and thoroughly cooked it. Since building the standard logic based expansion card, I'd acquired a more modern programmer as was able to program an ATF16v8 PLD to replace the PAL.

The true source of the power problem was revealed when I happened to touch the 10W resistor R62, it was HOT, indicating the real source of the power problem was the TIP 2955, which I'd not replaced when I did the regulators. It also explained why the CMOS CPU swap helped, as the reduced current consumed by that device reduced the rate at which R62 overheated.

Having replaced the TIP, all of the power related problems went away so fault no. 2 was fixed.

[See here for the diagnosis and repair if a similar TIP 2955 problem]

Memory Upgrade

Dave generously provided some 6164 DRAMs, so that I could install those on the board along with some new LS157 multiplexers and get rid of the expansion card. With a suitably programmed PLD replacing the dead PAL and the motherboard links set for 64k Drams, I put the ROMs back in their sockets, and got . . . . . . .

nothing!

just the black screen and hum of a bricked MTX.

A Z80 doesn't NEED RAM to work with so I wrote a custom ROM, based on some of the early MAGROM code, that initialised the VDP, turned the sound off and then displayed the results of some very basic tests of the RAM. With this fitted onto the expansion card, and using the new internal RAM it revealed that the visible 48k of the 64k of RAM was working and seemed reliable.

It's not possible to re-program the old TI 21v EPROMs with modern programmers, so I re-wired the ROM sockets to use modern EPROMs and put the 2864 EEPROM with the test program into the OS ROM socket and got the expected result. So I programmed 3 2864s with the full MTX ROM set and plugged them in, I had a working 64k MTX512. YAY!

. . . . . . . . . . .  for about 3 minutes until it crashed.

There then followed a couple of weeks experimenting with the timing chain.

Part of the RAS/CAS timing for the dynamic RAM goes through the PAL and part through the on-board LS logic. As the PLD I was using in place of the PAL has a much faster response time typically 3ns (and 15ns worst case) instead of the original device's 25/35ns, I thought there may be a RAM timing issue.

The RAS delay is fixed as it is MREQ delayed by being passed through 2 LS04 inverters. In generating CAS, MREQ goes through the PAL, 2 inverters and then a resistor-capacitor delay at R14/C6 before the multiplexers are switched and then a further delay with R15/C5 and 2 more inversions before CAS is generated. I was hoping that increasing the resistor/capacitor delay at R14/C6 I could restore the original timings. The theory being increasing that delay by 20ns would restore the timings to their original values.

I tried numerous variations, based on some formulae found on the net, and some additional values Dave came up with when he ran the timing chain through SPICE. Sometimes it would work for an hour or more, on other it would need 3 or 4 resets to even start. But I never found a stable solution. So eventually gave up and put the original value parts back, as there had to be another problem.

As part of the MTX+ project Dave and I have built diagnostics cards to enable the status of the system to be seen in the event of problems. So I put together a small adaptor board to enable me to connect the MTX+ diagnostics board to the MTX500. I also made a 2Hz clock to fit in place of the 74HC04 chip at 9D on the board enabling me to watch on the indicator lights each clock cycle as the system booted. ("Ready" would take around 2 days to come up at that rate).

[For details of the 2Hz clock, see Martin's post on Memorum]

That revealed fault no. 3 :  address line A7 was intermittently stuck high. A check of the circuit diagrams in the manual revealed that there are only a few places where A7 comes into contact with board components. The CPU and memory, and the I/O port decode logic.

I removed the socketed parts, (the Z80 and ROMs) and the RAM multiplexers, then tested with a multi-meter. A short was present, an indication that the I/O select could be the culprit.

In the I/O logic, A7 is connected to pin 13 of the 74LS27, the pin next to the 5v power supply. There were no visible external shorts, so I replaced the chip. The stuck A7 problem vanished. Fault no. 3 was fixed.

Since that chip is located on the MTX motherboard right next to the PAL it's possible that the chip had been damaged when I cooked the PAL in the socket next door.

Having fixed that, the diagnostics board was able reveal fault no. 4 : once the system was warm, A12 would start to stick high too. A12 is only connected to the Z80 and memory.

After much searching, I found that one of the tracks that had been cut in the factory to fit the original EPROMs was bridging when warm, there was probably a minute fleck of foil that I'd disturbed when I made the extra changes to fit the modern EPROMs.

However, having widened the cut the problem went away fault no. 4 was fixed. Since then there have been no further problems of any kind. (and I've done considerable amounts of MAGROM “testing” to make sure!)

A selection of photos from the process can be found on the Smörgåsbord photos page

The Moral of the story:

It IS possible to upgrade an MTX500 to 64k, it should only need new RAM chips and a new PAL/GAL/PLD and the motherboard links being correctly set.

Depending on the RAM it might need a timing chain modification, but with the chips Dave supplied that wasn't needed.

Cooking the PAL in the process is not to be advised.