Help wanted with sharp MZ80A repair

[Gary C]

Interesting that most of the EPROM goes C5 C7 and thats only bit 1 changing from 0 to 1 and bit 1 is connected to pin 12 which is wired to /wait.

Infact, every byte seems to be followed by a byte with the same binary except that wait is toggled 0 to 1 to 0. So

~Which would suggest the toggling of wait is normal ?

I note that A0 is connected to 0v so that would suggest that A1 would be the prime to jump locations and that is connected to /EXWAIT.

If the EPROM is toggling wait, then it MUST be one of the address lines toggling so which one is ?

 

[daver2]

With A0 being (apparantly) strapped to 0V, only half the the EPROM (the even addressed bytes) are being used.

It is not unexpected that /EXWAIT input (external wait) being pulled to logic 0 would operate the /WAIT output.

I would like to bet that /MREQ = 0 (A12), /BLNK (A9) and A15, A14, A13, and A12 (A7, A6, A5, and A4) would also factor into the /WAIT equation (possibly when = 1101 = 0xD).

Dave

 

[Gary C]

Yes, I mean that something must be toggling in time with /WAIT and the arangement of bytes in quads (with two never addressed) but a lot of them swapping bit 1 should be easy to track down what is making /WAIT toggle.

 

[oldcomputerdave]

Yes the EPROM is a 27256

To clarify when using the adapter pin 1 on the MZ80 is not used the EPROM pin 1 is to ground.

As the EPROM seems to be giving the same results I have refitted to original N82s100N chip.

I can't test the reset on IC40 due to the pulsing /WAIT but I get this on the pulsing>

/WAIT High - Low
/CSD High - Low
/BLNK Low - Data
/MREQ High - Data

I am not sure what the state is between each pin only the change!

I have now done and attached the videos you asked for.

On power up I need to do many resets to get anything at all.
its getting harder and harder to get a reset even with a power cycle.
/WAIT is low until I can get it to reset but even on the "failed" resets /WAIT will go high for a fraction of a second

I have bodged in an led on the CPU to show the /WAIT line.
Led on = /WAIT High
Led off = /WAIT Low

Both videos pan down to show the led

Video with the lines is with M-ROM removed
The display "pulses" on off (I think the gaps in the lines are due to timing on the video not the MZ80)
/WAIT stays low

Other video is with M-ROM fitted
Note the Random flashing of the curser!
/WAIT is a steady on off pulse


Dave

 

[daver2]

The video with no ROM fitted is of little use (as I said before). The Z80 is doing 'something', but we have no idea what...

I notice, however' that the blue LED is on constantly. Which, according to your statement, indicates that the /WAIT line is HIGH - and not as you described as LOW. Unless I misunderstood something.

The video with the ROM is interesting though.

So, can you remind me (if you have told me previously), what test equipment do you have (so we can track this fault down)? I agree (from the LED status) that something is clearly wrong with the /WAIT signal - but we need to work out what - and work backwards.

Also, when the machine does not startup correctly, we can look at the key Z80 control signals to try and ascertain what it is doing.

Dave

 

[oldcomputerdave]

I agree the no ROM can't run code as there is none to execute but I don't understand why /WAIT is high if the ROM is removed and pulsing when fitted .

I also have an working MZ80K and if I remove the M-ROM I get a stable (not pulsing) display with thin vertical lines, This is why I thought this was a clue?

With the ROM fitted /WAIT is pulsing to LOW at the time of the first post I had not tried without the ROM.

I have a 2 channel scope but I am still learning how to use it as I have not had it long and not had a scope before!
I also have a simple multimeter and an IC tester that can do most logic chips.

I have tested the memory in a borrowed tester and replaced a few faulty ones.

Dave

 

[oldcomputerdave]

Just thinking you are correct I got it the wrong way round with the M-ROM removed /WAIT is high sorry.....!!

But if /Wait is high the CPU will not run and with the M-ROM removed something must be causing the pulsing.
I will check this tomorrow... Maybe see what happens with both M-ROM and CPU removed? What do you think.

Dave

 

[daver2]

What make and model of oscilloscope is it?

Or post a link to the manual.

The 'pulsing' screen and the incorrect WAIT signal could be linked. As I have stated previously, the WAIT signal will be activated if the Z80 and the video circuitry is attempting to access the video RAM concurrently. If there is something wrong with the video circuitry somewhere, this may be affecting the WAIT signal - which is what we are observing.

