7

For example, consider the case of handling an INT interrupt signal in the Z80. When the CPU makes the IORQ signal active, it expects the requesting IO device to place a vector onto on the databus. And when it makes the signal inactive, for the IO device to stop driving the databus. (At least this is what I have infered from the timing diagram found in the technical manual).

Z80 interrupt timing diagram

What stops the IO device from continuing to drive/assert the IO bus after the CPU makes the IORQ signal inactive? Is it an assumption that the IO device will behave correctly?

For example, consider the case where the ISR routine has an OUT instruction. This makes the CPU attempt to drive the databus which the misbehaving IO device is still driving. What happens here?

Improve this question
1
  • Short answer: "Nothing. Don't use I/O devices that do that." :-)
    – cjs
    Commented Apr 20 at 5:35

5 Answers 5

Reset to default
13

An I/O device will monitor IORQ, M1, and the address bus to determine whether to respond to an I/O cycle. As soon as the CPU negates IORQ the I/O device will stop responding. This ensures the CPU is always in control of how long an I/O device is driving the bus.

If an I/O device continued to drive the data bus after IORQ was negated then it would be a faulty design that would likely be caught before the device was put into production (say a UART chip or something else).

Now if a slow I/O device needs more time to respond than normal available it can use the WAIT signal to request a delay. In this case a misbehaving device could stall the CPU for longer than is desirable, but a properly designed I/O device wouldn't allow that.

In the case if your OUT example it would cause bus contention. Imagine in the next bus cycle a different I/O device or memory device attempts to drive the bus while the misbehaving I/O device is still doing so. Now both devices are trying to drive data on to the bus, and they will sink or source additional current as they "fight" with each other, up to the limit of how much current their data bus pins can deliver. This can lead to damage so it is an undesirable outcome, and hardware is designed to prevent these conflicts.

Improve this answer
6
  • It's perhaps worth noting that the timing diagram shows the device releasing the data bus before the CPU has stoped asserting ~IORQ -- I think the intent is that the device is responding to the positive edge of the clock. Of course in practice responding to IORQ will work just as well, however, because nothing else can use the bus until the processor puts the next operation onto it, which won't be for at least another two full cycles, because it performs a refresh cycle next which doesn't need the data bus.
    – Jules
    Commented Sep 8, 2018 at 7:51
  • .... although the diagram in the Z84C00 datasheet (which also applies to NMOS Z80s, which are included in the datasheet) is different, and clearly shows the data bus being released after IORQ is deasserted, and gives a timing indication for it as "ThD(RDr) Data hold time after /RD rise", min 0ns ... which implies that the timing diagram shown above is wrong. I wonder where it came from...?
    – Jules
    Commented Sep 8, 2018 at 8:23
  • It's almost identical to page 22 of the Mostek Z80 manual (jameco.com/Jameco/Products/ProdDS/35561.pdf) but the formatting is slightly different, maybe a different revision of the document. While I like this manual for having more information than Zilog's I wonder if the timing oddities are something Mostek specific or only apply to very old (1979) parts.
    – raisin-wrangler
    Commented Sep 10, 2018 at 14:32
  • @Jules: The data sheet shows the amount of time during which the Z80 requires the data bus to be driven by the device. The next memory device to drive the bus will want the I/O device off the device before it starts driving, but the Z80 won't care whether the I/O device gets off the bus immediately when IOREQ goes away and the memory device gets on as soon as MREQ appears, or if the I/O device hangs around for awhile, but the memory bus takes awhile to start driving the bus. Consequently, there's no need for the Z80 data sheet to specify those timings.
    – supercat
    Commented Sep 10, 2018 at 19:38
  • @supercat - yes, but according to the official datasheet, the Z80 requires the data to be on the bus until IORQ is deasserted, while the diagram above shows it being removed earlier than that, just after the clock edge. That's a discrepancy that could cause issues in some situations (although I'd guess they're rare ones).
    – Jules
    Commented Sep 11, 2018 at 7:13
6

Here's the equivalent diagram from the Z84C00 datasheet (which applies to NMOS Z80s as well as the later CMOS versions), which is a little clearer.

Z84C00 datasheet IRQ timing

The first thing to notice is that it's actually different: the diagram you show has the bus being released by the device before the CPU deasserts ~IORQ. This is actually wrong: here the timing is explicit, and shows that it must happen after.

This diagram also includes references to the table of timing requirements in the back of the datasheet. (15) indicates that the data must be on the bus at least TsD(Cr) ns before the positive clock edge - this varies depending on which exact processor you're using, but for a Z84C0004 it's 35ns. (16) indicates that the data must be left on the bus at least ThD(RDr) ns after the IORQ is deasserted, which is 0ns for all processor versions.

There's no specification of how long it can hold on to the bus, because all that's necessary is it stops using it before the next operation starts. In this case, that's slightly more than two clock cycles -- after the acknowledgement cycle the processor continues with the T3 and T4 states of the M1 bus cycle, in which the processor is performing a memory refresh operation which doesn't need the data bus. After that, depending on the interrupt mode, it will either perform a standard M1 instruction fetch cycle or a memory read cycle, both of which give the device until at least 40ns after the negative edge of the clock in the next clock cycle to release the bus before the next request is made.

Improve this answer
6

Like with any other misbehaving bus user - it crashes one way or another. Such a behaviour is just not valid, thus there is no way to recover (in fact, it's even hard to detect it anyway).

For example, consider the case where the ISR routine has an OUT instruction. This makes the CPU attempt to drive the databus which the misbehaving IO device is still driving. What happens here?

Nothing, as it would have been crashed already before. With the interrupting device still driving the bus, the Z80 wouldn't be able to read the interrupt routine address from memory, and even less the mentioned OUT instruction - or any other of the desired interrupt routine.

Keep in mind, there is only one data and address bus which carries everything from instructions over data to interrupt information. All following the protocol, and if one participant screws the protocol, the system is irrecoverably broken.

Improve this answer
3

What stops the IO device from continuing to drive/assert the IO bus after the CPU makes the IORQ signal inactive?

The protocol of the bus explained in the datasheet. If device is misbehaving, it causes CPU to malfunction.

This makes the CPU attempt to drive the databus which the misbehaving IO device is still driving. What happens here?

Machine hangs, reboots or anything else not expected. The malfunctioning device must be removed from the system and repaired (if it is defective) or put into the trash bin if it is designed to malfunction (in other words not designed up to CPU specifications).

Improve this answer
1

The example timing diagram shown is for a complex situation where the CPU is acknowledging an interrupt and reading an interrupt vector (mode 2 interrupt operation). As noted before the IORQ line going high shuts of the outputs of the Z80 peripheral chip. For non Z80 I/O chips it was usual to integrate the IORQ signal into the enable circuitry for that chip (the chip is only active for IORQ read/write cycles). Typical operation of a typical chip of the time was as follows (assuming /EN /RD and /WR type control):

EN=1 RD=X WR=X ---- Chip outputs are tristated (hiz), RD & WR signals irreverent.

EN=0 RD=0 WR=1 ---- Chip is outputting data (no other chip on the bus should be enabled).

EN=0 RD=1 WR=0 ---- Chip is reading from the bus.

Note that the Z80 would sample the data during a read on a clock edge some time after it expects the data to be stable on the bus, wait cycles could extend this period.

The Z80 had many different types of memory/I/O read/write cycles. The original Z80 manual covers them all and it's worth studying as an example of a well engineered product of its time.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .