Because the Opcode fetch cycle was shorter than other memory cycles, it was
common practice to use M1* to insert a wait state. This added an extra
clock tick to the length of the cycle, making it almost as long as normal
memory cycles. That practice also set back DRAM design by a mite. It would
have been smarter for the chip designers to cough up the MREQ* a bit sooner
during M1* in order to make it easier to distinguish between opcode fetch
cycles and interrupt acknowledg cycles. Hindsight is always 20-20 . . .
Dick
-----Original Message-----
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Wednesday, March 31, 1999 2:09 PM
Subject: Re: Z-80 M1?
[Z80 M1 signal]
M1 signals the start of an instruction fetch or
an interrupt cycle start.
It's machine status to differentiate a opcode fetch from a data read or
write. it serves other uses especially with the Z80 periperal chips.
Sure, and if asserted along with IORQ/ it signals an interrupt
acknowledge cycle (Which is logical, as at least in Mode 0, it is going
to execute an instruction fetched from the peripheral chip).
But I guess the question is _why_ would external logic need to know that
a memory cycle was an instruction fetch rather than a data read. In some
ways signalling a memory cycle that wasn't addressed from the PC would be
more use.
I suppose some of the peripheral chips recognised things like RETI
instructions so they'd need to know that the appropriate bytes were being
fetched as instructions and not data. Is that the only common use, though?
-tony