Well, Allison, you're going to force me to venture into the archives and
fetch the data sheet.
I'll get back to you on the precise numbers after I've looked them up, but
for now, I recall that the normal memory cycle was three clock ticks long.
That's the cycle, not the stroke into memory. Your assertion "The memory
active portion of the instruction cycle was far shorter, typically 300ns at
4mhz (shorter for M1 cycle)" is ABSOLUTELY correct. However, it took three
clock ticks in order to generate that cycle. IIRC, the entire M1 (opcode
fetch + refresh) cycle took 4 or 5 (?) clock ticks, which made it the
longest cycle. Memory cycles other than opcode fetches took 3 ticks and I
believe I/O cycles took 4.
The theory was that one execute a bunch of memory cycles to load up the
internal registers of the Z-80, of which there are plenty, and then execute
scads of register-register instructions which are faster, in order to
accomplish a given computational task. It didn't easily work out that way,
a notion which wasn't lost on the designers of the 6502.
The MOS-Technology people who first implemented the 6502 architecture,
recognized that although the Z-80 had plenty of registers, it still wasn't
enough, so they shortened the memory access cycles. In fact, they used a
whole addressing mode focused on the lowest page in memory, as, MOTOROLA had
done, and they opted for an 8-bit stack pointer, which gave them the ability
to execute stack-oriented operations faster than the Z-80 and its kin could
do so. It could look at its zero-page as extra-fast memory, or slow
register space. In any case, a stack operation took one clock tick + one
clock tick per byte. A zero page operation, depending on the operation in
question, took one clock tick less time than that same instruction operating
on any of the rest of memory. A load or store took two cycles, and an
indexed load or store took three.
Today, we're equipped with cheap VERY fast large, SRAMs which would make it
much easire to make a solid and objective test of the two processors.
Unfortunately, there's little reason to do so, since neither is of any
commercial interest.
The testing I did was many years ago, and my emphasis was on which one
worked faster in raw speed in a DRAM environment in which the affordable
DRAMs were of the 200 ns flavor. I've never been comfortable with my final
conclusion that the Z-80 was faster, except for the observation I made along
the way, that most tasks simply couldn't be done realistically on the 6502
because the tools weren't available.
Have YOU seen a 'C' compiler for any of the 6502 types?
Dick
-----Original Message-----
From: Allison J Parent <allisonp_at_world.std.com>
To: Discussion re-collecting of classic computers
<classiccmp_at_u.washington.edu>
Date: Sunday, April 11, 1999 4:35 PM
Subject: Re: stepping machanism of Apple Disk ][ drive (was Re: Heatkit 51/4
floppies)
><I have to disagree with your comparison of the 2 MHz 6502 with a 4 MHz
><Z-80A. My thought here is that the 4MHz Z-80 used in the conventional way
><had a memory cycle of 750 nanoseconds (3 clock ticks), while the 6502, at
>
>No it did not. The memory active portion of the instruction cycle was
>far shorter, typically 300ns at 4mhz (shorter for M1 cycle). the rest of
>the time the cpu cares not if memory is there. Now if your depending on
the
>CPU for refresh it's longer but then again if you used something else it
>still has to be done and takes some about of time/logic.
>
><had to go in order to utilize the memory bandwidth most effectively. The
><The 6502 could be interfaced quite easily by using an asymmetrical clock,
><with a short Phase-1 (the period during which addresses and control signal
>
>The same can be done with the Z80 (the cmos parts it can be very
effective).
>I've used that trick to get a M1 read/ that has the same length as Mread/.
>
><In any case, what I determined was that the Z-80, in spite of its
><complicated hardware requirement, was potentially the faster processor.
>
>I always get upset with this term as it's hard to quantitize unless
standard
>programs (sieve, fp-ops...)
>
>Allison
>
Received on Sun Apr 11 1999 - 19:27:07 BST