[Z80] Scope probe interrupt request

[RazSlack]

So I have a little homebrew computer project with a Z80A MPU, and there's some weird stuff I experienced with it:

The program I made for it as "hello world!" is just an infinite loop:
1:OUT (0),A
2:JP 1
Might not be the exact thing in the ROM, but you get the idea, a foolproof program that should be an infinite loop.

Now after applying voltage and trying it out, appears I don't have IORQ activity at all. I check the address lines, and A15 is changing states like crazy. My guess: For some reason, the program itself was skipped, and the MPU now pretty much does as it pleases.

After this, I shorted the reset pin to ground for a few seconds. All of the sudden, everything goes like normal on the address bus, but still no IORQ.

Just for the heck of it, I measured the non-maskable interrupt pin (NMI), and I saw some ripple there (about 2 volts of ripple, might be more). The NMI pin is actually connected to Vcc through a 10K pull-up resistor. My first guess was that my probe's impedance somehow pulled the NMI pin low, requesting a "ghost interrupt", setting the program counter to 0066H, and never returning.

I soldered a 100nF cap in parallel with the pull-up resistor, and the ripple stopped, my probe doesn't request interrupts anymore, and now I do measure some IORQ activity!

Still, the whole probe requesting interrupts stuff is pretty weird. Anyone have a clearer explanation to why this happens? Could it be the capacitive load of the scope probe itself?

[DJohn]

Do you have anything to generate a reset when power is applied?  Processors of that era generally do unpredictable things on power-up.
Zilog's "minimum system" in the datasheet has a resistor to VCC and capacitor to GND on /RESET.  That will keep the processor in reset until the supply has risen to an acceptable level.

[RazSlack]

Yes, I have auto-reset implemented, a 4.7 uF cap between reset and GND, and 10K pull-up between reset and Vcc.

[Andy Watson]

Now after applying voltage and trying it out, appears I don't have IORQ activity at all. I check the address lines, and A15 is changing states like crazy.

The original Z80 had in-built facility to refresh dynamic ram. I've never used the option in anger but I believe it outputs an address - based on the contents of the R register - in the spare time it has during an instruction cycle. So seeing A15 wobble does not necessarily mean that something is wrong - it would depend on the contents of the R register after reset - which is indeterminate.

Also, the I/O address space is specified to be only 8 bits. It's three decades since I last dabbled with a Z80, but what I believe happens is that for a standard OUT instruction, the lower 8 bit address is repeated on the upper 8 bits of the address lines. If you use HL as an address for the I/O (OUT via (HL) ) you get, contrary to what the book says, the full 16 bits of HL appearing on the address bus - so you effectively have a 16 bit addressable I/O space.

Edit: That should be C register, and BC instead of HL. I see the datasheets now mention that register B is put out on the upper address bits.

[RazSlack]

Forgot to mention that the A register contains 0, and that's what's supposed to be output, so the top half of the address bus should have been all low. That's why we found it weird that A15 kept changing states.

[Andy Watson]

Forgot to mention that the A register contains 0, and that's what's supposed to be output, so the top half of the address bus should have been all low. That's why we found it weird that A15 kept changing states.

If this is a bog-standard Z80 (not one those newfangled CMOS jobs), you should be able single-step the clock input and see exactly what is happening on the I/O and address lines.

[grumpydoc]

Forgot to mention that the A register contains 0, and that's what's supposed to be output, so the top half of the address bus should have been all low. That's why we found it weird that A15 kept changing states.

You are correct that the contents of the accumulator appear on A_8-15 during an OUT(n),A - however how do you know that the accumulator contains zero?

Unless you set it in code that you did not show us a reset on the Z80 does not clear register contents to zero - it sets the PC to 0, sets the I & R registers to 0, disables interrupts and sets interrupt mode 0 but it doesn't touch the registers

[DJohn]

What exactly is in the ROM?  You've labelled the instructions 1 and 2, but they can't be addresses (OUT (n),A is two bytes).

If you've got a proper reset, then I can't explain the NMI behaviour.  That's strange.  Unless the pullup resistor wasn't attached properly.

Andy Watson's suggestion of single-stepping the clock would be my next step.  You can get the scope (or better, a bunch of LEDs) on the address and data lines and see exactly what is going on.  I would never have got my little 6502 board going without this.

[RazSlack]

Forgot to mention that the A register contains 0, and that's what's supposed to be output, so the top half of the address bus should have been all low. That's why we found it weird that A15 kept changing states.

You are correct that the contents of the accumulator appear on A_8-15 during an OUT(n),A - however how do you know that the accumulator contains zero?

Unless you set it in code that you did not show us a reset on the Z80 does not clear register contents to zero - it sets the PC to 0, sets the I & R registers to 0, disables interrupts and sets interrupt mode 0 but it doesn't touch the registers

I don't remember the exact sample code in it's completeness, but it was something like clear the A register, output it on channel 00H, then loop from start.

What's in the ROM, or what the code does is irrelevant as it's just a test routine to check if the processor can read it at all. My main question was about why does the probe cause a ripple when I touch the NMI pin. Although thanks for the tip about the single-stepping. I'll try to implement it in some way.

[Andy Watson]

.... when I touch the NMI pin.

I believe the NMI input is edge triggered. Your scope probe will probably have enough capacitance such that when you touch it to the NMI pin you generate a pulse, albeit very brief, and trigger the interrupt.

Which leads us to:

What's in the ROM, or what the code does is irrelevant ...

Typically, empty rom space is filled with 00, or, more often, FF. If you have tripped the processor into executing blank rom it will be seeing FF as its instruction code. FF is a restart to location 0038h - when it gets there it will presumably find another FF and sit in a very tight, infinite loop - pushing a return address on to the stack at each loop. So it will be trying to fill the memory with 0039h, or possibly 3900h. I know this happens - I found out the hard way