I'm sure you're right, Dave. I'd still like to know why the wait doesn't go to 0 when I press a key, though. No pulse or anything. Maybe I should be concentrating more on the interrupt and see where it goes. I agree I must get the M1 pin to pulse. I did change out the Z80 chip with a known good one and the results stay the same. I believe my readings are right. The Z80 chip on the CPU board pulses like it should. Thanks.
| VCF SoCal | Feb 15 - 16 2025, | Hotel Fera, Orange CA |
| VCF East | Apr 04 - 06 2025, | Infoage Museum, Wall NJ |
| VCF Southwest | Jun 20 - 22 2025, | University of Texas at Dallas |
| VCF Southeast | Jun 20 - 22 2025, | Atlanta, GA |
| VCF West | Aug 2025, | CHM, Mountain View, CA |
| VCF Midwest | Sep 13 - 14 2025, | Schaumburg, IL |
-
Please review our updated Terms and Rules here
Heathkit H89A Question
- Thread starter JimboX
- Start date
daver2
10k Member
If /WAIT is permanently HIGH I wouldn't bother about this - otherwise you end up chasing too many red herrings. Worry about this when we get the Z80 CPU working properly!
'Fixing' this won't help your /M1 signal I am afraid. Only if /WAIT was stuck LOW would this be a problem.
Likewise, if the Z80 is not working properly (and by this I mean not executing the ROM program properly), then chasing the /INT line is also potentially pointless.
Just out of interest can you check the Z80 pin 28 (/REFSH) to see if that is pulsing away?
EDIT: I think I may have identified that the Z80 may be put into WAIT states for a while if the Z80 accesses the keyboard look-up ROM (U445).
Dave
'Fixing' this won't help your /M1 signal I am afraid. Only if /WAIT was stuck LOW would this be a problem.
Likewise, if the Z80 is not working properly (and by this I mean not executing the ROM program properly), then chasing the /INT line is also potentially pointless.
Just out of interest can you check the Z80 pin 28 (/REFSH) to see if that is pulsing away?
EDIT: I think I may have identified that the Z80 may be put into WAIT states for a while if the Z80 accesses the keyboard look-up ROM (U445).
Dave
Last edited:
bladamson
Veteran Member
If your CPU isn't running right, it's probably never getting to the instruction that polls the keyboard port and triggers the wait state generator.
I am sorry to keep beating the proverbial dead horse, but you have verified that the CPU is resetting correctly at power-up, right? It's unclear to me from skimming back over the previous posts.
That reset signal not only resets the CPU, but it resets the latch that generates the NMI at the start of the vertical blanking interval. If that's never getting reset, that might also explain why you are getting a barrage of NMIs instead of just one whenever the CPU writes to video RAM. Grab that schematic earlier in the thread and check both the inverted and non-inverted reset signals. Maybe if there's a bad inverter somewhere some of the stuff is getting reset and some of it is staying in an undefined state.
You should see it pulse for a moment when you power up the computer, and when you do rightshift-reset from the keyboard. You may need to put your scope in single seq mode and set the trigger slope (rising or falling) to the right thing to catch it. It will be very brief, maybe too quick to see on a digital scope without grabbing a single seq.
I hope I'm not leading you on a wild goose chase. My apologies in advance if so!
I am sorry to keep beating the proverbial dead horse, but you have verified that the CPU is resetting correctly at power-up, right? It's unclear to me from skimming back over the previous posts.
That reset signal not only resets the CPU, but it resets the latch that generates the NMI at the start of the vertical blanking interval. If that's never getting reset, that might also explain why you are getting a barrage of NMIs instead of just one whenever the CPU writes to video RAM. Grab that schematic earlier in the thread and check both the inverted and non-inverted reset signals. Maybe if there's a bad inverter somewhere some of the stuff is getting reset and some of it is staying in an undefined state.
You should see it pulse for a moment when you power up the computer, and when you do rightshift-reset from the keyboard. You may need to put your scope in single seq mode and set the trigger slope (rising or falling) to the right thing to catch it. It will be very brief, maybe too quick to see on a digital scope without grabbing a single seq.
I hope I'm not leading you on a wild goose chase. My apologies in advance if so!
The reset gives a momentary pulse when the computer is turned on as well as the chirp in the speaker. The wait pulse is still high. The refresh pulses and is low. The reset pulse when first turned on and is high. I found something interesting, U447 which gives the interrupt to the CPU always has a high output which goes to pin 16 on The CPU through U432 C. Pin 5 on U447 is high unless the break key is pressed. Pin 4 should also be high to get a low out put on pin 6. There is no voltage on this pin. I traced this back to the resistor RP4 Pin 2 and JP12 pin 1 and 2. There's no voltage there. All the rest of the JP's have 5 volts on 1and 2. Do you think RP2 is open or am I chasing my tail? This keeps getting curiouser and curiouser as Alice said.
daver2
10k Member
RP4 is a pull-up resistor package.
Why do you think that all of the pins of it should have a voltage on them?
It is more likely that the signal connected to RP4 pin 2 is (intentionally) driving the signal LOW.
I am not expecting the refresh signal on the Z80 to be 'pulsing and LOW'. I expect this line to be normally HIGH and pulsing LOW.
Can you post a photograph of what the Z80 refresh signal looks like on your oscilloscope screen please?
Dave
Why do you think that all of the pins of it should have a voltage on them?
It is more likely that the signal connected to RP4 pin 2 is (intentionally) driving the signal LOW.
I am not expecting the refresh signal on the Z80 to be 'pulsing and LOW'. I expect this line to be normally HIGH and pulsing LOW.
Can you post a photograph of what the Z80 refresh signal looks like on your oscilloscope screen please?
Dave
You're so right on RP4 pin 2. Just for kicks I removed chip U448 and U447 pin 4 shot up to 5 volts. The only thing I could get off of RFSH was noise, no real signal. It read low at 3.78 volts the same as M1. I happened to notice that Chip U446 gets super hot. This was not the Chinese chip but a Canadian one I replaced it with. I'm probably way off base again, but there is no data strobe (pin 13) on U444 produced when any key is pushed. This strobe goes to U448. U444 voltages are good. I'll replace this chip (U446) with another and see if it heats up, too. We may be at the end of the road here. I'm beginning to wonder if we'll ever fix this computer. I sure do appreciate your efforts. What do you think?
daver2
10k Member
You needn't have removed U447 - this is an INPUT. The signal is driven by U448.
Just removing a device (or in this case two) "for kicks" is just irresponsible. You can measure the other pins of the device and using your grey matter and the data sheet work out what is going on.
You didn't tell me you already replaced U446. You were having some strange effects with pins 12 and 13. Did those go away when you replaced it? If a chip is overheating, there are a number of possibilities:
1. The power supply is wrong - measure the power supply directly at the device (pin 7 = GND, pin 14 = +5V).
2. There is an internal logic fault. There are six (6) inverter gates within U446. Test the inputs and outputs of all six of them. Look for the six gates on the schematic to see what drives them and what they drive.
3. The output of one of the gates is shorted to +5V via a low resistance path. The above test (point 2) should reveal this fault.
Regarding the data strobe, it is just possible that once a key has been detected - and activated U448A (because this drives the pin on RP4/2) and the Z80 /INT pin 'gets stuck' because the Z80 is not processing its program correctly; then the keyboard encoder may NOT generate another data strobe until the Z80 has told it that it has processed the last key. Again, is this the cause or the effect of the fault?!
We are still not seeing SENSIBLE readings from the Z80 CPU yet. This is now /M1 and /REFSH. Two pins is not coincidence. I am back to either there is something wrong at the Z80 CPU, or you are not taking the readings correctly.
The only reason this repair is taking too long is that you keep disappearing down a rabbit hole! Looking for signals that don't do what you think they should do - and then start to remove chips on a whim...
Back to the Z80!!!
Get /MREQ (Z80 pin 19) onto your scope and get a good lock on it. Get a few cycles of the signal on your oscilloscope. Is it varying between <0.6V and >4.5V? Post a photograph of what you observe.
If so, move your probe (without adjusting anything on the oscilloscope for now) onto Z80 pins 25, 26 and 27 in turn and post a photograph of each pin.
Dave
Just removing a device (or in this case two) "for kicks" is just irresponsible. You can measure the other pins of the device and using your grey matter and the data sheet work out what is going on.
You didn't tell me you already replaced U446. You were having some strange effects with pins 12 and 13. Did those go away when you replaced it? If a chip is overheating, there are a number of possibilities:
1. The power supply is wrong - measure the power supply directly at the device (pin 7 = GND, pin 14 = +5V).
2. There is an internal logic fault. There are six (6) inverter gates within U446. Test the inputs and outputs of all six of them. Look for the six gates on the schematic to see what drives them and what they drive.
3. The output of one of the gates is shorted to +5V via a low resistance path. The above test (point 2) should reveal this fault.
Regarding the data strobe, it is just possible that once a key has been detected - and activated U448A (because this drives the pin on RP4/2) and the Z80 /INT pin 'gets stuck' because the Z80 is not processing its program correctly; then the keyboard encoder may NOT generate another data strobe until the Z80 has told it that it has processed the last key. Again, is this the cause or the effect of the fault?!
We are still not seeing SENSIBLE readings from the Z80 CPU yet. This is now /M1 and /REFSH. Two pins is not coincidence. I am back to either there is something wrong at the Z80 CPU, or you are not taking the readings correctly.
The only reason this repair is taking too long is that you keep disappearing down a rabbit hole! Looking for signals that don't do what you think they should do - and then start to remove chips on a whim...
Back to the Z80!!!
Get /MREQ (Z80 pin 19) onto your scope and get a good lock on it. Get a few cycles of the signal on your oscilloscope. Is it varying between <0.6V and >4.5V? Post a photograph of what you observe.
If so, move your probe (without adjusting anything on the oscilloscope for now) onto Z80 pins 25, 26 and 27 in turn and post a photograph of each pin.
Dave
Your right, Dave I've been going in too many directions instead of working on the main problem. I mentioned that chip U446 was getting super hot and shorting out between pins 12 and 13. It's not the Chinese Chips fault. I traced the problem down to RP4(5). This resistor reads 1.5k ohms. I opened up the link between 1 and 2 on JP15 and measured the resistance between 2 and VCC2. What do you think I should do now? Am I falling deeper down the rabbit hole? Should I just keep this chip out for now since it just seems to affect the keyboard operation and continue on, or should I put a 10k resistor in place of the supposedly bad one first? I haven't taken any readings yet because of this problem. Thanks.
daver2
10k Member
Back down the rabbit hole I am afraid...
Let's think about RP4(5) 'changing' resistance from 10k to 1.5k first. A pull-up resistor is a passive component and pretty reliable - unless it is subject to heat, vibration or some other excessive parameter. Normally, a resistor would fail open circuit (high resistance) rather than change its resistance lower - but there are exceptions. Let's calculate the current (from Ohm's Law) I = V/R = 5/10,000 = 0.5 mA. Then the power (P = I*I*R which also = V*V/R) = 2.5 mW. That is teeny weeny. If you remove the link JP15 1-2 you will still find that RP4(5) is still connected to U449 pin 11. What (in all probability) you are reading is the combined (parallel) resistance of RP4(5) and the 'sneak path' via U449 and the power supply rails. This (in all probability) is why the resistance value you are reading of 1.5k is much smaller than the original resistance of RP4(5) of 10k. I would be suspect of something if it was GREATER than 10k...
Even then, a 'faulty' RP4(5) dropping the resistance from 10k to 1.5k would still not cause U446 to either get hot or fail! This is a pull-up resistor on the INPUT - even then 1.5k would only draw 5/1500 = just over 3 mA of current from the DRIVING TTL device (which doesn't exist because it is another pull-up resistor RP3(2) of 10k and a switch to 0V/GND). So no failure here...
If U446 is getting hot - and not working properly - you need to ascertain why. Look for ALL of the gates that form part of U446 - there should be six of them. Just leaving U446 out is no solution - as the other five gates (unless some are not used) will also be removed - and this will have repercussions for the operation of the circuitry elsewhere. It may NOT be this gate we are looking at (gate F on pins 12 and 13 of U446) but one of the other five gates (A to E of U446).
I am still concerned about why the Z80 is not producing the correct signals - even though they are not connected to anything...
In my last post I did ask you to post a photograph of the /MREQ signal and then (using the same oscilloscope settings) post a photograph of the Z80 pins 25, 26 and 27.
Can you do this FIRST please - now we have pulled you out of the rabbit hole again!
Dave
Let's think about RP4(5) 'changing' resistance from 10k to 1.5k first. A pull-up resistor is a passive component and pretty reliable - unless it is subject to heat, vibration or some other excessive parameter. Normally, a resistor would fail open circuit (high resistance) rather than change its resistance lower - but there are exceptions. Let's calculate the current (from Ohm's Law) I = V/R = 5/10,000 = 0.5 mA. Then the power (P = I*I*R which also = V*V/R) = 2.5 mW. That is teeny weeny. If you remove the link JP15 1-2 you will still find that RP4(5) is still connected to U449 pin 11. What (in all probability) you are reading is the combined (parallel) resistance of RP4(5) and the 'sneak path' via U449 and the power supply rails. This (in all probability) is why the resistance value you are reading of 1.5k is much smaller than the original resistance of RP4(5) of 10k. I would be suspect of something if it was GREATER than 10k...
Even then, a 'faulty' RP4(5) dropping the resistance from 10k to 1.5k would still not cause U446 to either get hot or fail! This is a pull-up resistor on the INPUT - even then 1.5k would only draw 5/1500 = just over 3 mA of current from the DRIVING TTL device (which doesn't exist because it is another pull-up resistor RP3(2) of 10k and a switch to 0V/GND). So no failure here...
If U446 is getting hot - and not working properly - you need to ascertain why. Look for ALL of the gates that form part of U446 - there should be six of them. Just leaving U446 out is no solution - as the other five gates (unless some are not used) will also be removed - and this will have repercussions for the operation of the circuitry elsewhere. It may NOT be this gate we are looking at (gate F on pins 12 and 13 of U446) but one of the other five gates (A to E of U446).
I am still concerned about why the Z80 is not producing the correct signals - even though they are not connected to anything...
In my last post I did ask you to post a photograph of the /MREQ signal and then (using the same oscilloscope settings) post a photograph of the Z80 pins 25, 26 and 27.
Can you do this FIRST please - now we have pulled you out of the rabbit hole again!
Dave
Thanks for your great explanations on RP4(5). I'll try to solve this U446 problem by looking at the other gates. Whatever is causing it is shorting out Pins 12 and 13 and there was a burning smell. I know Z80 is the major problem we're trying to solve, so if I can solve this problem, I can get back to it. Had some minor surgery today so I'll be out of commission for a few days. I'm trying to climb out of this hole, but the sides are very slippery. Thanks for helping me figure this one out.
daver2
10k Member
No problem.
Burning smells are not good...
Get well soon, but don't overdo things!
I had some major surgery back 2012, so I used the time wisely to get my S-100 system working. It took me a long while doing it in very short bursts!!!
The wife was quite content for me to have a Cromemco Z2 power supply in bits on the living room carpet for a week whilst I repaired the beast! Now I just get shouted at... Go figure.
I will check the schematics also tomorrow for the other U446 gates, to see if there is any commonality between the gates of U446 and the perceived symptoms.
Dave
Burning smells are not good...
Get well soon, but don't overdo things!
I had some major surgery back 2012, so I used the time wisely to get my S-100 system working. It took me a long while doing it in very short bursts!!!
The wife was quite content for me to have a Cromemco Z2 power supply in bits on the living room carpet for a week whilst I repaired the beast! Now I just get shouted at... Go figure.
I will check the schematics also tomorrow for the other U446 gates, to see if there is any commonality between the gates of U446 and the perceived symptoms.
Dave
daver2
10k Member
All six (6) of the U446 inverter gates are used, and they are all associated with the keyboard encoder logic.
Dave
Dave
I'm back and recuperating nicely. Got some dizziness, but that's another issue. Fixed the U446 inverter problem. U449 was bad and caused the low readings on RP4(5). U446 doesn't heat up anymore and works as it should. Tomorrow I'll get the readings on /MREQ and pins 25, 26, and 27, on the CPU chip. Have a good night.
daver2
10k Member
U449 being bad could cause the LOW on RP4(5) as you state. I don't see a causal link between a faulty U449 and the overheating of U446 though. But, if it works now...
Dave
Dave
Didn't get to the computer today. To many honey dos. Tomorrow for sure.
Here are the Photos you requested from pin 19, pin 25, pin 26, pin 27 in that order. The voltages were low, high, high, and low in the same order. Hope that helps. The last 3 photos look like noise to me. I was using a x1 probe.
Attachments
daver2
10k Member
Agreed.
These signals from a Z80 are not open collector (but I will check), so this is completely inconsistent behaviour.
Dave
Dave
These signals from a Z80 are not open collector (but I will check), so this is completely inconsistent behaviour.
Dave
Dave
I hope you find something. This seems like a bigger problem than I anticipated. Thanks.
Dwight Elvey
Veteran Member
When posting scope pictures please state the sweep and voltage scales. Is this an analog or digital scope? The "noise" pictures could be aliasing is on a digital scope( wrong sweep frequency for the signals being looked at ).
I've been too busy to follow this but Daver is a very good debugger.
Do remember, debugging remotely is difficult thing to do. It depends on the person doing exactly what is requested and replying to exactly what is requested. Things like if the voltage measurement is request with answers like "it was good" are problems that make it difficult for the person helping with the debug. Good is not a voltage.
Thanks
Dwight
I've been too busy to follow this but Daver is a very good debugger.
Do remember, debugging remotely is difficult thing to do. It depends on the person doing exactly what is requested and replying to exactly what is requested. Things like if the voltage measurement is request with answers like "it was good" are problems that make it difficult for the person helping with the debug. Good is not a voltage.
Thanks
Dwight