Without some means of sensibly observing the signals (i.e. with an oscilloscope) we are 'walking around in the dark'.

EDIT: Just seen your later post. The Z80 may still be executing SOMETHING with the ROM removed. We just don't know WHAT. The 'pulsing' may be due to a video / Z80 interaction (even if no ROM is present) or may be due to faulty video circuitry.

You just need to remove the Z80 CPU to see what happens! I can guarantee you do not need to remove both the Z80 CPU and the ROM!

If you get video 'pulsing' then, the problem is almost certainly with the video circuitry.

Dave

 

[oldcomputerdave]

I think I have been looking at this too long and I confused myself regarding the LED!

But the fault is still the same as it is blinking on and off, but to confirm...

Led off = /WAIT High
Led on = /WAIT Low

it is connected through a resistor from +5v to /WAIT

The scope is a Rigol DS1202 2 channel.

As it is now VERY hard to get /WAIT to go low by resets and or power cycling I have taken some readings on the CPU.

These readings are with /Wait high from power on scope in "run" mode and the second reading is when reset is pushed with the scope in "single" mode so I can catch any pulse but some trigger the scope without pushing reset so I assume these are floating?

/INT L Floating
/NMI H H
/HALT H H
/MREQ L Floating
/IORQ H H
/RD H Pulse low
/WR L Floating
/BUSAK H H
/WAIT L Floating
/BUSRQ H H
/RESET H Pulse low
/M1 H Pulse low
/RFSH H Pulse low

Dave

 

[daver2]

Unfortunately, the CPU readings are not too helpful I am afraid. If you have an oscilloscope, so detailed measurements are called for.

Right, first off, can you measure (using your oscilloscope) the following pins with the M-ROM installed and the machine running the monitor:

CPU /RFSH pin. This should be pulsing. Check that there is no gap in the pulses of > 1 millisecond.
CPU /WAIT pin. This may be completely HIGH or pulsing. Make sure it is not LOW for > 1 millisecond.

If either pulse is > 1 millisecond, then the DRAM contents could evaporate...

Could I also ask you to measure what is on the following pins of IC2 (SN74LS00):

Pin 4 - This is the /HBLNK signal (horizontal blanking).
Pin 5 - This is the /VBLNK signal (vertical blanking).
Pin 6 - This is a combination of the above two signal (this signal should be LOW when either /HBLNK or /VBLNK is low - or both LOW).

These signals should be nice and regular - so no strange 'pulsing'.

You should be able to post an image of the IC2 signals so that I can have a look at them.

In fact, I suggest you perform the tests on IC2 FIRST and then move back to the Z80 CPU - these readings may be more tricky (so you may have questions regarding the best way to take the measurements). In the meantime, I will lookup the manual for your oscilloscope...

Dave

 

[daver2]

This is what you need to look for on your oscilloscope:



In the case of the /RFSH signal - you want to set "+pulse width more than" and set the pulse width to 1 millisecond. This means that more than 1 millisecond has elapsed before a Z80 refresh cycle has occurred.

In the case of the /WAIT signal - you want to set "-pulse width more than" and set the pulse width to 1 millisecond. This means that more than 1 millisecond has elapsed with the Z80 in a WAIT condition.

You can vary the 1 millisecond delay (increase it) to see what the worst case is - basically, increase the pulse width until the oscilloscope just stops triggering. The pulse width value is then just longer than the worst case measured.

Of course, your particular oscilloscope may not have this feature... In which case, we need to get more 'creative' !

Dave

 

[oldcomputerdave]

As I an still learning how to use the scope I will post the screen grabs so you can see for yourself.

Due to the /WAIT pulsing and stopping the CPU I am sure DRAM data is being lost as you say.
The grabs are taken when the CPU is running (between the /WAIT pulses)

I also found I can't see both horizontal and vertical blanking signals on the scope
IC11-pin 8 and IC50-pin 10

I the other waveforms seem ok to me? (as in the service manual)

I did all this before reading your last post so let me know if you want me to redo any of the checks!

Dave

 

[daver2]

We now have the tool for the job (i.e. the oscilloscope)!

IC2 pin 4 (/HBLNK) at 15.7 kHz looks OK to me.

A couple of things:

