enter image description here

I'm currently running NOP on a Z80A cpu. All it does it flash some led, I expected it to flash 1 by 1. The led are place from address 16-0

  • 1
    @BrianH oh actually I'm looking for the reason why it blink. I'm beginner to electronics so sorry If I use the wrong term. I hook up my z80 with a 5v power supplied by a Arduino. The digital bus are connected to ground with a 100k ohm resistor. The clock speed is at 1hz. (From my Arduino, it goes high and delay 500ms and goes low and delay another 500ms and repeats) – user142208 Mar 17 '17 at 13:33
  • 4
    At such low clock rates you are most likely seeing undefined behaviour. 1 Hz is way below chip's operational frequency which is into megahertz range. – Algimantas Mar 17 '17 at 16:53
  • 1
    @Algimantas No - The Z80 is famous for its all-static design and should run at clock frequencies even lower. – tofro Mar 17 '17 at 23:22
  • 1
    Note there's more going on on the address bus than simply instruction fetch addresses: during state transitions T3 and T4, the Z80 pushes the contents of the (incrementing) R register onto the address bus for dynamic memory refresh. You'll probably not be able to distinguish the two overlapping increments from each other. What have you done to the rest of the CPU signals? – tofro Mar 17 '17 at 23:28
  • 3
    The original Z80 is not all static by any means. In fact, it is famous because of being non static. It won't work below its minimuim clock rate. To achieve DC to max clock rate operation, you need the CMOS version of the Z80. – mcleod_ideafix Mar 24 '17 at 10:00

Algimantas's answer is partly correct - the pins will begin to count in binary as these represent the 16-bit program counter (PC). But they also present an 8-bit I register, and 8-bit Refresh (R) counter. Thus there is a different pattern on the upper 8 address lines than the "expected" straight binary pattern.

There are two things going on, an opcode fetch, and a refresh cycle. The LEDS are actually showing the contents of the PC register followed by the I register on the upper 8 bits of the address bus and R is on the bottom 8 bits. It is further complicated by the length of the different registers.

See I AND R REGISTERS. What they do.

More detailed explanation: The Z80 fetches opcodes with a a cycle named "M1" which is 4 clocks long. The PC is presented on the LED's during clock cycles T1 and T2. A refresh cycle also occurs during T3 and T4 of all M1 cycles. In T3 and T4, the address pins present the contents of the 8-bit I register (interrupt page register) on the upper 8 bits, and the lower 8 bits is the R-register that also increments after each opcode fetch.

The R and I registers will start at 00 and the Z80 PC will start at 00000 on reset. For the first 256 (Edit: actually 128) cycles, the LED will show the I + Refresh and the PC RAM memory addresses in perfect sync.

But at cycle 128 (0x080), the pattern will change. The Refresh register will have wrapped around back to 0x00, so the pattern will change as shown below

Address bits in Hex:

0x0000 M1 cycle (opcode fetch)
0x0000 Refresh cycle is made from I (00) + R (00)
0x0001 M1 cycle (opcode fetch)
0x0001 R
0x0002 M1 cycle (opcode fetch)
0x0002 R
<and so on...>
0x007f M1  cycle (opcode fetch)
0x007f R  they both still match.
0x0080 M1  cycle (opcode fetch)
0x0000 R <=- refresh register has wrapped around
0x0081 M1 <= but the Program Counter does not.
0x0001 R <= refresh is now at a count of 1
0x0081 M1 <= but the Program Counter = 0x81 
<and so on...>
| improve this answer | |
  • 1
    The R register doesn't increment up to FF, but up to 7F, then it goes back to 0. The highest bit of this register is not altered by the refesh logic. It only can be changed by a LD R,A instruction. So the sync between memory address and refresh address is only kept for the first 128 M1 cycles. – mcleod_ideafix Mar 24 '17 at 1:40
  • Thanks for the correction! It's been a long time ( 40 years) since I worked at Mostek on the Z80 testers – Ferd Mar 29 '17 at 16:09
  • If you want to see the memory refresh alone, provide a HALT instruction instead of NOP. That will stop the PC advancing (more correctly, it will stop the CPU putting the new PC onto the address bus). – Toby Speight Mar 27 '19 at 17:33

The LEDs show individual bits of address that is currently accessed. This is a binary representation and each combination of on/off LEDs corresponds to different address.

Since you are giving it a hardwired NOP instruction, the address grows sequentially like this:

0000 0000 0000 0000
0000 0000 0000 0001
0000 0000 0000 0010
0000 0000 0000 0011
<and so on...>
1111 1111 1111 1111

After that it rolls over back to all zeros. If you gave it some real code that does something, the LEDs would not grow sequentially due to branches in code. They would also show memory addresses being accessed for reading or writing.

| improve this answer | |
  • 1
    Please also note that the high (?) bits of the Z80 address bus are used by the Z80-built-in D-RAM refresher. So I would expect to see 0000h, 0100h, 0001h, 0200h, 0002h, ... at the address bus. – Martin Rosenau Mar 31 '19 at 6:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.