MTX 512 (debugging thread)

User avatar
Dave
Posts: 793
Joined: 11 Aug 2012 18:16
Contact:

Re: MTX 512 (debugging thread)

Post by Dave » 09 Jul 2020 16:17

It's obviously been a year since you read Mark's post a couple of entries above this post.

Mark gave you some tips there on the -5V question, are you sure that the -V (-12V) line is OK?

The video RAM is the only user of -5VDC

regards
Dave

GozdniJezek
Posts: 21
Joined: 07 Jun 2019 20:49

Re: MTX 512 (debugging thread)

Post by GozdniJezek » 09 Jul 2020 17:31

Sorry, I forgot to mentioned, that the ZD3 is the second diode that was replaced and R60 is also reading 1kΩ. Will check the voltage on D16 or D18 anode leads and for any other shorts. I'm sorry for asking stupid questions, should have referred to the previous post. Thank you for your input. :)

I will report on the results. :)

User avatar
Dave
Posts: 793
Joined: 11 Aug 2012 18:16
Contact:

Re: MTX 512 (debugging thread)

Post by Dave » 09 Jul 2020 17:44

Hi,

the questions aren't stupid, it just helps to know that you have followed earlier advice, including checking for shorts at the locations mentioned

regards
Dave

GozdniJezek
Posts: 21
Joined: 07 Jun 2019 20:49

Re: MTX 512 (debugging thread)

Post by GozdniJezek » 28 Jul 2020 15:58

Hello, as promised an update. I'm not so sure that the -5V issue was the real culprit, all of the voltages check out now. We've replaced all of the 4116 video ram with modified 4164 which should not use the -5v line or 12V (we changed the ZD3 diode (second time) with one that now gives, -5.3V without rams, I hope the voltage will lower under the load, but according to the datasheet its still ok) (during the limited testing the voltage did not collapse anymore, but need to do more testing with 4116). The results can be seen in the picture although it might be related to the 15ns ram (is this fast enough?). But the most pressing concern is that the image disappears after a second or 2. I suspect that the video board might have an issue, does this sound reasonable? Any additional pointers would be greatly appreciated. This is turning into a rabbit hole, and I'm starting to doubt everything. I might be missing something obvious, so any pointers are most welcome.
videoRams.jpg
videoRams.jpg (174.6 KiB) Viewed 142 times
videoScrambled.jpg
videoScrambled.jpg (110.84 KiB) Viewed 142 times
videoGone.jpg
videoGone.jpg (131.46 KiB) Viewed 142 times
4164 rams.jpg
4164 rams.jpg (189.49 KiB) Viewed 142 times
tl;dr:
So my rationale is:
-(image 1)the video rams are not working properly, maybe it's related to the 15ns timing, maybe its something else, need to try with 4116 ones (i did not had them at friends house).
-(image 2) scrambled and dis spearing video, my noob opinion is that this might be caused by a bad video board? I intend to try with RF output, to see if anything changes, I was also thinking on recapping the video board.

Any suggestions and observations are most welcome.

Martin A
Posts: 459
Joined: 09 Nov 2013 21:03

Re: MTX 512 (debugging thread)

Post by Martin A » 28 Jul 2020 19:02

Just for reference, those rams are 150ns, not 15. Back in the 80s, 15ns ram was the sort of stuff you'd find in a Cray mainframe. :o

When the MTX was built, 200ns for the rams would have been normal, so 150ns is faster than required definitely not too slow.

User avatar
Dave
Posts: 793
Joined: 11 Aug 2012 18:16
Contact:

Re: MTX 512 (debugging thread)

Post by Dave » 28 Jul 2020 20:28

As you have changed out all of the VRAMs for sockets, there’s always the chance that there’s an issue there. If you haven’t already done so, I suggest that you remove the VRAMs and use a meter to verify connectivity between them and the VDP ss as per the drawing.

I.e., check for continuity as per the schematic and there are no shorts that shouldn’t be there

Regards
Dave

User avatar
1024MAK
Posts: 612
Joined: 24 Dec 2012 03:01
Location: Looking forward to summer, in Somerset, UK

Re: MTX 512 (debugging thread)

Post by 1024MAK » 29 Jul 2020 13:05

Apart from the data in (D) and data out (Q) pins (2 & 14), ensure by continuity testing (or by using the 200 ohm resistance range) using a multimeter that all like numbered pins on each video DRAM socket are connected to all the other video DRAM sockets. So pin 3 on one video DRAM socket should have continuity to pin 3 on the other seven video DRAM sockets.

Also test the relevant data pins to the video chip. As well as all the address and control lines.

The RF/UHF signal is derived from the composite video signal, so although it is a good idea to try this, don’t be surprised if you get similar results.

In your pictures, it looks like a loss of synchronisation signals that is causing the picture to break up and disappear.

Mark

Post Reply