The Memotech MTX Series
System Description : MTX512-S2 Serial No.33003, 4000-04
computer board with 256k DRAM chips.
Problem Description : Faulty Video Display
I bought an MTX512S2 with 80 Column board and SDX disk
controller/drive. I was aware that it had a problem with the
on-board video processor output, the symptoms described sounded
typical of VRAM failure(s),
so I was not overly concerned. The computer has an 80 Column
board and SDX controller with a CP/M ROM, the system could
successfully run CP/M and drive the 80 Column monitor output,
indicating that the computer board itself was working.
The image above shows the status of the output from the VDP
on booting the MTX without the SDX controller with CP/M ROM
connected. Initially expecting a VRAM fault, I opened the case and
inspection of the internals revealed a large amount of corrosion
on the legs of various chips, including some of the VRAM and the
TMS9929A VDP. I initially thought that the MTX may have been
stored in a relatively harsh environment, such as a loft, where
it might have been exposed to condensation etc. But that is not
the cause of the problem - the 80 Column board and most of the
MTX motherboard were in pretty good condition. On closer
inspection, it is clear that the corrosion is confined to one
area of the board - mainly around the VDP and the VRAM chip legs.
The VDP and VRAM, and the edges of some of the
adjacent ICs, showing corrosion on the legs.
appears that something "nasty" has been spilled onto
the VDP and some of the VRAMs, there are
marks on the chips themselves and a few other marks
on the board which look like spill residue. Where it
has hit the legs, it appears to have caused the
The keyboard PCB in the upper half of the MTX shell
shields the computer board PCB from spillages over
The UHF modulator is more
corroded than is typical, it looks like the spillage
has been through the rear of the case, over the
modulator and onto the computer board and ICs.
The image at the top of the page shows how the video
display looked the majority of the time after
booting the MTX.
When pressing down gently on the VDP, the display on the screen often changed - sometimes
as shown, and often improving
markedly, suggesting that there may have been bad
contact between the VDP chip's legs and the socket.
That would not have been a surprise, given the state
of the legs and socket contacts!
I attempted to remove the VDP for closer
inspection, when I did that, many of the legs disintegrated - leaving a number still in the
The underside of the TMS 9929A VDP - missing a
The socket was in a pretty bad way too, although the
computer board itself looked OK
I cleaned up the board as best I could, removed the
remnants of the old VDP from the socket, and
"borrowed" the VDP from another MTX, but the
symptoms were the same as before.
The screen corruption was unchanged and continued
to vary significantly when pressure was applied to
the VDP in its socket. The obvious next step was to
replace the VDP socket.
Andy Key generously sent me a replacement VDP
and 40 pin DIL socket to enable me to progress the
diagnosis, and hopefully repair, of the system.
The first step was to remove the old socket, this
was a little harder then removing an IC as you can
not snip off the individual legs, but it was not too
difficult with the aid of a
After cleaning up the board a little more, the new
socket was soldered into place, and after checking
for shorts between adjacent pins, the replacement
VDP was installed.
On powering up the MTX, the video display was the
same as the original fault, I had not expected that
replacement of the VDP and its socket would cure the
problem, but at least I had not made things worse.
At this point, the system correctly responded to
<ctrl><G>, i.e., the computer produced the expected
sound tone. If you look closely, you can make out
what appears to be a very corrupted "Ready" prompt
in the edit region.
Having a corrupted, but relatively stable, video
display at least gave me the opportunity to carry
out further tests as described in the
Manual. The manual advises that disabling each VRAM
in turn by grounding pin 14 (via
a 10 ohm resistor) can help identify faulty VRAMs.
I used test
my Logic Analyser to connect to pin 14 of each
of the VRAMs and Pin 16 (ground) on one, then
grounded each in turn using a short jumper wire/resistor.
I found that at least one VRAM in position 6F was definitely
faulty, the display improved as shown.
The majority of the display area is now clear,
although the "Ready" text is still
The next step will be to remove the faulty VRAM, install a DIL socket and a replacement
The second line of text is this display is a corrupt
"Mistake" error message, this results when any BASIC
command is entered.
This is particularly odd as
the keyboard itself works fine in CP/M mode -
perhaps there is a BASIC ROM fault too?
way to remove ICs soldered onto the board is to use
a pair of fine nosed snips and cut though each leg
in turn, taking care not to damage the PCB. Using a
solder sucker, the individual legs can then be
de-soldered and removed without using too much heat
which could potentially damage the copper tracks on
should then be cleaned up to remove any excess
solder before fitting a new IC socket to reduce the
potential for damage to the new IC and making future
David Kimberlin-Wyer kindly sent me a couple of
compatible replacements (AMD AM9016) for the ITT 4116
New socket installed and replacement VRAM
on other compatible VRAM replacements).
After fitting a new socket and VRAM, the display improved as
As you can see, the display is much
improved but the "Ready" prompt is
displaying "Peady". I don't think that
that is a character display problem as typing "R"
at the keyboard also results in a "P"
which is interpreted by BASIC as a "P"
rather than an "R".
In addition to any other faults that may be present,
I think that there is also another faulty VRAM.
Using the same process as described above to
disable each of the VRAMs again, when the RAM in
position 7F was disabled, the display was as shown.
The next step will be to replace that VRAM too.
With a second VRAM replaced, the "Peady"
message and the keyboard problems are unchanged. The
keyboard still works fine in CP/M mode, but is
unusable in MTX mode.
When it is displayed, the "Mistake"
text is still corrupted but there are no more VRAMs
where disabling them shows signs of improvement to
the corrupted text, it may be a case of
replacing the rest of the VRAMs and taking it from
attempt to identify the nature of the keyboard
errors, I made a quick table to compare the typed
key with the character echoed to the screen;
in all but one case, in each of the 20 or so errors,
the ASCII value of the key reported is off by 2.
corresponds to an error in the second bit of the
data bus, i.e., bit "D1" appears to be stuck "low".
As noted earlier, this could have been caused by a
ROM problem, to try and eliminate that possibility,
I tried swapping all of the major socketed chips -
ROMs, CPU, CTC and VDP - to no effect.
As the schematic shows, the VRAMs are not
directly connected to the Z80 data bus - data
between the VDP and the VRAMs. It is possible that a
fault between the data bus and the VDP could be
causing the errors - possibly a short between D1 and
ground holding D1 "low".
I have ordered up some of the same type of DRAM as
David gave me, from ebay.com - I will (hopefully) be
able to make progress when they arrive.
OK - the replacement RAM has arrived, although I
intended to replace all of the remaining RAMs, I
wanted to do it one at a time to see if I could
identify a particular RAM as being faulty.
I replaced the remaining RAMs in the following
order : 4G, 5G, 6G, 7G, 5Fand 4F. On replacing
each one in turn, I powered on the MTX and entered a
single REM statement, in each case, the display
shown was produced.
That is, until I got to the very last RAM in
position 4F - on powering on the MTX - the system
now operated correctly - I was able to correctly
enter BASIC statements and the resultant display was
correct. (The last VRAM replaced was the closest to
the site of the spillage ingress.)
With apologies for the poor quality
iPhone photo - herewith the display of a now healthy
The replacement VDP in its new socket, along with
the set of replacement VRAMs in their new sockets.
.... and the parts they replaced
- the leftovers !
And finally, the MTX512S2 computer board back in its case along
with the 80 column video board.
If you zoom in on the picture, you can see that
the board looks in much better shape than before.
As you can imagine, by the time I got to the last
VRAM, I was thinking that it was unlikely that a
VRAM fault was the cause of the secondary problems
Much to my relief though, replacing the last VRAM did
indeed fix the problem. Whilst I am obviously very
pleased with this outcome, I am struggling to
understand how a faulty VRAM could cause erroneous
key presses to be reported - particularly as the
VRAM does not connect directly to the MTX data bus.
Update : I think I know why this
was now -
see here for details