Resurrecting an MTX500.

[Dave]

Hopefully you have the board back in the case? The regulator heatsink really needs to be fixed to the case to allow the heat to dissipate.

That said, even when running normally, things get pretty warm, particularly the VDP


With lack of use, the keys do get a bit “jittery”, they often get better just with exercise (don’t we all!)

Spend a bit of time just working the keys repeatedly, I bet you see an improvement

[stephen_usher]

Hopefully you have the board back in the case? The regulator heatsink really needs to be fixed to the case to allow the heat to dissipate.

That said, even when running normally, things get pretty warm, particularly the VDP


With lack of use, the keys do get a bit “jittery”, they often get better just with exercise (don’t we all!)

Spend a bit of time just working the keys repeatedly, I bet you see an improvement

Hehe. Yes, I've been exercising them. Some have got a little better.

As for the circuit board, yes, it's in the case and all bolted down.

[stephen_usher]

Having replaced the two LS273s and used switch cleaner/lubricant plus a bit of key tapping I have a working keyboard. It's not perfect as I get double characters on some keys now and again but it's usable. I also replaced the three LS244 chips as I no-longer trust them as they've been through a lot during the fault-finding.

I think I may have a latent memory fault although it passes the diag ROM RAM test. I may have to look into learning enough Z80 assembler to write a "March" memory test. (Write zeros from base of memory to top, from top read each location comparing with zero and set to 1. From the bottom read each value and check it's 1 and set to zero. Read all locations and make sure they're zero. This detects transition errors and addressing errors.) I'm guessing the diag ROM merely writes and then reads, which will only detect one type of error.

Why do I think this? If I load "STAR.MTX" from the CFX the game runs but slowly corrupts the display (star field get stuff left behind and numbers get printed in the wrong place on the screen) and eventually crashes.

P.S. Thinking about it there is a complication for the march test, you have to test a whole chip at once, so you'd have to page the "high" memory in and out during the test.

P.P.S. CP/M is unreliable and crashes not long after it starts, within a minute at most.

[Dave]

I wonder if there might be a problem with the DRAM timing circuit?

Assuming that all the chips in the circuit are working, it might be worth checking C5 and C6 for damage. With all the work on the machine, they might have taken a knock? I had a weird RAM fault that turned out to be a cracked capacitor

[stephen_usher]

I wonder if there might be a problem with the DRAM timing circuit?

Assuming that all the chips in the circuit are working, it might be worth checking C5 and C6 for damage. With all the work on the machine, they might have taken a knock? I had a weird RAM fault that turned out to be a cracked capacitor

They're both newly replaced, along with 5D and 6D.

[Martin A]

I'm guessing the diag ROM merely writes and then reads, which will only detect one type of error.

The daig rom writes an XOR of the high and low bytes of the address to each location as it fills the memory, then reads back to check the correct value is present. The early version wrote a fixed pattern but that didn't detect address issues. Running with the socketed 157 on the test MTX removed still passed the memory test, when it should have failed

The revised test will detect addressing errors and plain broken or missing memory. it's not guaranteed to detect stuck bits or bit rot, because the pattern written is the same each time. But it seemed a fair compromise given the restrictions of programming with no ram available. I'll try having a look at the code over the weekend to see if it's possible to invert the data on alternate passes to help with stuck bit detection.

However, you might be able to test if the memory is decaying using the monitor. Use the F option to fill a block with a test pattern, maybe FF AA 55 or 00. Then use D to dump the same block and see if there's any changes

[Dave]

I wonder if there might be a problem with the DRAM timing circuit?

Assuming that all the chips in the circuit are working, it might be worth checking C5 and C6 for damage. With all the work on the machine, they might have taken a knock? I had a weird RAM fault that turned out to be a cracked capacitor

They're both newly replaced, along with 5D and 6D.

What are their values ?

[1024MAK]

I'm guessing the diag ROM merely writes and then reads, which will only detect one type of error.

The daig rom writes an XOR of the high and low bytes of the address to each location as it fills the memory, then reads back to check the correct value is present. The early version wrote a fixed pattern but that didn't detect address issues. Running with the socketed 157 on the test MTX removed still passed the memory test, when it should have failed

The revised test will detect addressing errors and plain broken or missing memory. it's not guaranteed to detect stuck bits or bit rot, because the pattern written is the same each time. But it seemed a fair compromise given the restrictions of programming with no ram available. I'll try having a look at the code over the weekend to see if it's possible to invert the data on alternate passes to help with stuck bit detection.

However, you might be able to test if the memory is decaying using the monitor. Use the F option to fill a block with a test pattern, maybe FF AA 55 or 00. Then use D to dump the same block and see if there's any changes

If you want to confirm if the DRAM is being refreshed, limit the CPU to a short loop for at least 20ms. Then check the contents of memory.

Mark

[stephen_usher]

They're both newly replaced, along with 5D and 6D.

What are their values ?
[/quote]

Sorry, I mis-understood. I thought you meant chips in the locations on the motherboard and not the capacitors. I will have to check them tomorrow as I'm out this evening.

[stephen_usher]

If you want to confirm if the DRAM is being refreshed, limit the CPU to a short loop for at least 20ms. Then check the contents of memory.

Mark

It looks like I'm going to have to learn how to use the MTX assembler doesn't it?

The first test may be swapping the CPU as I have at least one unused spare Z80B.

Last night I did write a rudimentary march memory tester in BASIC. Assign an array (8192 elements), fill it with zeros, read from the top and set each value to 32768. Read from the bottom and set each value to 0. Read all the values to see if they're zero. That worked fine. I could really work out what value sets all bits in a floating point number. Is the format the same as is used on the Spectrum?