IM0 中的 Z80 多字节命令答案

【问题标题】：Z80 Multibyte Commands in IM0IM0 中的 Z80 多字节命令
【发布时间】：2014-12-06 23:54:20
【问题描述】：

我只是为了好玩而设计一个带有很多外围设备的更复杂的 Z80 CP/M 系统。在阅读文档时，我在接受 IM0 中的中断时偶然发现了 Z80 CPU 的（未记录的？）行为。

当中断发生时，Z80 激活 M1 和 IORQ 向外部设备发出信号：“嘿，给我一个操作码”。如果操作码是 rst 00 或类似的东西，一切都很好。现在文档告诉我们，任何命令的任何操作码都可以提供给 cpu，例如 CALL。

但现在出现了未记录的部分：“在中断确认周期期间读取多字节指令的第一个字节。随后的字节由正常的内存读取序列读取。”

“正常的内存读取序列”。我如何确定 CPU 是想从内存中获取一个字节还是从设备中获取下一个字节？

编辑：我想，我找到了一个（好的？）解决方案：我可以通过分析 IORQ 和 M1 来检测中断确认周期的开始。我还可以通过分析 MREQ 和 M1 来检测下一个“正常”操作码获取。这样我就可以安装一个由这两个 ANDed 信号触发的触发器，即只要 CPU 从 io-device 读取数据，触发器就是 1。这个 1 我可以用来禁止总线驱动程序进出内存。

我的意图？我正在设计一个 CPLD 中具有 8 个优先输入的中断控制器。它的寄存器为每个中断引脚保存一个 16 位地址。只是为了好玩:-)

【问题讨论】：

在我的旧 Rodnay Zaks 编程 Z80 中查找 IM 0，他只说：“在这种情况下，中断设备可能会在数据总线上插入一条指令对于执行，其第一个字节必须在中断确认周期内发生。”数据没有多大帮助:)
我认为在 ack 周期内只能从设备中获取一个字节。 CPU 不知道操作码的来源，然后执行它在加载多字节操作数时一直执行的操作，并从内存中读取其余部分。
@Mike 从应用说明中可以看出，它至少足够聪明，不会在这样的序列中调整 PC。
我很高兴看到 SO 上这么老的 CPU 的质量答案 - 特别是因为它也是那个 CPU 的一个非常神秘的角落（我想知道是否有人真的在 IM0 中使用过多字节指令?)。

标签： interrupt z80

【解决方案1】：

我的理解是需要外围设备：

知道它需要提供多少字节；
响应 IORQ 周期后的正常读取周期；和
安排正常情况下响应内存读取周期的任何内容在此期间都不会这样做。

此外，Zilog 在 application note 中记录了该行为，您的报价来自该地址（可能未注明）。

实际上，我猜 99.99% 的 IM0 用户只使用 RST，其余 99.99% 的用户使用已知大小的指令，例如 CALL xxxx。

（我也知道有几个微控制器有效地保证在中断周期内不会将任何东西放到总线上，从而由于集电极开路输出将IM0 变成IM1 的同义词）。

【讨论】：

这些额外的字节从何而来？ Zaks 中的图表，在他关于中断处理的部分中，说“PC 没有递增”，因此确认“PC”（Z80 的）不在图片中，外围设备应该读取主机内存。
我的读数是 CPU 将继续执行读取周期，并且外围设备旨在通过自己的计数器对它们进行计数。我找不到关于将为读取周期提供哪个地址的明确文档。如果历史有帮助，IM0 是 8080 兼容模式，并且 8080 被设计为与 8008 中断兼容（并且源兼容，但不兼容二进制）。所以我们说的是非常原始的东西。 IM1 和 IM2 是 Zilog 尝试做一些更智能的事情。
在应用笔记上找到了很好的发现。问题中的引用也在 Z80 用户手册中，但没有太多其他细节（因此可能是问题）。看起来即使在应用说明中也没有明确提及的关键细节是，必须有一些外部电路来防止普通存储设备干扰第一个之后的 OP 代码字节的读取周期。

【解决方案2】：

Z80 手册中合理地记录了中断行为： Interupt modes，IM2 允许您为 16 位指针提供 8 位地址。至少到所需的 16 位直接地址的一半。

How to set the interrupt modes

我的理解是使用 M1 + IORQ 组合，因为没有留给专用中断响应的引脚。还有一个有趣的细节是，PIO、SIO、CTC 等 Zilog I/O 芯片读取 RETI 指令（当 CPU 获取它时）以了解 CPU 已准备好接受另一个中断。

【讨论】：

您好，感谢您的发帖，虽然没有什么新鲜事。问题是：“我如何确定 CPU 是想从内存中获取一个字节，还是从设备中获取下一个字节？”
没问题，我只是添加了几张。
我假设原始答案 + 应用笔记中的信息足够完整，可以提供地址字节？否则我也可以详细说明一下。