Sharp MZ-80K help needed on repair

[Mark1960]

With the z80 running NOP test there will be an instruction fetch followed by a refresh cycle for each NOP. Both should start at 0, so the low address lines A0 to A6 would look regular but A7 and up will be zero during refresh. I think this is why A7 shows continuous line at 0v.

It might be possible to use a second scope channel to trigger on M1, but probably not worth the complication at this stage.

[pudwink]

Checked IC 35 as far as I can tell it looks right took all memory out still pulsing text running through the screen.
Now I am guessing that the bigger the distance between the wave form the slower it is so on that idea IC 44 pin 5 small spacing then 16,18,3,5,7 getting bigger 12 and 9 got smaller.
IC 45
14 fast 16 and 18 slower then 3 through to 9 got faster.
Hope I got that right.

[Mark1960]

The pulsing on the display will probably be caused by the z80 reading from video ram addresses as it runs through the address space. I think in normal operation it would only access video ram during frame blanking, detected using the 8255 input.

[Timbucus]

Originally Posted by Mark1960

The pulsing on the display will probably be caused by the z80 reading from video ram addresses as it runs through the address space. I think in normal operation it would only access video ram during frame blanking, detected using the 8255 input.

Yes I was thinking that as I watched the screen looks just like my Triton when you do the same and it is a cyclic repeating effect.

[SiriusHardware]

What shall we focus on now? Why we don't seem to be able to run code from the ROM?

Pud, with the RAM TEST EPROM fitted and the NOP rig still in place, can you get scope pictures of:

ROM pin 20 (CS0, ROM chip enable)

IC51 pin 6 (Enable signal for buffer, IC50). Reads from both system RAM and ROM pass through this buffer.

[pudwink]

Here are pics asked for I have not got any resitors so going to try a shop today otherwise I will have to order some.

[pudwink]

Hi all
Major Major progress I went to the shop to get some resistors and while I was there I got some SN74LS241N to replace the wrong ones the other guy sent me which he said (they will work) and guess what no more corrupted ram screen and better still with the resistor fitted the program is now running.

[SiriusHardware]

Another good call by Mark! So, what does the RAM TEST EPROM tell you about the state of the RAMs now, if you put it all back in? If it's running properly I think you should probably see the first character on the screen continually changing even if nothing else on the screen moves. (That character indicates which block of the RAM it is currently testing).

[pudwink]

yes it is running properly I think but it does not give you a constant report of which ram is showing as bad It changes its mind depending on when you turn it on.

[SiriusHardware]

If the RAM TEST ROM is starting up every time now, it may be worth swapping the MROM in just to see what that does now as you have replaced a couple of things since you last tried it.

If it still doesn't work at all we'll stick with the RAM TEST EPROM for now as that does not depend on working RAM to be able to run, whereas MROM does.

[pudwink]

Ahead of you already tried the MROM just ramdom characters

[SiriusHardware]

So apart from the fact that it does not show consistent good / bad states for the state of each RAM, do you feel that the RAM test code is running normally - especially - with the first character on the screen changing all the time, showing that the program is continually running?

If that character is not changing all the time then it means the program is starting, but getting stuck somewhere along the line.

If it is genuinely running then maybe we can use the activity generated by that program to try to look at signals in the system RAM area.

[pudwink]

Yes character is changing 1 through to 3 so looks like it's running fine.

[SiriusHardware]

That's really good - as you say a great step forwards as it opens up the possibility of writing bits of test code to check out specific parts of the circuitry.

I still wish we had a belt and braces or second independent method of testing the RAMs - remember that all the ones originally fitted had 19V sitting on them for quite a while until you fixed that fault - but if we assume for now that the RAMs themselves are OK then we probably need to look at the RAM support circuitry - not the RAMs themselves, but the timing and selection and access circuits which control the RAM subsystem.

[SiriusHardware]

Now that RAM TEST looks like it's running, one thing you could try is something which Mark suggested earlier, remove all RAMs and put only one RAM at a time into the first RAM socket, see if you can identify individual good and bad RAM ICs that way. It's possible for one RAM to be so faulty that it affects the operation of the rest.

If this method identifies at least one RAM which always passes as good, try moving that one RAM step by step through all of the other RAM positions as a way of testing each of the RAM slots / positions individually. (There might be one particular slot or row in which no RAMs will work).

[pudwink]

been playing around with it and it seems to have settled to saying three banks of dram have an issue but its not the dram chips because if I move them around the failure is the same.
also noticed it only needs one of the row of three to show a problem and it shows a problem on that whole row.
https://youtu.be/aLcg4xl01vQ

[Mark1960]

Each row shares a common data line.

Remove all the ram from each bad row and put them to one side. Then fill the first two columns with chips from the last row. Does that give you two working columns?

If you still have bad rows this probably means some other issue on those rows, either short, open or a buffer issue on that data line.

If you now have two working columns, fill the last column with the ram chips put to one side. If any of those make the row bad remove them and try a different ram chip.

[SiriusHardware]

Down the right hand side of the test display are the figures D0 to D7 (Data lines D0 to D7) so it looks like the test is indicating a RAM-wide problem with RAM data bits D1, D4 and D7. We know that read access from the system RAM is through the buffer IC, IC50, 74LS244, but we also know that read access from the ROM is through the same buffer, so that would suggest that the system should be able to read from the DRAM through that buffer OK as well.

Data written to the RAMs is supplied to them from the main data bus buffers which have already been replaced.

With the RAM TEST eprom running can you scope the following pins on ALL of the RAM chips

In the following group, the signal on each IC should look broadly the same as the signal on the same pin on all the other ICs, so what you are looking for is an odd man out, one or several where the signal does not look like the signal on the same pin on the other chips.

-Pin 3 (WE
-pin 4 (RAS)
-pin 15 (CAS)
-pin 13 (CS)

In this next group the signals on the lines are very complex because data coming from the RAM is mixed in with code being read from the ROM. The waveforms themselves will not be regular but going up and down in seemingly random fashion.

Scope IC50 pins:-
2
17 (?)
4
15
6 (?)
13
8
11 (?)

In particular, we are looking for any significant visual difference between the signals on the pins I have put a question mark next to, and the others. If you want to post pictures that will be helpful but make sure all photos are taken with the Time / Div control at the same setting.

Edit: Do what Mark said first.

[pudwink]

update and mega news I contact the person who wrote the tester program and explained that if one chip in a row failed it knocked out the whole row so they altered the rom file and on rerun said 4 drams were bad.
now all the dram chips in the computer passed the tester I brought with flying colours but I replaced them with 4 that did not fully pass the tester and all memory has now passed the dram tester program and better still the computer now boots up next issue non of the keys work although if I keep hitting them some work odd times.

[SiriusHardware]

Wow, you don't need us.