1. Why is the Y probe setting at 1.3 V/div? That is a strange number. For measuring digital signals, I would choose 1 V/div - it makes it easy to make measurements using the oscilloscope screen and your eye.

2. The little 'arrow' should be the 0V reference. Before you start taking any measurements, short out the oscilloscope probe tip to the ground clip and adjust the Y position so that it aligns with a major division mark on the oscilloscope screen. This is the 0V point of all measurements you take. Again, it makes life easy (and the measurements more accurate)...

3. If these are as a result of the oscilloscope being set to some AUTO mode. Set it to MANUAL mode. AUTO mode is designed to mess with your head!

IC2 pin 5 (/VBLNK) at 61 Hz looks OK - HOWEVER the voltage is WAY low! I measure (approximately) 2.6 Volts. Whilst this is (technically) a logic HIGH - it is a very poor one! When using an oscilloscope to measure TTL signals, you need to keep in mind the acceptable permissible voltage levels (see https://learn.sparkfun.com/tutorials/logic-levels/ttl-logic-levels).

IC2 pin 6 (combined) looks OK to me. Note that there is a HIGH when pin 5 (/VBLNK is LOW) and a load of 'mush' when /HBLNK is oscillating. Due to the difference in the frequency of /HBLNK and /VBLNK (15 kHz vs 61 Hz) you cannot see the logic action of the /HBLNK signal (unless you speed up the oscilloscope timebase. The trick to this is to trigger the oscilloscope on a HIGH->LOW transition of /VBLNK on IC2 pin 5 and use the other oscilloscope channel to measure IC2 pin 6. The oscilloscope is now 'locked' to a fixed point in time and you can speed up the timebase to see the detail on IC2 pin 6. You should observe a 15 kHz signal to come into view embedded onto the 61 Hz signal.

The question that you haven't answered is "are these traces stable or not"?

IC20/11, IC20/10 and IC3/4 also look OK.

IC11/8 is ONLY /HBLNK. *** HOWEVER *** this doesn't make sense to me. I am also not sure where /V.GATE is driven from. What signal is on IC11 pin 10 I wonder, and where is it source from?

IC50/10 is ONLY /VBLNK.

-RFSH and -WAIT need to be looked at again in light of my post above.

-RFSH looks good at a period of 2 us - but is this wholly true?

Likewise, -WAIT (with a period of 16 ms) will guarantee DRAM data loss! Is it possible there are some 'little' VBLNK transitions between the HBLNK pulses? If so, the oscilloscope timebase may be running too fast to see them...

Dave

 

[oldcomputerdave]

Dave:

Thank you for all the help with this,
I have not had the scope for long and I am learning to use it at the same time as the fault finding, I have never used one before so please bear with me if/when I get it wrong!.

Ok latest tests..

Firstly as I say is now taking longer and longer to "persuade" the /WAIT to start pulsing on and off so the tests are getting difficult.

IC2- With ch1 on pin 5 and ch2 on pin 6 CPU not running /WAIT high
There is a pulse on pin 5 reducing the voltage pictures 1,2 and 3 at different timebases


IC2- With ch1 on pin 5 and ch2 on pin 6 /WAIT pulsing high-low
Now pin 5 is oscillating, Pictures 4 and 5

I see -VBLNK also goes to the 8255 IC50 pin 10 so I tried the same test with IC50 removed and the voltage increased on pin 5. This was with /WAIT high pictures 6 and 7

I have to go out now but will continue later

Dave

 

[daver2]

>>> I have never used one before so please bear with me if/when I get it wrong!

Absolutely no problem - we all have to learn at some time... You are learning quicker than others we have coached...

IC2 pin 5 (/VBLNK) is present in pictures 1, 2, 3, and 4 - just with a reduced voltage level for some reason. IC2 pin 5 is still present in picture 5 - however, due to the oscilloscope timebase setting and the frequency of the IC5 pin 5 signal, all you are observing is the HIGH portion of /VBLNK - combined with some heavy noise. Sometimes signals don't appear to change - because of the oscilloscope timebase setting...

As your channel 1 (yellow trace) is being used as the oscilloscope trigger, you can see it has transitioned from HIGH to LOW (albeit with a poor voltage swing) - so it is oscillating. You have to think of things in terms of time. IC2 pin 5 (/VBLNK) was measured as 61 Hz -> convert to microseconds (us) = 16,393 us. If I understand picture 5 correctly, the oscilloscope timebase is set to 20 microseconds/div [us/div]. There are 12 major divisions on the horizontal/time axis of the oscilloscope - so the screen can display (at most) 20 * 12 = 240 us. We are, therefore, trying to fit a 16,393 microsecond signal onto a 240 microsecond screen! No way are you going to see any other transition - other than the edge that the oscilloscope is triggering on. This is half the battle - is understanding what you are expecting to observe and then setting up the oscilloscope to observe what you expect. Sometimes, you are surprised by what you then observe! Some oscilloscopes have a facility to display ten (or more) times what has been displayed on the screen.

Another thing to watch out for is the sample rate of the oscilloscope vs the signal frequency you are measuring. There is a trade of between sample rate and length of time you can take a trace for (this is limited by the RAM in your oscilloscope). This can lead to aliasing - whereby a signal displayed on the oscilloscope screen is 'not real'. I can explain a bit more if you need me to...

Question: where is your oscilloscope ground probe clipped to when you are measuring IC2 pins 5 and 6? Is it on the GND pin of IC2 or somewhere else? If somewhere else, what you are probably observing is noise pickup across the ground plane of the logic board. Ideally, you want the oscilloscope probe ground clip on the GND of the IC that you are taking the measurements on.

It is VERY interesting that when you removed the 8255 that the voltage level on IC2 pin 5 increased. I would suspect that the 8255 is either loading the signal too much - or is faulty. Your yellow oscilloscope trace may (now) have gone off the top of the screen - making a voltage measurement impossible.

Remember above I said about setting your ground reference arrows on a major division of the oscilloscope screen?

I would setup a 2 channel scope trace (TTL signals) at 1V/div (which you have done) and configured so that the ground of one channel is 1 major division above the other (so a slight offset). Remembering that a TTL signal is lightly to be 5V - so that is 5 major divisions of the oscilloscope screen at 1V/div. This (I have found) is the best solution for me - as a default.

I am going out tonight myself.

Dave

 

[oldcomputerdave]

>>>> Question: where is your oscilloscope ground probe clipped to when you are measuring

Is connected to the main board ground pin, I tried it on the IC ground but it made no difference.

I swapped the 8255 with the one in my MZ80k but it was the same.
After more testing I found the via below the 8255 for ground was corroded, It was still connected but there was a resistance.
After repairing the -VBLNK on IC2 is now stable with the 8255 installed.
New scope pictures 1 and 2.

I still cant reset it and \WAIT is still high however I have again removed the M-ROM (/WAIT goes low with it removed) to enable the CPU to run (yes I know there no code) but with it running I can test /RFSH .. Pictures 3 and 4.

I am not sure where to go next!

Dave

 

[daver2]

I'll take a look tomorrow.

I assume you mean /WAIT is HIGH with the M-ROM removed to enable the CPU to run to test /RFSH?

We just have to keep plugging away...

Dave

 

[daver2]

Those signals look much better now.

So the problem was with a corroded 8255 via on the GND trace. So you found (and fixed) something that was faulty. Well done! Are there any more? Where there is one problem - are there more of the same type?

I assume (with /WAIT being high...) and the CPU running - that the refresh signal (/RFSH) looks OK. My question is (though) is it CONSISTENTLY OK? An oscilloscope provides a snapshot in time - and not necessarily the whole truth. With /WAIT being HIGH, does the refresh signal look consistently OK? If you trigger continuously on a /RFSH HIGH to LOW transition - are there any periods where the oscilloscope appears to 'stop' tracing?

This still leaves us looking at the /WAIT signal when the CPU is running some code. Is it TRUE that the /WAIT signal is LOW for (say) > 4 milliseconds or not? We have not yet answered this question...

Dave

 

[oldcomputerdave]

I have made a few more discoveries...

After repairing the via fault on IC50 Ground, With all IC's fitted /WAIT is low all the time and I can't get a reset!

If I remove IC7 buffer for CPU control lines /WAIT goes high CPU runs and I get CPU**** on the scope.

Then if I refit IC7 and remove IC6 buffer for address lines A8 to A15 /WAIT is still high and I get IC50**** on the scope

I have tested the buffers (they are ok) but I have replaced them anyway, No change..

As one is data and the other is address lines I am not sure what to make of this!

Dave

 

[oldcomputerdave]

More pictures..