ZX80 troubleshoot /HALT is high

[Erm]

Of the 2 ZX80's that I seem to be getting frustrated about and am just about to give up on, this one possibly has the best chance of working, so this is what I've found. Going by a list Mark once wrote re Z80 pins, and also comparing the broken one to a working ZX80, this is what I have:

Pin Function
16 /INT (should be pulsing) YES
17 /NMI (I think this should always be high on a ZX80) YES
18 /HALT (should be pulsing) NO -This one is always high.
19 /MREQ (should be pulsing rapidly) YES
21 /RD (should be pulsing rapidly) YES
22 /WR (should be pulsing) YES
24 /WAIT (I think this should always be high on a ZX80) YES
25 /BUSRQ (should be high) YES
26 /RESET (should be high, except for a very short time after power is applied) YES
27 /M1 (should be pulsing) YES
28 /RFSH (should be pulsing) YES

So my /HALT isn't right and the rest look ok (almost the same) compared to the working one. In case something elsewhere was pulling it up I removed pin 18 from the socket and it's still always high.

Pin 8 on the RAM is mostly high and pluses down every 10us.

A15 (and the others) don't look right compared to the working one, i.e. there is activity but not as much - they are mostly low and pulse up every 10us.

I've gone over everything with a magnifying glass, all the chips are socketed due to a big failure of some kind (how I received it) and I even changed the Z80 and ROM sockets to better ones - checking under them, around them etc. This ZX80 did originally have some odd circuitry concerning the video output because it probably started life in France. Here are the details on that: viewtopic.php?f=7&t=3688&p=38057&hilit= ... ite#p38057

I have reverted it to standard setup by removing the resistor on the rear, removing the transistor, removing R31, populating R32 and changing the A-B-C jumper back to connecting A and C.

Suggestions as to why my /HALT is high and what can be done about it will be gratefully received.

[1024MAK]

If /HALT is active (this is an output pin on a Z80), it indicates that the Z80 has encountered a HALT instruction. If interrupts are NOT enabled, or the /INT input is faulty, the Z80 will just execute NOP (no operation) instructions repeatedly…

While the Z80 program counter will not change state while the processor is halted, the refresh (R) register (bits 0 to 6) will continue to count from zero to 127, then back to zero again. Bit 7 will likely be at zero (it does not count, so stays at whatever value it was previously at). After each instruction fetch, the Z80 will put the refresh address on the address bus. A0 to A7 are from the R register. A8 to A15 are from the interrupt (I) register (because the Z80 always puts out a 16 bit address).

The most common cause of a HALT with interrupts disabled (at reset interrupts are disabled), assuming the Z80 is okay, is either a memory problem, or a problem with the address, control or data busses.

I assume you have swapped the ROM/EPROM and SRAM chips? Are you able to read the contents of the ROM/EPROM chip? Or do you have a ZX81 or TS1000 ROM chip which you can put in the ZX80?

Have you tested the the address, control and data busses? If you have a ‘scope, check each line is switching between valid logic levels and that none are always the same as another line (as that indicates a short circuit between them). Also with the power off, continuity test each node for each line. By node I mean pick a major chip (e.g. Z80) and test each pin of each chip or resistor fed from, or feeding to that pin.

If you copy and printout the schematic, you can use a coloured pen to mark your progress.

I’m not at all sure that you have signals changing at 10ns intervals. 1980s memory chips have access times between 120ns and 250ns… Can you double check this please.

The French analogue video has the level of the black/white video component inverted compared to U.K. / European 625 line, 50 Hz video signals. Hence the additional components. Problems with the analogue video should have no effect on the digital circuitry used by the Z80 etc.

Mark

[Erm]

Thanks for taking the time to reply Mark, I really hope I can get this one going.

If /HALT is active (this is an output pin on a Z80), it indicates that the Z80 has encountered a HALT instruction. If interrupts are NOT enabled, or the /INT input is faulty, the Z80 will just execute NOP (no operation) instructions repeatedly…

While the Z80 program counter will not change state while the processor is halted, the refresh (R) register (bits 0 to 6) will continue to count from zero to 127, then back to zero again. Bit 7 will likely be at zero (it does not count, so stays at whatever value it was previously at). After each instruction fetch, the Z80 will put the refresh address on the address bus. A0 to A7 are from the R register. A8 to A15 are from the interrupt (I) register (because the Z80 always puts out a 16 bit address).

The most common cause of a HALT with interrupts disabled (at reset interrupts are disabled), assuming the Z80 is okay, is either a memory problem, or a problem with the address, control or data busses.

I've tried a few Z80's, including the one from the known working ZX80.

I assume you have swapped the ROM/EPROM and SRAM chips? Are you able to read the contents of the ROM/EPROM chip? Or do you have a ZX81 or TS1000 ROM chip which you can put in the ZX80?

The original ROM is certainly ok. I've used it in the known working one and it was fine there. I did also try a ZX81 ROM and scribbled down that with the ZX81 ROM fitted the Z80 Pin 18 (/HALT) was always high instead of always low. Not sure if that is significant. The RAM chips are the original ones from the broken one, how it came: NEC uPD2114LC -1 on the right and NEC uPD2114LC on the left. Both tested ok in my retro chip tester. I also have the following 2114 chips that have also tested ok:

National Semiconductor MM2114N-2L (that's one suitable for the 'fast' chip isn't it?)
National Semiconductor MM2114N-3 (for the 'slow' chip?)
Toshiba TMM314APL-1 2114L2 (got 2 of those - only suitable for 'slow' position I believe)

Have you tested the the address, control and data busses? If you have a ‘scope, check each line is switching between valid logic levels and that none are always the same as another line (as that indicates a short circuit between them). Also with the power off, continuity test each node for each line. By node I mean pick a major chip (e.g. Z80) and test each pin of each chip or resistor fed from, or feeding to that pin.

I certainly buzzed through the traces from the Z80 and the ROM while the sockets were off today and they all seemed to go to where they should. Also visually I could see no issues. I also visually checked both sides in and around the 74x chips when they were out. I'll check again.

I’m not at all sure that you have signals changing at 10ns intervals. 1980s memory chips have access times between 120ns and 250ns… Can you double check this please.

10us, i.e. 2 blocks that were each 5us on the scope scale.

[Erm]

Oh yes, one other thing I did notice that may not be significant but I'll mention it.

When testing the 74LS05 chips in my XGecu/Minipro they always fail with the 7405 option but pass with the option labelled 74HC05(OD). I expect that's normal and is just the way the device measures/handles the levels etc. Mentioning it because without a working socketed ZX80 it's the only way I can test 74 logic chips.

[Erm]

Some scope stills.

These Address lines are rapid and look 'normal' (to me), like this:

These Address lines are the less frequent, like this (or similar with the solid line high, and it dipping down to gnd instead of up to 5v):

Data lines all look very similar to these 2 examples: