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_at_p850ug1.demon.co.uk>
To: Discussion re-collecting of classic computers
<classiccmp_at_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
>
Received on Wed Mar 31 1999 - 16:38:56 BST