6502/Z80 speed comparison (was MITS 2SIO serial chip?)

From: Sipke de Wal <sipke_at_wxs.nl>
Date: Thu Dec 20 14:57:17 2001

The fact that the 6502 was a kinda striped-down version of
the M6800, and was more efficient from a computing power
perspective, has convinced some people that the 6502 was
the first (and only 8-bit) RISC-processor.

If the MOS people had given the chip more on board general
purpose registers (i.e. like zero-page memory on-chip) and if they
had truely done away with some more Motorola-like CISC
instructions, it would really have pulled it off as a true RISC-design.

Sipke de Wal


----- Original Message -----
From: Richard Erlacher <edick_at_idcomm.com>
To: <classiccmp_at_classiccmp.org>
Sent: Thursday, December 20, 2001 5:42 PM
Subject: Re: 6502/Z80 speed comparison (was MITS 2SIO serial chip?)

> There are lots of things that you could compare, but the first things you've
> to leave out are the ones that aren't a Z80, which immediately deletes the
> and Z280. The Z80 is not around any more than the 6502 is around. There are
> derivatives of the 6502 still in production, but they are few. There are
> derivative of the Z80 being produced as well. None of the former are 6502's,
> and none of the latter are Z80's.
> Your're right, in that they use their time differently. Because of the vast
> architectural differences, one has to be cautious about chosing a comparison.
> The first basis, before chosing a set of instructions for a comparision,
> however, is selection of an appropriate timebase. The Z80 uses its clock
> differently than the 6502 does. The Z80 never uses fewer than 2 clock ticks
> a complete memory cycle, ant 2 ticks is only the lenght of the M1 cycle.
> followed by the refresh cycle, during which, if I understand the process
> correctly, the Z80 decodes that opcode. "Normal" memory cycles are three
> clock-ticks in length, though only thwo of them are actually used during the
> actual access of memory. The memory access portion of the M1 cycle is
> essentially a
> The 6502 uses one clock tick for each CPU cycle. External hardware determines
> how long the memory access is, though the period beginning with valid
> and read/write begins just under half-way into phase-1 and continues
> phase-2, each of which is actually more-or-less half a clock cycle long. If
> don't attempt to do transparent memory sharing along the phase-1/phase-2
> boundary, a memory cycle can be as long as 1-1/2 clock ticks.
> All of these constraints are based on the addition of no wait-states. The Z80
> has excellent support for wait-state insertion during any cycle other than the
> refresh cycle. The early NMOS 6502 supports wait state insertion on read
> only. There are ways of getting around this, but the Z80 certainly makes it
> easier than does the 6502. CMOS 6502's support wait states on both read and
> write cycles.
> If you run each of the two at a rate that allows each to use its shortest
> cycle as the basic access window to memory, the 6502 will probably outperform
> the Z80 in a task that operates on 8-bit data in an 8-bit way. The more 16 or
> 32-bit things you do, the more it favors the Z80, due to its inherent features
> such as the 16-bit registers and operatons on them without intervening
> instruction fetches.
> If you compare the rate at which they operate, however, the 6502 has features
> that enable it to do 16-bit things quite handily in memory. Since one can
> the 6502's page-zero as an extended register set, with instructions dedicated
> for it. Those instructions include indirection into main memory, which make
> 16-bit operations remarkably fast for a CPU that has no 16-bit registers.
> Have a look at it and contemplate that. It's a VERY clever design, intended
> make for a small, hence, cheap, CPU chip.
> Dick
> ----- Original Message -----
> From: "Allison" <ajp166_at_bellatlantic.net>
> To: <classiccmp_at_classiccmp.org>
> Sent: Thursday, December 20, 2001 6:55 AM
> Subject: Re: 6502/Z80 speed comparison (was MITS 2SIO serial chip?)
> > Z80 uses it's time differently... Then again how many instuctions
> > would it take to do a 16bit add (result in register or convenient place).
> >
> > The fact that both are still viable suggests they have adaquate
> > speed and a rich enough instruction set to do many tasks.
> >
> > Last item, z80, Z180 and Z280 do not have the same timing.
> > For example the Z280 can be run at a bus speed slower than
> > the CPU speed and with the MMU and cache running in burst
> > mode you get a very different bus utilization model.
> >
> > Generally the only things that count is:
> >
> > Can the cpu do the task?
> > What cpu are you familiar with?
> > What is the total cost to implement the task (firmware/software counts)?
> > Politcial impacts (company prefers, owns, has, used before).
> >
> > Do I think z80 is better than 6502? Yes, I'm biased. Is 6502 a good cpu?
> > I think so, it certainly beat the 6800 and a lot of others in the 8bit
> > space.
> > Would I design with it? No, lack of experience, no on hand software base
> > for it, limited tools to work with it. Would I consider it, likely.
> >
> > I have 6502, 6800, 1802, SC/MP, SC/MPII, ti9900, 8048/9/874x, 8080,
> > 8085, z80, Z180 Z280, 6809 and T-11 to pick from. For a new design
> > (personal) of some size say to run an OS then Z280 or T-11 for single chip
> > I have 8748, 8749 and 8751s around. For simple controllers 8085 is easy
> > to use if it grows out of the 8749. Then again I also have upd78pg11s too.
> >
> Why do you see the 8085 as growing out of the 8049? The 8085 was quite mature
> when the 8049 came out, so they'r probably not from a common heritage, and the
> instruction sets are so totally different that one might believe they're even
> from a different manufacturer. The one that Intel claimed grew out of the
> 8048/49 was the 8051.
> Of all these old-timers, that's the only one that still has life, and it has
> LIFE in a big way! There are many variants, with the same common instruction
> set, but many different hardware features. The Dallas 89C420 runs at, 50 MIPS,
> which certainly breathes life into the line. There are bit-banging things
> you can do with that one that few of the others above could handle in less
> 10x the time, yet the architecture supports a full 64K of data space and a
> 64K of code space, with memory mapped I/O in the data space.
> >
> <snip>
> > >>
> > >>
> > >
> >
> >
Received on Thu Dec 20 2001 - 14:57:17 GMT

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:33:41 BST