z80 timing... 6502 timing
<the relatively short memory access strobe, while I was talking about the
<frequency at which they occur, as defined in the spec. I agree completely
Yes so? Often the z80 is moving 16bits, with 8bit wide memory it's going
to take several cycles. If it were a z280 that would be even more biased
as it uses fewer "ticks" per cycle and the bus is 16bits wide. Counting
ticks or whatever as I've repeatedly stated meaningless save for
discussions of how memory is used and not who is faster.
An aside at this point, the z280 runs different cycle timing as _at_4mhz would
be the base z80 of the same speed and the z380 (in z80 native mode) beats
that as the cycles have been shortend again.
<personal. The fact remains, that the memory CYCLE is three clock ticks
<long, as defined in the spec (though I haven't looked at it in 15 years or
It is not and Like I said the spec is infront of me as I type. Worst case
its 2. But that in itself is again meaningless.
<so since I haven't yet unearthed my Zilog or Mostek data books) and if you
<look at the pictures you saw with your logic analyzer, you should have see
<two read pulses of whatever lenght they were, spaced at very nearly 750 ns
<each time you saw the execution of an absolute jump, or any other
<instruction which consists of an opcode followed by a 16-bit address. The
<same is true of writes. They take one memory cycle, which is three clock
<ticks long, for each byte, although the memory write strobe is a mite
<shorter than the read strobe, IIRC, which I might not, but . . .
Your memory is faulty. and that 750ns bumber is still meaningless. they
only number for comparative purposes is the amount of time it takes to do
an absolute jump. For Z80 _at_4mhz that will be 2.5us. It will require
memory in the 250ns range to do it.
<were inserted as they often were for M1 cycles. Nevertheless, commonly use
<instructions were MUCH faster on the 2 MHz 6502, than on the 4 MHz Z-80.
A 2mhz 6502 executes a 1byte (say INX) instuction in 2 machine cycles and
that takes 1uS.
A 4mhz INC B (any register) takes 4 z80 clocks at 4mhz... damm if that
doesn't happen to be 1uS! Where is the speed difference?
According to my book a 6502 absolute jump takes 3-5 cycles and in the 5
cycle case its 2.5 us.
<probably measure three microseconds for those twelve clock ticks (T-states
<which is EXACTLY how long a 1 MHz 6502 takes to do that. Hence, I conclud
Exactly my point. The 6502 is not faster, it only marches to a different
drummer.
<I've concluded that most code I've seen underutilizes the internal resource
<and overutilizes the external ones. Code like that favors processors with
<more time-efficient use of the external resources. Hence, my assertion tha
<there's reason to believe the 6502 at 2 MHz could outrun the 4 MHz Z-80 in
<more or less typical code and in a more or less typical hardware
No again. It can match the z80 and in some cases it's better or worse.
<environment. Code written to make better than average utilization of the
<internals of a Z-80 might fare better against equally well-written code on
<6502. I'm comfortable with the reality that I'll probably never know for
<certain. Since neither processor is particularly important these days, no
<terribly important to me either.
Agreed well written code is essential for either to do useful work.
<None of this is really worth getting all excited about because, by the way
<in spite of its "better" performance, (by my assessment) the 6502 didn't
<accomplish more useful work on MY behalf, because I used a Z-80 running CP/
<every chance I got due to the abundance of really decent tools and office
<automation software.
Therein lies the key. A good system is not always defined by it's
hardware. Systems are a combination of practical hardware and functional
software. This account for why despite their flaws the TRS80, Apple II,
Z80 CPM based as well as others florished. Most people didn't program
8080z806502ti990018028085680980886800065815 they ran basic or a word
processor. the run on of part numbers was deliberate as to most people
the cpu used was just a number.
Allison
Received on Tue Apr 13 1999 - 20:28:19 BST
This archive was generated by hypermail 2.3.0
: Fri Oct 10 2014 - 23:31:42 BST