opcodes for Zilog 8800/Intel 8080
Marat Fayzullin
: However, I can't for the life of me track down the opcode list for
: either the Zilog 8800 or the Intel 8080, nor the memory map for
: either the Imsai 8080 or the Altair 8800 microcomputer.
http://www.komkon.org/fms/comp/
: Does anyone have any of these available? I've checked most all of
: the computer museum and software/hardware archive and/or "we're
: preserving all this info for posterity" sites, as well as several
: books.
8080 opcode tables are not *that* rare.
Neil Franklin
>
> f...@cs.umd.edu (Marat Fayzullin) writes:
>
> > skr...@home.com wrote:
> >
> > : However, I can't for the life of me track down the opcode list for
> > : either the Zilog 8800
That is either Zilog Z80-CPU or Zilog 85x0 (can't remember the x), an
8080 compatible processor or Altair 8800, an early Intel 8080 processor
based microcomputer.
> > : Does anyone have any of these available? I've checked most all of
> > 8080 opcode tables are not *that* rare.
> No, but they are surprisingly hard to find, at least in the form in
> which I need them. :) Thanks for the help, tho.
I have got here an full opcode list of the 8085 (Intels compatible
upgrade for the 8080) printed by Siemens, an official 8085 second
source.
It has the full mnemonics, binary representation, instruction
description in english, but the detailed descriptions are in german
(Siemens is an german firm).
If you want a copy (3 2-sided A4) e-mail me your snail address.
Actually, looking at it, this is the sort of thing that should be
webbed. If it is not, I think I will put it on my website. And 6809 as
well. I learned programming on Z80, 6809 was second.
--
Neil Franklin, Nerd, Geek, Unix Guru, Hacker
ne...@franklin.ch.remove http://neil.franklin.ch/
"No, it was a JOKE! You can't RUN this!" Ken Thompson
Bill Richman
Manual. I scanned the table in the back with the opcodes and object
code; this in combination with one of the instruction tables from
http://www.comlab.ox.ac.uk/archive/cards.html should be all you need to
start programming the Z-80. You can find my scanned pages on my web
page under "Classic Computers", "Archive of Esoteric Documents for
Obscure Computers". Hope this helps.
P.S. - Come to think of it, the original IMSAI and the Altair 8800 both
used the 8080 CPU, so this is probably of little use to you... DOH!
---
On Mon, 16 Nov 1998 16:36:43 GMT, skr...@home.com wrote:
>>
>> : However, I can't for the life of me track down the opcode list for
>> : either the Zilog 8800 or the Intel 8080, nor the memory map for
>> : either the Imsai 8080 or the Altair 8800 microcomputer.
-Bill Richman (bil...@inetnebr.com)
http://incolor.inetnebr.com/bill_r - Home of the COSMAC Elf Microcomputer
Simulator, Fun with Molten Metal, Orphaned Robots, and Technological Oddities.)
Marat Fayzullin
: But I thought the Altair 8800 used a Zilog chip. I've seen the Altair
: 8800 spoken about as using a "Zilog 8800" CPU, and have also seen
: people say it uses a Z80, or a Z80-compatible. I've even seen
: statements that the Intel 8080 and the Zilog Z80 are compatible.
: So, I guess now my question has evolved into, which is the real story?
: I really would rather not have to track down and crack open an actual
: Altair to check. I value by skin in its current state. :)
Can't say much about Altair, but Zilog Z80 CPU is an extended 8080 clone
backward compatible with Z80 at the assembly level. Zilog has added more
instructions and changed mnemonics, but the basic core of instructions
works the same and has the same opcodes in both 8080 and Z80. They are
just called with different names.
Marat
Jim Stewart
skr...@home.com wrote:
> bil...@inetnebr.com (Bill Richman) writes:
>
> > I have a copy of the 1976 Zilog Z80 Assembly Language Programming
> > Manual. I scanned the table in the back with the opcodes and object
> > code; this in combination with one of the instruction tables from
> > http://www.comlab.ox.ac.uk/archive/cards.html should be all you need to
> > start programming the Z-80. You can find my scanned pages on my web
> > page under "Classic Computers", "Archive of Esoteric Documents for
> > Obscure Computers". Hope this helps.
> >
> > P.S. - Come to think of it, the original IMSAI and the Altair 8800 both
> > used the 8080 CPU, so this is probably of little use to you... DOH!
>
> Thanks for the effort!
>
> But, now I guess I'm really confused. I'm positive that the IMSAI
> 8080 did use the Intel 8080 chip. So there's no debate there (unless
> I'm wrong, at which point I may break down in tears).
>
> But I thought the Altair 8800 used a Zilog chip. I've seen the Altair
> 8800 spoken about as using a "Zilog 8800" CPU, and have also seen
> people say it uses a Z80, or a Z80-compatible. I've even seen
> statements that the Intel 8080 and the Zilog Z80 are compatible.
>
> So, I guess now my question has evolved into, which is the real story?
> I really would rather not have to track down and crack open an actual
> Altair to check. I value by skin in its current state. :)
I worked for IMSAI during this era so I know a little about the subject.
The Altair 8800 used the Intel 8080A chip. The earliest IMSAI 8080's used the
Intel 8080A cpu, but soon after the start of production, they switched to the
NEC 8080A. After some problems involving the way the flags were handled,
IMSAI went to the NEC8080AF, a cpu that handled the flags exactly as the
Intel chip. Neither company used the Z-80 in their original products. A
company called TDL made a very popular replacement/alternate cpu board with a
Z-80 processor.
The flag issue was an important one because the first releases of Microsoft
Basic would only run on a Genuine Intel cpu. Details here are a little
fuzzy, but as I recall, the Intel 8080A did not handle the parity flag
correctly and Microsoft Basic exploited this in a bad way. As the NEC 8080A
and the Z-80 handled the flag properly, early releases of Basic would not run
on them. Microsoft later modified Basic to run on all the processors, but by
that time damage had already been done.
Jim
Tony Wingo
<jste...@jkmicro.com> wrote:
> I worked for IMSAI during this era so I know a little about the subject.
I worked at IMSAI for a short while too. Would have been late '75 to mid '76.
>The Altair 8800 used the Intel 8080A chip. The earliest IMSAI 8080's used the
>Intel 8080A cpu, but soon after the start of production, they switched to the
>NEC 8080A. After some problems involving the way the flags were handled,
>IMSAI went to the NEC8080AF, a cpu that handled the flags exactly as the
>Intel chip. Neither company used the Z-80 in their original products. A
>company called TDL made a very popular replacement/alternate cpu board with a
>Z-80 processor.
>
>The flag issue was an important one because the first releases of Microsoft
>Basic would only run on a Genuine Intel cpu. Details here are a little
>fuzzy, but as I recall, the Intel 8080A did not handle the parity flag
>correctly and Microsoft Basic exploited this in a bad way. As the NEC 8080A
>and the Z-80 handled the flag properly, early releases of Basic would not run
>on them. Microsoft later modified Basic to run on all the processors, but by
>that time damage had already been done.
Actually, the problem was that INTEL didn't specify how the flags behaved
on all instructions. So the various knock-offs behaved differently in the
undefined cases. Unfortuately, a number of "clever" programmers figured
out how Intel set the flags, then coded to this "standard". While MS may
have been the worst offender, this was the source of numerous headaches at
several companies I worked at.
-t
Eric Smith
> But I thought the Altair 8800 used a Zilog chip.
Nope. It used the good 'ol 8080. The Zilog chip wasn't even announced
until more than a year after the Altair 8800 shipped.
> I've seen the Altair 8800 spoken about as using a "Zilog 8800" CPU,
There wasn't ever a Zilog 8800, although Zilog had a Z-8000 series (16-bit)
and a Z80,000 (32-bit, never actually shipped AFAIK). There *almost* was an
Intel 8800, but it wasn't even *similar* to the 8080; it was a 32-bit chip
set, and became the iAPX-432 when it was announced in 1981. The schematics of
the 432/100 evaluation board (which ran a custom version of Rosetta Smalltalk)
show the GDP chips with part numbers 8801 and 8802, which became 43201 and
43202.
> and have also seen
> people say it uses a Z80, or a Z80-compatible. I've even seen
> statements that the Intel 8080 and the Zilog Z80 are compatible.
The Z-80 is nowhere near pin-compatible with the 8080. The 8080 requires
a two-phase non-overlapping clock at MOS levels, and requires some external
logic to decode the bus status. Intel offered support chips for clock
generation and bus interfacing, but AFAIK the Altair did not use them,
probably because they were expensive. The Z-80 was much easier to design
with, because it only required a single-phase clock (almost but not quite
TTL compatible), and had internal bus signal decoding.
Software-wise, the Z-80 is mostly upward compatible from the 8080. I've heard
that there was a change in how one of the flag bits was affected by one
instruction, but I'm not sure if that is true. Zilog adopted a different (and
more logical) set of mnemonics, possibly because Intel claimed that the 8080
mnemonics were copyrighted. However, the object code was identical.
Almost all 8080 software runs fine on the Z-80. CP/M was written for the 8080
and did not use Z-80 features, but some vendors wrote BIOS code that used
extra registers without properly saving and restoring them; this later caused
problems with some application software that also used Z-80 registers.
Eric
William Hamblen
<eric-no-s...@brouhaha.com> wrote:
>Software-wise, the Z-80 is mostly upward compatible from the 8080. I've heard
>that there was a change in how one of the flag bits was affected by one
>instruction, but I'm not sure if that is true.
The Intel 8080 set the parity bit after every arithmetic or logical
instruction. The Z80 set the parity bit only after the logical
instructions and used the same flag bit for an overflow bit after
arithmetic instructions. The 8080 didn't have an overflow bit. If
you wanted the Z80 parity bit to behave just like the 8080 parity bit
you needed to put an AND A instruction after the arithmetic
instruction.
Bill Richman
lot of people upgraded them to a Z-80 by swapping out the CPU card. I
built an IMSAI from a kit when I was 16, and still have it in working
condition, so I can speak with a fair amount of certainty about it. The
Altair I don't have personal experience with, but there are a lot of web
sites around about it (http://www.hyperweb.com/altair/ for example).
The Z80 used a super-set of the 8080 instructions, and was available at
higher clock speeds if I remember correctly. Although there are purists
who will argue that there were undocumented features that could cause
problems, essentially any normal code written for the 8080 would run on
the Z80, but not necessarily the reverse. At any rate, I've also
scanned the instruction set page for the 8080 and placed it in the same
location on my site as the Z80 pages I mentioned earlier. I'd suggest
printing it out for readability. Make sure you don't confuse 0's for
D's; it was a pretty poor job of printing, and scanning didn't help it
any... :-)
On Tue, 17 Nov 1998 06:49:57 GMT, skr...@home.com wrote:
>Thanks for the effort!
>
>But, now I guess I'm really confused. I'm positive that the IMSAI
>8080 did use the Intel 8080 chip. So there's no debate there (unless
>I'm wrong, at which point I may break down in tears).
>
>But I thought the Altair 8800 used a Zilog chip. I've seen the Altair
>8800 spoken about as using a "Zilog 8800" CPU, and have also seen
>people say it uses a Z80, or a Z80-compatible. I've even seen
>statements that the Intel 8080 and the Zilog Z80 are compatible.
>
>So, I guess now my question has evolved into, which is the real story?
>I really would rather not have to track down and crack open an actual
>Altair to check. I value by skin in its current state. :)
>
Don Stokes
> Excellent! And I'm not at all surprised to hear that about Bill. :)
>So this means I shouldn't have any trouble with either the 8080 or the Z80
>opcodes on either machine.
Stick with the 8080 set -- the opcodes are the same, but the Z80 adds a
few niceties like the alternate register set and block instructions.
(Personally, I think the Zilog style assembler mnemonics (ld to,from)
make more sense than the Intel equivalents (mov to,from), but that's
probably because the Intel way is backwards from the DEC way (mov from,to)
that I'm used to.)
--
Don Stokes, Networking Consultant http://www.daedalus.co.nz +64 25 739 724
AutismUK
In article <72s0a6$r13$1...@cronkite.cs.umd.edu>, f...@cs.umd.edu (Marat Fayzullin)
writes:
>Can't say much about Altair, but Zilog Z80 CPU is an extended 8080 clone
>backward compatible with Z80 at the assembly level. Zilog has added more
>instructions and changed mnemonics, but the basic core of instructions
>works the same and has the same opcodes in both 8080 and Z80. They are
>just called with different names.
I *think* the 8080 doesn't implement the direction bit on arithmetic ;
DAA is only addition.
Andrew Cadley
AutismUK wrote in message <19981118040755...@ngol06.aol.com>...
:
:In article <72s0a6$r13$1...@cronkite.cs.umd.edu>, f...@cs.umd.edu (Marat
What about all the block operations and the slightly crap indexed ones? IIRC
none of those were on the 8080. I don't think the 8080 allowed rotates on
any register either.
AndyC
lis...@zetnet.co.uk
On 1998-11-17 jste...@jkmicro.com said:
:The flag issue was an important one because the first releases of
:Microsoft Basic would only run on a Genuine Intel cpu. Details
Old habits die hard, I suppose...? ;>
--
Communa (lis...@zetnet.co.uk) -- you know soft spoken changes nothing
Charlie Gibbs
d...@news.daedalus.co.nz (Don Stokes) writes:
>(Personally, I think the Zilog style assembler mnemonics (ld to,from)
>make more sense than the Intel equivalents (mov to,from), but that's
>probably because the Intel way is backwards from the DEC way (mov
>from,to) that I'm used to.)
Oh hell, I might as well get another flame war going. I prefer
the Intel mnemonics. IMHO the Zilog mnemonics are bad because
they create an illusion of orthogonality where none exists. At
least saying MOV, LXI, STA, or whatever keeps you aware that the
corresponding operations are quite different from each other, and
it's quite obvious which operations are not allowed - something
which the Zilog mnemonics conceal. (That might be OK for a
high-level language, but we're down to the bare metal here.)
The other thing that irritates me about Zilog mnemonics was that
opcodes are almost redundant - everything's becoming LD, it
sometimes seems. I thought of modifying my assembler (or at
least adding macros) to make it so: e.g. LD @A,<addr> instead
of INP, or LD PC,<addr> instead of JMP(*), for instance. Once
all instructions have the same op code, you can get rid of it
entirely, and write your program as just a series of operands. :-)
* Yes, I know that the Zilog mnemonic for an unconditional jump
is JP, even though every fiber of my being screams, "NO! That's
wrong! JP means Jump if Plus!" But I hate the format of the
Zilog jump instructions too, so there. :-p
--
cgi...@sky.bus.com (Charlie Gibbs)
Remove the first period after the "at" sign to reply.
Marat Fayzullin
: Oh hell, I might as well get another flame war going. I prefer
: the Intel mnemonics. IMHO the Zilog mnemonics are bad because
: they create an illusion of orthogonality where none exists. At
: least saying MOV, LXI, STA, or whatever keeps you aware that the
: corresponding operations are quite different from each other, and
: it's quite obvious which operations are not allowed - something
: which the Zilog mnemonics conceal. (That might be OK for a
: high-level language, but we're down to the bare metal here.)
way CPU internals perform them, but for me as a programmer they
are all the same: data transfers. I simply don't care how CPU
performs them, as long as they are around.
: The other thing that irritates me about Zilog mnemonics was that
: opcodes are almost redundant - everything's becoming LD, it
: sometimes seems. I thought of modifying my assembler (or at
: least adding macros) to make it so: e.g. LD @A,<addr> instead
: of INP, or LD PC,<addr> instead of JMP(*), for instance. Once
: all instructions have the same op code, you can get rid of it
: entirely, and write your program as just a series of operands. :-)
Lousy argument. Zilog uses "LD" for data transfers. They are all
called LD because they all perform the same operation, including
the infamous LD PC,<addr> opcode. There is a lot of other mnemonics
in Z80 assembly though, ADD, EX, DEC, and INC to name a few.
: * Yes, I know that the Zilog mnemonic for an unconditional jump
: is JP, even though every fiber of my being screams, "NO! That's
: wrong! JP means Jump if Plus!" But I hate the format of the
: Zilog jump instructions too, so there. :-p
Then how you distinguish it from JR? Remember, Z80 has relative
jumps. 8080 doesn't.
PS: Some of the most dreadful mnemonics I have seen in my life
were XTHL,SPHL,PCHL, and XCHG (*four* consonants in a row),
all from 8080. I am sure IBM/360 programmers will readily
come with even worse ones though.
Marat
Tim Shoppa
>
> Charlie Gibbs (cgi...@sky.bus.com) wrote:
> : Oh hell, I might as well get another flame war going. I prefer
> : the Intel mnemonics. IMHO the Zilog mnemonics are bad because
> : they create an illusion of orthogonality where none exists. At
> : least saying MOV, LXI, STA, or whatever keeps you aware that the
> : corresponding operations are quite different from each other, and
> : it's quite obvious which operations are not allowed - something
> : which the Zilog mnemonics conceal. (That might be OK for a
> : high-level language, but we're down to the bare metal here.)
> How are they different? I agree that they are different in the
> way CPU internals perform them, but for me as a programmer they
> are all the same: data transfers. I simply don't care how CPU
> performs them, as long as they are around.
The original 8080A mnemonics were a very direct mapping between
the different move types possibe and the mnemonics. The
moves can be broken up into several different types:
1. Register to register, and register to M, byte moves.
(i.e. MOV B,D or MOV M,A).
2. Move immediate byte to register commands, i.e. MVI B,5.
3. Move immediate 2-byte word to register commands, i.e.
LXI D,5632.
4. Move accumulator to memory location (and reverse) commands,
i.e. STA 4567, LDA 8321.
5. Store and load HL pair commands, i.e SHLD 4567, LHLD 8321.
6. The STAX B, LDAX B, STAX D, and LDAX D type moves.
7. The PCHL, SPHL, XTHL, and XCHG mnemonics, all in a class of
their own :-).
The above different sorts of moves are *very* different to
someone who's learned 8080A assembly language, or who has
spent years of their lives toggling programs into front panel
machines. Within any given type of move, the move is
orthogonal, and the 8080A mnemonics nicely delineate the
different classes of moves to keep clear what is possible.
For instance, you can't do a LD B,(DE) (in Z-80 style mnemonic)
on an 8080A, and you wouldn't dream of doing so in 8080A
mnemonics because such a mnemonic doesn't exist.
Why should a programmer care what class of "load" they're doing?
Every byte counts, and the number of bytes and cycles it takes
to do each operation is perfectly clear in 8080A mnemonics.
The Z80 mnemonics hide all this, making the actual operation
much more opaque. (I won't start complaining about all the
"prefix" opcodes the Z80 designers had to introduce to deal
with the IX and IY registers.)
> : The other thing that irritates me about Zilog mnemonics was that
> : opcodes are almost redundant - everything's becoming LD, it
> : sometimes seems. I thought of modifying my assembler (or at
> : least adding macros) to make it so: e.g. LD @A,<addr> instead
> : of INP, or LD PC,<addr> instead of JMP(*), for instance. Once
> : all instructions have the same op code, you can get rid of it
> : entirely, and write your program as just a series of operands. :-)
> Lousy argument. Zilog uses "LD" for data transfers. They are all
> called LD because they all perform the same operation, including
> the infamous LD PC,<addr> opcode.
Yep, to the untrained eye they all perform the same operation.
To folks who have to worry about how many bytes are used by
each instruction and how many clocks it takes to execute
each instruction, the "LD" is a pain in the butt because it
hides these important details.
IMHO, if you're using assembler, it's because you want to
get involved at the detailed level. Anything that hides
these details from you - like the Z80 mnemonics - is doing
you more harm than good.
--
Tim Shoppa Email: sho...@trailing-edge.com
Trailing Edge Technology WWW: http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927
Charlie Gibbs
(Marat Fayzullin) writes:
>Charlie Gibbs (cgi...@sky.bus.com) wrote:
>
>: Oh hell, I might as well get another flame war going.
Yup, someone bit. :-)
>: I prefer
>: the Intel mnemonics. IMHO the Zilog mnemonics are bad because
>: they create an illusion of orthogonality where none exists. At
>: least saying MOV, LXI, STA, or whatever keeps you aware that the
>: corresponding operations are quite different from each other, and
>: it's quite obvious which operations are not allowed - something
>: which the Zilog mnemonics conceal. (That might be OK for a
>: high-level language, but we're down to the bare metal here.)
>
>How are they different? I agree that they are different in the
>way CPU internals perform them, but for me as a programmer they
>are all the same: data transfers. I simply don't care how CPU
>performs them, as long as they are around.
See my last sentence above. If I'm down to assembly language,
I often _do_ care how the CPU does it.
>: The other thing that irritates me about Zilog mnemonics was that
>: opcodes are almost redundant - everything's becoming LD, it
>: sometimes seems. I thought of modifying my assembler (or at
>: least adding macros) to make it so: e.g. LD @A,<addr> instead
>: of INP, or LD PC,<addr> instead of JMP(*), for instance. Once
>: all instructions have the same op code, you can get rid of it
>: entirely, and write your program as just a series of operands. :-)
>
>Lousy argument. Zilog uses "LD" for data transfers. They are all
>called LD because they all perform the same operation, including
>the infamous LD PC,<addr> opcode. There is a lot of other mnemonics
>in Z80 assembly though, ADD, EX, DEC, and INC to name a few.
Why "LD" instead of something that better suggests a general
move, such as "MOV"? Whenever I see "LD" I think "Load". This
isn't too appropriate for a move from a register to memory, which
is commonly referred to as a "store". "Load" is usually reserved
to mean a move in the opposite direction.
>: * Yes, I know that the Zilog mnemonic for an unconditional jump
>: is JP, even though every fiber of my being screams, "NO! That's
>: wrong! JP means Jump if Plus!" But I hate the format of the
>: Zilog jump instructions too, so there. :-p
>
>Then how you distinguish it from JR? Remember, Z80 has relative
>jumps. 8080 doesn't.
JRZ, JRNZ, etc. I got used to extended branch mnemonics on the
IBM 360, although I do admit it took me a while. On the 1620, on
the other hand, the different conditional branches were separate
instructions with unique first bytes, just like on the 8080/Z-80.
(But I could be opening a whole new can of worms regarding
instruction decoding if we follow that one too far...)
Still, if the mnemonic was more obviously "Jump on Condition" (the
360 uses "BC" as in "Branch on Condition"), I might find it easier
to swallow. JP just doesn't sound like "jump" to me, I guess.
>PS: Some of the most dreadful mnemonics I have seen in my life
> were XTHL,SPHL,PCHL, and XCHG (*four* consonants in a row),
> all from 8080. I am sure IBM/360 programmers will readily
> come with even worse ones though.
Those one _are_ a mouthful. I spell the first three letter by
letter. The last one can be pronounced "exchange", though.
Let's see, the 360 has things like MVC, MVN, and MVZ, which again
are easier to just spell out. But it also has ZAP, which is kind
of fun. Then there are the inbetween ones like BXLE. Most people
pronounce that one "bixel", but I once heard someone pronounce it
"boxel" and I liked it so much I adopted it. No such luck with its
sister instruction BXH, though...
Tim Shoppa
>
> In article <72viq9$g90$1...@cronkite.cs.umd.edu> f...@cs.umd.edu
> (Marat Fayzullin) writes:
> >Lousy argument. Zilog uses "LD" for data transfers. They are all
> >called LD because they all perform the same operation, including
> >the infamous LD PC,<addr> opcode. There is a lot of other mnemonics
> >in Z80 assembly though, ADD, EX, DEC, and INC to name a few.
>
> Why "LD" instead of something that better suggests a general
> move, such as "MOV"?
Because the good mnemonics were copyrighted by Intel, Zilog had
to be different or be sued. (Not that Zilog ever had much in the
way of profits in any event!)
Dave Daniels
> Can't say much about Altair, but Zilog Z80 CPU is an extended 8080 clone
> backward compatible with Z80 at the assembly level. Zilog has added more
> instructions and changed mnemonics, but the basic core of instructions
>
Whilst we are talking about the 8080 and Z80, does anybody have
any ideas as to what the undefined 8080 opcodes did? I am refering
to opcode values such as 0x08, 0x10, 0xCB, 0xDD, 0xED and so
forth, the ones later used in the Z80. ISTR hearing somewhere that
one of the undefined codes was a 16-bit subtract instruction, but
whether this is true or not, I have no idea. Has anybody got any
information on this?
Dave
--
ANTISPAM: Please note that the email address above is false. My
correct address is:
dave_daniels<at>argonet<dot>co<dot>uk
Please replace the <at> and <dot>s with @ and . respectively when
replying - Thanks!
Marat Fayzullin
: Why should a programmer care what class of "load" they're doing?
: Every byte counts, and the number of bytes and cycles it takes
: to do each operation is perfectly clear in 8080A mnemonics.
: The Z80 mnemonics hide all this, making the actual operation
: much more opaque. (I won't start complaining about all the
: "prefix" opcodes the Z80 designers had to introduce to deal
: with the IX and IY registers.)
have to agree that each Z80 opcode takes 1 (one) byte plus
as many bytes as it's argument takes. The latter can be clearly
seen from the program:
LD HL,0053h <-- 1 byte opcode + 2 byte argument
Execution time may differ (of course), but it also doesn't take
too much time to deduce from the number of parenthesis and
numerical arguments.
Now, if you look at 80x86 architecture from the same Intel, and
look at how much time ADD to AX takes in comparison to, let us
say, ADD to DX, you will see what "non-orthogonal" means.
: Yep, to the untrained eye they all perform the same operation.
: To folks who have to worry about how many bytes are used by
: each instruction and how many clocks it takes to execute
: each instruction, the "LD" is a pain in the butt because it
: hides these important details.
See above. Both Z80 and 8080 are (generally, not counting FD/FF/ED/CB
which we are not arguing about) 1-byte-per-opcode CPUs whose opcode
execution times rigidly depend on the number and addressation
of opcode arguments. Both these parameters are quite obvious
from Z80 mnemonics.
: IMHO, if you're using assembler, it's because you want to
: get involved at the detailed level. Anything that hides
: these details from you - like the Z80 mnemonics - is doing
: you more harm than good.
Anything that makes me memorize hundreds of different mnemonics
will do me more harm than good by making my brain do additional
useless work.
Marat Fayzullin
: Yup, someone bit. :-)
But of course :)
: Why "LD" instead of something that better suggests a general
: move, such as "MOV"? Whenever I see "LD" I think "Load". This
: isn't too appropriate for a move from a register to memory, which
: is commonly referred to as a "store". "Load" is usually reserved
: to mean a move in the opposite direction.
Does the sentence "Load a memory cell from the register"
sound like a broken English to you?
"MOVE", on the other hand, is an English verb used to mean a removal of an
object from location A and placing it to location B. Do any of the 8080
operations we are talking about remove anything from anywhere?
Tim Shoppa
>
> Tim Shoppa (sho...@trailing-edge.com) wrote:
> : Why should a programmer care what class of "load" they're doing?
> : Every byte counts, and the number of bytes and cycles it takes
> : to do each operation is perfectly clear in 8080A mnemonics.
> : The Z80 mnemonics hide all this, making the actual operation
> : much more opaque. (I won't start complaining about all the
> : "prefix" opcodes the Z80 designers had to introduce to deal
> : with the IX and IY registers.)
> Incorrect. If we do not look at the IX/IY operations, you will
> have to agree that each Z80 opcode takes 1 (one) byte plus
> as many bytes as it's argument takes.
Well, you're leaving out the BIT, SET, and RESET prefixes,
which can be combined with the IX and IY prefixes to create
very long "instructions", i.e. BIT 6,(IX+08) assembles to
DDCB0876, four bytes. Notice that the "08" is sort-of an
argument (it takes a byte), while the "6" isn't in the same
sense.
> Execution time may differ (of course), but it also doesn't take
> too much time to deduce from the number of parenthesis and
> numerical arguments.
Actually, it's much more complicated than just counting
parentheses and numerical arguments. When counting cycles,
you *have* to think of all the different LD forms, and their
various IX and IY prefixes, as different instructions. The
LD mnemonic form is just hiding this from you.
If it's just a matter of counting parantheses, how come
LD HL,(8) takes such a substantially different amount of time
than LD (IY+08),C ?
> Now, if you look at 80x86 architecture from the same Intel, and
> look at how much time ADD to AX takes in comparison to, let us
> say, ADD to DX, you will see what "non-orthogonal" means.
I'll agree that 80x86 mnemonics are just as bad, if not worse,
than Z80 mnemonics :-).
> : IMHO, if you're using assembler, it's because you want to
> : get involved at the detailed level. Anything that hides
> : these details from you - like the Z80 mnemonics - is doing
> : you more harm than good.
> Anything that makes me memorize hundreds of different mnemonics
> will do me more harm than good by making my brain do additional
> useless work.
But with "LD" you're doing the work of remembering which LD
forms are legal and which aren't. LD A,I works, but LD B,I
doesn't. LD (HL),C works but LD (DE),C doesn't, yet LD (DE),A
does. You've got to remember all the rules for what different
real operations are possible with LD, when 8080 mnemonics do that
work for you (and more) automatically. And I would argue that
the mnemonics are easier to remember (hey, isn't that what
mnemonic is defined as?!) than seemingly arbitrary rules about
which LD combinations are legal and which aren't.
What I'm saying is this: The Z80 mnemonic LD isn't one instruction.
It actually assembles to one of a couple dozen different instructions,
all with radically different binary forms. This is a complete
breakaway from, say, 8080 or PDP-11 assembler, where each mnemonic
is one instruction, and where the argument bit patterns get filled
in in a very predictable manner. Folks like me who grew up with
assemblers that directly map mnemonics to instructions like it
that way, because knowing the mnemonic tells you a lot about
what actually happens at the machine level. I feel uncomfortable
with assemblers that hide the machine level stuff from me.
Tim. (sho...@trailing-edge.com)
Andrew Cadley
Tim Shoppa wrote in message <36532888...@trailing-edge.com>...
:The above different sorts of moves are *very* different to
:someone who's learned 8080A assembly language, or who has
:spent years of their lives toggling programs into front panel
:machines. Within any given type of move, the move is
:orthogonal, and the 8080A mnemonics nicely delineate the
:different classes of moves to keep clear what is possible.
:For instance, you can't do a LD B,(DE) (in Z-80 style mnemonic)
:on an 8080A, and you wouldn't dream of doing so in 8080A
:mnemonics because such a mnemonic doesn't exist.
Hmm, well 8080 has the *appearance* of being more orthagonal, but IMHO, it
actually conceals far more than Z80. For example the Z80 instruction LD
A,(HL) has an obvious dependency on the HL register pair. The use of M in
8080 as a psuedo-register makes that much less obvious.
I don't really see any advantage in having different mnemonics for the
different types of load. IT doesn't take long to learn which combinations
are possible in Z80 and you have far less instruction mnemonics to remember,
since every type of load uses LD.
:Why should a programmer care what class of "load" they're doing?
:Every byte counts, and the number of bytes and cycles it takes
:to do each operation is perfectly clear in 8080A mnemonics.
But it isn't exactly difficult to see which addressing modes are being used
by the Z80, is it? For instance, in 8080 the MOV B,A and MOV M,A
instructions appear to be the same. In reality one uses implicit addressing,
the other indirect. The Z80 equivalents LD A,B and LD A,(HL) are quite
obviously using different addressing modes due to the introduction of the
brackets.
:Yep, to the untrained eye they all perform the same operation.
:To folks who have to worry about how many bytes are used by
:each instruction and how many clocks it takes to execute
:each instruction, the "LD" is a pain in the butt because it
:hides these important details.
No it doesn't. It arranges all of the data transfer operations into a single
class, the LD group. The addressing modes are obvious from the parameters.
Since the timing and length of the instructions is wholly dependent on the
addressing mode it is quite easy to see how long, or how many bytes an
instruction requires.
:IMHO, if you're using assembler, it's because you want to
:get involved at the detailed level. Anything that hides
:these details from you - like the Z80 mnemonics - is doing
:you more harm than good.
So you don't want to hide the details, but you prefer an assembler to
"disguise" indirect addressing via the HL pair by using a pseudo-register M?
I really don't see the logic in that argument. Give me the much more
straightforward and far easier to read Z80 anyday.
AndyC
Gene Wirchenko
>In article <72viq9$g90$1...@cronkite.cs.umd.edu> f...@cs.umd.edu
>(Marat Fayzullin) writes:
[snip]
>>How are they different? I agree that they are different in the
>>way CPU internals perform them, but for me as a programmer they
>>are all the same: data transfers. I simply don't care how CPU
>>performs them, as long as they are around.
>
>See my last sentence above. If I'm down to assembly language,
>I often _do_ care how the CPU does it.
So why not just skip the assembler and go to the bits? Don't let
"LD" or "MOV" get in the way of grooving to the 0s and 1s. <gd&rvvf>
>>Lousy argument. Zilog uses "LD" for data transfers. They are all
>>called LD because they all perform the same operation, including
>>the infamous LD PC,<addr> opcode. There is a lot of other mnemonics
>>in Z80 assembly though, ADD, EX, DEC, and INC to name a few.
>
>Why "LD" instead of something that better suggests a general
>move, such as "MOV"? Whenever I see "LD" I think "Load". This
>isn't too appropriate for a move from a register to memory, which
>is commonly referred to as a "store". "Load" is usually reserved
>to mean a move in the opposite direction.
A move? Come on! "LD" is much better because a value is being
loaded. "MOV" is inaccurate as the value is NOT being moved. It's
still at the source after the load. "COPY" is another possible,
accurate opcode.
>>: * Yes, I know that the Zilog mnemonic for an unconditional jump
>>: is JP, even though every fiber of my being screams, "NO! That's
>>: wrong! JP means Jump if Plus!" But I hate the format of the
>>: Zilog jump instructions too, so there. :-p
>>
>>Then how you distinguish it from JR? Remember, Z80 has relative
>>jumps. 8080 doesn't.
>
>JRZ, JRNZ, etc. I got used to extended branch mnemonics on the
>IBM 360, although I do admit it took me a while. On the 1620, on
>the other hand, the different conditional branches were separate
>instructions with unique first bytes, just like on the 8080/Z-80.
>(But I could be opening a whole new can of worms regarding
>instruction decoding if we follow that one too far...)
>
>Still, if the mnemonic was more obviously "Jump on Condition" (the
>360 uses "BC" as in "Branch on Condition"), I might find it easier
>to swallow. JP just doesn't sound like "jump" to me, I guess.
I did a bit of /370 Assembler. I did like the jump mnemonics.
You'd hate PDPs then, eh? I understand from the PDP afficionados
(spelling?) that JUMP on PDPs doesn't jump.
>>PS: Some of the most dreadful mnemonics I have seen in my life
>> were XTHL,SPHL,PCHL, and XCHG (*four* consonants in a row),
>> all from 8080. I am sure IBM/360 programmers will readily
>> come with even worse ones though.
>
>Those one _are_ a mouthful. I spell the first three letter by
>letter. The last one can be pronounced "exchange", though.
Um, how about "ex-thil", "spill", and "pitch-el"? I didn't spit
much saying them.
>Let's see, the 360 has things like MVC, MVN, and MVZ, which again
>are easier to just spell out. But it also has ZAP, which is kind
"move-see", "move-en", and "move-zee"?
>of fun. Then there are the inbetween ones like BXLE. Most people
>pronounce that one "bixel", but I once heard someone pronounce it
>"boxel" and I liked it so much I adopted it. No such luck with its
>sister instruction BXH, though...
I'd probably say "bixel" or maybe "bix-lee". That isn't from
ever using it.
"bix-huh" or "bix-hi"?
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
Tim Shoppa
> You'd hate PDPs then, eh? I understand from the PDP afficionados
> (spelling?) that JUMP on PDPs doesn't jump.
On a PDP-11 it does. You're thinking of the PDP-10, where a
JUMP without any condition codes never jumps (because the condition
is never met!)
Tim. (sho...@trailing-edge.com)
Mel Wilson
d...@news.daedalus.co.nz (Don Stokes) wrote:
>In article <863e7ib...@home.com>, <skr...@home.com> wrote:
>make more sense than the Intel equivalents (mov to,from), but that's
>probably because the Intel way is backwards from the DEC way (mov from,to)
>that I'm used to.)
Working with assembly macros, I liked the Zilog mnemonics too.
Because the operand source was coded with the operand, I could set up a
macro like
MIDISEND 90h ; note-on command
MIDISEND e ; note number pre-calculated in E
MIDISEND (vel) ; velocity set in memory sometime before
and the macro didn't have to do handsprings finding the opcode to use in
each separate instance.
Regards. Mel.
Gene Wirchenko
>Marat Fayzullin wrote:
>>
>> Tim Shoppa (sho...@trailing-edge.com) wrote:
>> : Why should a programmer care what class of "load" they're doing?
>> : Every byte counts, and the number of bytes and cycles it takes
>> : to do each operation is perfectly clear in 8080A mnemonics.
>> : The Z80 mnemonics hide all this, making the actual operation
>> : much more opaque. (I won't start complaining about all the
>> : "prefix" opcodes the Z80 designers had to introduce to deal
>> : with the IX and IY registers.)
>> Incorrect. If we do not look at the IX/IY operations, you will
>> have to agree that each Z80 opcode takes 1 (one) byte plus
>> as many bytes as it's argument takes.
>
>Well, you're leaving out the BIT, SET, and RESET prefixes,
>which can be combined with the IX and IY prefixes to create
>very long "instructions", i.e. BIT 6,(IX+08) assembles to
>DDCB0876, four bytes. Notice that the "08" is sort-of an
>argument (it takes a byte), while the "6" isn't in the same
>sense.
Sure it is. It's just that only three bits are needed to encode
it. If you want an example of "isn't in the same sense, look at LDA.
The A register is implied. "LDA"? There's that "LD" again.
>> Execution time may differ (of course), but it also doesn't take
>> too much time to deduce from the number of parenthesis and
>> numerical arguments.
>
>Actually, it's much more complicated than just counting
>parentheses and numerical arguments. When counting cycles,
>you *have* to think of all the different LD forms, and their
>various IX and IY prefixes, as different instructions. The
>LD mnemonic form is just hiding this from you.
Personally, I found the 8080 numbmonics hid stuff from me.
Trying to figure out the memory transfer instructions was a pain. In
the Z-80 mnemonics, it all got dealt with by LD and there was no need
to go flipping through the manual looking for another one that might
do it.
When confronted with 8080 mnemonics, I would mentally convert
most to Z-80.
>If it's just a matter of counting parantheses, how come
>LD HL,(8) takes such a substantially different amount of time
>than LD (IY+08),C ?
And numerical arguments. "IY+08" is a clue.
>> Now, if you look at 80x86 architecture from the same Intel, and
>> look at how much time ADD to AX takes in comparison to, let us
>> say, ADD to DX, you will see what "non-orthogonal" means.
>
>I'll agree that 80x86 mnemonics are just as bad, if not worse,
>than Z80 mnemonics :-).
So it's good that I never did get around to x86 Assembler?
>> : IMHO, if you're using assembler, it's because you want to
>> : get involved at the detailed level. Anything that hides
But not too detailed or you would simply write your code in
binary.
>> : these details from you - like the Z80 mnemonics - is doing
>> : you more harm than good.
Come on! Different levels of abstraction! To me, most of the
time, the non-semantic details of the instruction don't matter, but if
I want to check, say, the execution time of an instruction, I can look
it up and I can find the right one -- the mnemonics are NOT confusing
to me.
>> Anything that makes me memorize hundreds of different mnemonics
>> will do me more harm than good by making my brain do additional
>> useless work.
>
>But with "LD" you're doing the work of remembering which LD
>forms are legal and which aren't. LD A,I works, but LD B,I
>doesn't. LD (HL),C works but LD (DE),C doesn't, yet LD (DE),A
>does. You've got to remember all the rules for what different
>real operations are possible with LD, when 8080 mnemonics do that
>work for you (and more) automatically. And I would argue that
>the mnemonics are easier to remember (hey, isn't that what
>mnemonic is defined as?!) than seemingly arbitrary rules about
>which LD combinations are legal and which aren't.
Six of one, half a dozen of another. It's syntactic sugar. Some
of us like the white sugar and some of us like the brown sugar. I
don't think that either is *inherently* better. See my sig.
>What I'm saying is this: The Z80 mnemonic LD isn't one instruction.
>It actually assembles to one of a couple dozen different instructions,
>all with radically different binary forms. This is a complete
>breakaway from, say, 8080 or PDP-11 assembler, where each mnemonic
>is one instruction, and where the argument bit patterns get filled
>in in a very predictable manner. Folks like me who grew up with
>assemblers that directly map mnemonics to instructions like it
>that way, because knowing the mnemonic tells you a lot about
>what actually happens at the machine level. I feel uncomfortable
>with assemblers that hide the machine level stuff from me.
Well, they all do. That was the intention.
Oh, sure I know a few Z-80 opcodes: RET is C9, CALL is CD, JP is
C3, the RSTs were 00ddd111, but XOR A assembles to, ah, who cares?
The assembler will deal with it; that's why I'd use one.
Sincerely,
Gene Wircheno
Scott Lanning
:"MOV" is inaccurate as the value is NOT being moved. It's still at the
:source after the load. "COPY" is another possible, accurate opcode.
Last spring, I took an electronics class where I programmed an M68008
CPU using a keypad to enter hex instructions (wrote the program in
assembly then, looked-up the codes). At first, I thought move.b
actually moved the byte, leaving the old register blank or
indeterminate; I mean, why else would they name it move?!? I ended
doing something contorted, like loop while decrementing until zero
and simulataneously incrementing two other registers (or something
like that). Next day, the prof (Tom Hayes, excellent teacher and man)
mentioned that move should probably be named copy, and I think I
audibly groaned...
--
Scott
Andrew Cadley
Tim Shoppa wrote in message <36536059...@trailing-edge.com>...
:Actually, it's much more complicated than just counting
:parentheses and numerical arguments. When counting cycles,
:you *have* to think of all the different LD forms, and their
:various IX and IY prefixes, as different instructions. The
:LD mnemonic form is just hiding this from you.
No you don't. The length (in both bytes and cycles) can easily be deduced
from the addressing modes used by the two arguments for LD.
:If it's just a matter of counting parantheses, how come
:LD HL,(8) takes such a substantially different amount of time
:than LD (IY+08),C ?
Because LD HL,(8) is using 16-bit absolute addressing wheras LD (IY+08),C is
using indexed addressing. The difference is obvious and largely irrelevant
in this thread anyway, given that indexed addressing simply doesn't exist on
the 8080.
:But with "LD" you're doing the work of remembering which LD
:forms are legal and which aren't. LD A,I works, but LD B,I
:doesn't. LD (HL),C works but LD (DE),C doesn't, yet LD (DE),A
:does. You've got to remember all the rules for what different
:real operations are possible with LD, when 8080 mnemonics do that
:work for you (and more) automatically. And I would argue that
:the mnemonics are easier to remember (hey, isn't that what
:mnemonic is defined as?!) than seemingly arbitrary rules about
:which LD combinations are legal and which aren't.
But it doesn't take very long to learn which addressing modes are valid and
it is certainly easier to remember than several different mnemonics for the
same type of instruction. It is also much easier to read and understand Z80
(with the possible exception of the block operations) than 8080 because
there are less mnemonics and less hidden information.
:What I'm saying is this: The Z80 mnemonic LD isn't one instruction.
:It actually assembles to one of a couple dozen different instructions,
:all with radically different binary forms. This is a complete
:breakaway from, say, 8080 or PDP-11 assembler, where each mnemonic
:is one instruction, and where the argument bit patterns get filled
:in in a very predictable manner. Folks like me who grew up with
:assemblers that directly map mnemonics to instructions like it
:that way, because knowing the mnemonic tells you a lot about
:what actually happens at the machine level. I feel uncomfortable
:with assemblers that hide the machine level stuff from me.
True to some extent although 8080 conceals certain facts about the
addressing modes as well. MOV M,A takes longer (7 cycles, IIRC) than MOV B,A
(4 cycles) so it hardly makes everything perfectly clear.
Actually the whole business about using M instead of (HL) sucks big time,
because it makes dependencies in the code less obvious to the casual
observer. Of course, Z80 isn't entirely free of this type of thing but I
dread to think how you would describe the dependencies of LDIR in a single
instruction. :)
Also the larger instruction set of the Z80 would have required even more
mnemonics for a 1:1 mapping and that would have been far too many.
AndyC
Marat Fayzullin
: Marat Fayzullin wrote:
: > Incorrect. If we do not look at the IX/IY operations, you will
: > have to agree that each Z80 opcode takes 1 (one) byte plus
: > as many bytes as it's argument takes.
: Well, you're leaving out the BIT, SET, and RESET prefixes,
: which can be combined with the IX and IY prefixes to create
: very long "instructions"
: LD HL,(8) takes such a substantially different amount of time
: than LD (IY+08),C ?
: > Anything that makes me memorize hundreds of different mnemonics
: > will do me more harm than good by making my brain do additional
: > useless work.
: But with "LD" you're doing the work of remembering which LD
: forms are legal and which aren't.
It's ok: I just feed them to assembler as I write and eventually
start to evade the non-existant ones or write macros for them.
: What I'm saying is this: The Z80 mnemonic LD isn't one instruction.
: It actually assembles to one of a couple dozen different instructions,
: all with radically different binary forms.
Which is perfectly ok with me.
: This is a complete
: breakaway from, say, 8080 or PDP-11 assembler, where each mnemonic
: is one instruction
PDP11 is a *really* bad example here. If we are to stay consistent,
DEC would be required to make up a new mnemonic for each addressation
method used by its instructions, which is not a case with PDP11
assembly. Using your own rhetorics, this would be the only way to know
Charlie Gibbs
(Marat Fayzullin) writes:
>Charlie Gibbs (cgi...@sky.bus.com) wrote:
>
>: Yup, someone bit. :-)
>
>But of course :)
>
>: Why "LD" instead of something that better suggests a general
>: move, such as "MOV"? Whenever I see "LD" I think "Load". This
>: isn't too appropriate for a move from a register to memory, which
>: is commonly referred to as a "store". "Load" is usually reserved
>: to mean a move in the opposite direction.
>
>Does the sentence "Load a memory cell from the register"
>sound like a broken English to you?
Not so much broken English as improper usage. The distinction
between "load" and "store" that I gave above reflects a convention
much older than the Z-80.
>"MOVE", on the other hand, is an English verb used to mean a removal
>of an object from location A and placing it to location B. Do any of
>the 8080 operations we are talking about remove anything from anywhere?
No. But doesn't the word "load" also imply a removal of an object
from its original location? I grant your point that in everyday
English, moving (or loading) an object removes it from location
A before placing it in location B. However, the common usage of
these terms in computer parlance (assembly language in particular -
the MS-DOS MOVE command doesn't count) implies a copy without removal
from the source location.
Charlie Gibbs
(Gene Wirchenko) writes:
>"Charlie Gibbs" <cgi...@sky.bus.com> wrote:
>
>>Why "LD" instead of something that better suggests a general
>>move, such as "MOV"? Whenever I see "LD" I think "Load". This
>>isn't too appropriate for a move from a register to memory, which
>>is commonly referred to as a "store". "Load" is usually reserved
>>to mean a move in the opposite direction.
>
> A move? Come on! "LD" is much better because a value is being
>loaded. "MOV" is inaccurate as the value is NOT being moved. It's
>still at the source after the load.
The same applies to "LD". If you load something on a truck, it's
no longer on the loading dock. Of course, the same argument also
applies to "store" - but it's still an ancient (in computer terms)
convention that data is LOADed into an accumulator from memory,
and STOREd from an accumulator to memory.
>"COPY" is another possible, accurate opcode.
True. Maybe future processor designers should consider this,
if they're feeling bold enough to challenge the convention.
>>>PS: Some of the most dreadful mnemonics I have seen in my life
>>> were XTHL,SPHL,PCHL, and XCHG (*four* consonants in a row),
>>> all from 8080. I am sure IBM/360 programmers will readily
>>> come with even worse ones though.
>>
>>Those one _are_ a mouthful. I spell the first three letter by
>>letter. The last one can be pronounced "exchange", though.
>
> Um, how about "ex-thil", "spill", and "pitch-el"? I didn't
>spit much saying them.
Hmm, I'd probably want to say "sphil", but aside from that you
have a point. You can do rather a lot by strategically inserting
a schwa here and there.
>>Let's see, the 360 has things like MVC, MVN, and MVZ, which again
>>are easier to just spell out. But it also has ZAP, which is kind
>
> "move-see", "move-en", and "move-zee"?
Or "muvuc", "muven", and "muvz".
>>of fun. Then there are the inbetween ones like BXLE. Most people
>>pronounce that one "bixel", but I once heard someone pronounce it
>>"boxel" and I liked it so much I adopted it. No such luck with its
>>sister instruction BXH, though...
>
> I'd probably say "bixel" or maybe "bix-lee". That isn't from
>ever using it.
I've heard both pronunciations.
> "bix-huh" or "bix-hi"?
I've tried to imagine things like "bugzh", but usually gave up.
I hardly ever used BXH anyway. :-)
barnacle
instructions for the cpu and fld/fst for the fpu...guess they couldn't make up
their minds...
barnacle
nailed-barnacle.home.ml.org
Nick Spalding
> No. But doesn't the word "load" also imply a removal of an object
> from its original location? I grant your point that in everyday
> English, moving (or loading) an object removes it from location
> A before placing it in location B. However, the common usage of
> these terms in computer parlance (assembly language in particular -
> the MS-DOS MOVE command doesn't count) implies a copy without removal
> from the source location.
In the IBM 1401 Move and Load both did a copy operation from one
memory location to another (there were no programmer accessible
registers) but Move only copied the data bits and Load copied the Word
Marks as well.
--
Nick Spalding
AutismUK
In article <731mj4$9...@cpca3.uea.ac.uk>, "Andrew Cadley" <a.p.c...@uea.ac.uk>
writes:
>Because LD HL,(8) is using 16-bit absolute addressing wheras LD (IY+08),C is
>using indexed addressing. The difference is obvious and largely irrelevant
>in this thread anyway, given that indexed addressing simply doesn't exist on
>the 8080.
Well, actually it does.... LD A,(HL) for example. It just doesn't have
offset indexed addressing.
Mr NitPick (auti...@aol.com)
Tim Shoppa
> : This is a complete
> : breakaway from, say, 8080 or PDP-11 assembler, where each mnemonic
> : is one instruction
> PDP11 is a *really* bad example here. If we are to stay consistent,
> DEC would be required to make up a new mnemonic for each addressation
> method used by its instructions, which is not a case with PDP11
> assembly. Using your own rhetorics, this would be the only way to know
> "what actually happens at the machine level".
I don't object to different addressing modes usable by the
same instruction. (Indeed, in 8080A mnemonics you can put "M"
anywhere you can put a register operand.) What I object to are
similar looking mnemonics that assemble to completely different
instructions; for example, LD A,(HL) is a very different opcode
(167 octal) than the opcode (012) for LD A,(BC). Then if you
get into the (IX) and (IY) modes all of a sudden the opcode
becomes doubled in length, despite the fact that the mnemonic
syntax looks much the same as if (HL) or (BC) was used.
The PDP-11's MOV mnemonic is, on the other hand, entirely
orthogonal: there's a 16-bit opcode, 6 bits determine the source
register and addressing mode, another 6 bits determine the destination
register and addressing mode. The opcode is never suddenly
lengthened by a word for certain addressing modes, and the
opcode's bit positions aren't arbitrarily rearranged for
certain addressing modes.
Note that there are separate PDP-11 mnemonics for move-type
operations that don't fit into the MOV mold; for instance, the
MFPI (Move From Previous Instruction Space), MFPF (Move
From Previous Data Space), MFPT (Move from Processor model Type),
etc., all get their own special opcodes. This, of course, is
how it should be, because these instructions don't fit the MOV
model at all.
Tim. (sho...@trailing-edge.com)
than LD A,(BC), which itself is
Gene Wirchenko
>In article <3653bf1a...@news.vip.net> ge...@vip.net
>(Gene Wirchenko) writes:
[snip]
>> Um, how about "ex-thil", "spill", and "pitch-el"? I didn't
>>spit much saying them.
>
>Hmm, I'd probably want to say "sphil", but aside from that you
>have a point. You can do rather a lot by strategically inserting
>a schwa here and there.
>
>>>Let's see, the 360 has things like MVC, MVN, and MVZ, which again
>>>are easier to just spell out. But it also has ZAP, which is kind
>>
>> "move-see", "move-en", and "move-zee"?
>
>Or "muvuc", "muven", and "muvz".
>
>>>of fun. Then there are the inbetween ones like BXLE. Most people
>>>pronounce that one "bixel", but I once heard someone pronounce it
>>>"boxel" and I liked it so much I adopted it. No such luck with its
>>>sister instruction BXH, though...
>>
>> I'd probably say "bixel" or maybe "bix-lee". That isn't from
>>ever using it.
>
>I've heard both pronunciations.
>
>> "bix-huh" or "bix-hi"?
>
>I've tried to imagine things like "bugzh", but usually gave up.
>I hardly ever used BXH anyway. :-)
I wonder how many assembler instructions are avoided because the
programmer can't pronounce them. Imagine a code review: "Then there's
a [XTHL]... uh ext-hell? cross thill? ex-tee-aitch-el... followed by
a... how do you say it...? Um... %^&$$%%$# IT ALL! I'm replacing it
all with eight-bit loads! See you tomorrow."
Sincerely,
Gene Wirchenko
Andrew Cadley
AutismUK wrote in message <19981119164536...@ngol08.aol.com>...
:In article <731mj4$9...@cpca3.uea.ac.uk>, "Andrew Cadley"
<a.p.c...@uea.ac.uk>
:writes:
That isn't really indexed though is it, it's register indirect. So I was
right, sort of.
AndyC
jmfb...@aol.com
You guys are just a tad confused, I think :-). I'll give you the
instruction set for the JUMP instruction as written up in our
cheat sheet cards. I will capitalize the characters that are part
of the instruction mneumonic.
JUMP if ac }--- never
Less
Equal
Less or Equal
Always
Greater
Greater or Equal
Not equal
So if I want to jump to a location, X, when the contents of the AC
are greater than or equal to zero, instruction line in the code
would look like this:
JUMPGE AC,X
So you are correct that a JUMP AC,X would never jump (we always
called them a NOOP). However, we always used JFCL for a NOOP
because it was a faster instruction.
A good discussion would be _why_ we used NOOPs; I don't recall
ever writing a NOOP in FORTRAN.
/BAH
/BAH
Subtract a hundred and four for e-mail.
gla...@glass2.cv.lexington.ibm.com
I never played with an 8080 much, but I did map out the undocumented
opcodes on a 6800 once (Ok, so I was bored.). :*) Among the opcodes
I found were a Store direct instruction, and a couple of HCF (Halt
and Catch Fire) instructions (There were instructions which tri-stated
the data bus and the control lines, which let the R/W line float to
the write state, and put the address bus into a 16 bit counter mode.
Thus, it wiped all of the memory in about a tenth of a second.).
Of course, since these instructions were undocumented, the manufacturer
of the chip was at liberty to change the behavior of these instructions
at any time. Thus, a programmer who designed who designed a program to
exploit one of these instructions could have his program stop working
when it was moved to another system (or, if the processor was ever
replaced in the primary system).
Dave
P.S. Standard disclaimer: I work for them, but I don't speak for them.
gla...@glass2.cv.lexington.ibm.com
>In article <7306d3$e61$2...@cronkite.cs.umd.edu> f...@cs.umd.edu
>(Marat Fayzullin) writes:
>
>>Charlie Gibbs (cgi...@sky.bus.com) wrote:
>>
>>: Yup, someone bit. :-)
>>
>>But of course :)
>>
>>: move, such as "MOV"? Whenever I see "LD" I think "Load". This
>>: isn't too appropriate for a move from a register to memory, which
>>: is commonly referred to as a "store". "Load" is usually reserved
>>: to mean a move in the opposite direction.
>>
>>sound like a broken English to you?
>
>Not so much broken English as improper usage. The distinction
>between "load" and "store" that I gave above reflects a convention
>much older than the Z-80.
>
>>"MOVE", on the other hand, is an English verb used to mean a removal
>>of an object from location A and placing it to location B. Do any of
>>the 8080 operations we are talking about remove anything from anywhere?
>
>from its original location? I grant your point that in everyday
>English, moving (or loading) an object removes it from location
>A before placing it in location B. However, the common usage of
>these terms in computer parlance (assembly language in particular -
>the MS-DOS MOVE command doesn't count) implies a copy without removal
>from the source location.
>
Of course, don't forget that with certain memory technologies that
were in use in the early days of computers (e.g., core memory) a read
of a memory location was destructive. Thus, the process of pulling a
value out of a memory location to be placed into an accumulator
resulted in the memory location being cleared. Thus, maybe "Load" was
appropriate back then.
Of course, with any system where the designers weren't on a permanent
coffee break, the memory controller would immediately perform a write
back into the memory location just read so that a read wouldn't be
destructive.
Dave
P.S. Standard Disclaimer: I work for them, but I don't speak for them.
Tim Shoppa
> A good discussion would be _why_ we used NOOPs; I don't recall
> ever writing a NOOP in FORTRAN.
Did you ever use CONTINUE ? (Or do you not count CONTINUE
as a NOOP ?)
Tim.
Tim Shoppa
> Of course, don't forget that with certain memory technologies that
> were in use in the early days of computers (e.g., core memory) a read
> of a memory location was destructive. Thus, the process of pulling a
> value out of a memory location to be placed into an accumulator
> resulted in the memory location being cleared. Thus, maybe "Load" was
> appropriate back then.
>
> Of course, with any system where the designers weren't on a permanent
> coffee break, the memory controller would immediately perform a write
> back into the memory location just read so that a read wouldn't be
> destructive.
No, that's what the designers did if the *were* on a permanent
coffee break. The good designers had the CPU specifiy two kinds
of read cycles:
1. Read followed by memory controller write back ("DATI"
in Unibus terminology). Used, for example, on a memory-
to-register operation.
2. Destructive read, not followed by memory controller
write back ("DATIP" in Unibus terminology) This is used
for instructions where the CPU is going to immediately
be writing data to the same memory location, so there's
no need for the memory controller to do so. Used, for
example, on an add-register-to-memory-location operation.
The write-back on a mid-70's minicomputer took of order 100ns,
as compared to the 300ns or read, so there was a potential 25%
speedup on read-modify-write access cycles. (See, for example,
any mid-to-late-70's _PDP-11 Processor Handbook_.)
Admittedly, on many instruction streams the number of cycles
that would be saved by read-modify-write cycles was much less
than 25%. But there are inner loops of some codes - for
example, matrix-vector or matrix-matrix multiply loops - where
near-maximum speedups are realized. And for systems where
DMA I/O was a substantial fraction of the memory bus traffic
freeing up even 5-10% of the bus time can substantially improve
the success of timing-critical I/O transfers.
Alan Bowler
>
>What I'm saying is this: The Z80 mnemonic LD isn't one instruction.
>It actually assembles to one of a couple dozen different instructions,
>breakaway from, say, 8080 or PDP-11 assembler, where each mnemonic
>in in a very predictable manner. Folks like me who grew up with
>assemblers that directly map mnemonics to instructions like it
>that way, because knowing the mnemonic tells you a lot about
>with assemblers that hide the machine level stuff from me.
I agree. When I ported the Zed compiler to the z8000, I spent
ages going over the manual trying to discover what the real
instruction set was. (writing down bits patterns etc.)
I eventually found a very nice classic register storage architecture
that was completely hidden under the archane variations of
LD in the documentation. I made up my own nmemonics using old fashioned
names like load, store, load immediate etc that mapped to fixed
machine opcodes, and the rest proceeded smoothly. The guy that ported
TLA (The Last Assembler) used my choice of opcodes.
Nick Spalding
> No, that's what the designers did if the *were* on a permanent
> coffee break. The good designers had the CPU specifiy two kinds
> of read cycles:
>
> 1. Read followed by memory controller write back ("DATI"
> in Unibus terminology). Used, for example, on a memory-
> to-register operation.
>
> 2. Destructive read, not followed by memory controller
> write back ("DATIP" in Unibus terminology) This is used
> for instructions where the CPU is going to immediately
> be writing data to the same memory location, so there's
> no need for the memory controller to do so. Used, for
> example, on an add-register-to-memory-location operation.
>
> The write-back on a mid-70's minicomputer took of order 100ns,
> as compared to the 300ns or read, so there was a potential 25%
> speedup on read-modify-write access cycles. (See, for example,
> any mid-to-late-70's _PDP-11 Processor Handbook_.)
On the IBM 7010 the read-write, or A cycle, took 2.4 microsecs, the
read-modify-write, or B, took 3.2. For an even-odd address pair of
consecutive characters in both cases.
--
Nick Spalding
lis...@zetnet.co.uk
On 1998-11-18 cgi...@sky.bus.com said:
:I thought of modifying my assembler (or at
:least adding macros) to make it so: e.g. LD @A,<addr> instead
:of INP, or LD PC,<addr> instead of JMP(*), for instance. Once
:all instructions have the same op code, you can get rid of it
:entirely, and write your program as just a series of operands. :-)
Yes, but things like ADD get difficult. :> However, in machines where
you have the PC and other important registers in the general register
set, you can dispose of the JMP instructions entirely (eg. ARM) - but
the assemblers seem to define those instructions anyway. (Why?)
--
Communa (lis...@zetnet.co.uk) -- you know soft spoken changes nothing
lis...@zetnet.co.uk
On 1998-11-19 a.p.c...@uea.ac.uk said:
:Hmm, well 8080 has the *appearance* of being more orthagonal, but
:IMHO, it actually conceals far more than Z80. For example the Z80
:instruction LD A,(HL) has an obvious dependency on the HL register
:pair. The use of M in 8080 as a psuedo-register makes that much
:less obvious.
But wasn't that inherited from the 8008, where M was the *only* way of
accessing something from memory? No ambiguity there, unless you were
going to spend all day looking for the M register.
:I don't really see any advantage in having different mnemonics for
:the different types of load. IT doesn't take long to learn which
:combinations are possible in Z80 and you have far less instruction
:mnemonics to remember, since every type of load uses LD.
Yes, but remembering gaps is always more of a hassle than remembering a
few extra mnemonics with consistency through them. Adding is easier than
subtracting. I'd much rather have LDI instructions dotted throughout my
x86 code. (In fact, I might do an assembler that way. & NEC's V20 manual
did use Z80-type mnemonics instead of Intel ones.)
:But it isn't exactly difficult to see which addressing modes are
:being used by the Z80, is it? For instance, in 8080 the MOV B,A and
:MOV M,A instructions appear to be the same. In reality one uses
:implicit addressing, the other indirect. The Z80 equivalents LD A,B
:and LD A,(HL) are quite obviously using different addressing modes
:due to the introduction of the brackets.
Yes, but MOV A, B and LD A,(HL) makes it even clearer. It also makes the
assembler much simpler to code, since you don't have to hover about
trying to parse one mnemonic into several completely different
instruction varieties. Forth x86 assemblers are worth looking at, to see
what a mess it is (compare and contrast with, say, a 6800 assembler).
:No it doesn't. It arranges all of the data transfer operations into
:a single class, the LD group. The addressing modes are obvious from
:the parameters. Since the timing and length of the instructions is
:wholly dependent on the addressing mode it is quite easy to see how
:long, or how many bytes an instruction requires.
Until you have to remember that LD A,(IX) takes many more cycles and 2
bytes longer than an LD A,(HL). That's far from obvious. (You'd rather
write it LD A,(IX+0)? Then why not have MOV A,D instead of LD A,D?)
:So you don't want to hide the details, but you prefer an assembler
:to "disguise" indirect addressing via the HL pair by using a
:pseudo-register M? I really don't see the logic in that argument.
Nor do I, but I don't think it's his either. These things happen
somewhere along threads...
--
Communa (lis...@zetnet.co.uk) -- you know soft spoken changes nothing
Net-Tamer V 1.08X - Test Drive
lis...@zetnet.co.uk
On 1998-11-19 a.p.c...@uea.ac.uk said:
:Actually the whole business about using M instead of (HL) sucks big
:time, because it makes dependencies in the code less obvious to the
:casual observer. Of course, Z80 isn't entirely free of this type of
:thing but I dread to think how you would describe the dependencies
:of LDIR in a single instruction. :)
Well, at least that set of instructions is completely consistent,
self-contained and sane, unlike the rest of the LD & CP groups, and
streets ahead of Intel's MOVS WORD PTR [SI], WORD PTR ES:[DI] notation.
Of course,
LDS I, R
would be even nicer... ;> Incidentally, the thing I really liked about
the 6502 was that all the instructions had TLMs. For some reason I
enjoyed the consistency...
--
Communa (lis...@zetnet.co.uk) -- you know soft spoken changes nothing
(OK, PSH was pshing it.)
lis...@zetnet.co.uk
On 1998-11-19 f...@cs.umd.edu(MaratFayzullin) said:
:PDP11 is a *really* bad example here. If we are to stay consistent,
:DEC would be required to make up a new mnemonic for each
:addressation method used by its instructions, which is not a case
:with PDP11 assembly. Using your own rhetorics, this would be the
:only way to know "what actually happens at the machine level".
No they wouldn't. The opcode bits don't change, only the bits which
determine the addressing mode. They're in a fixed place anyway, so that
isn't a problem. Encoding is much more convoluted in the Z80, and you
probably do want a new mnemonic for each case, because there's no
consistent (a) set of addressing modes, (b) place to set them.
Perhaps we can all just agree that the Z80's instruction set was a right
mess because of the need to retain compatibility with the 8080...
lis...@zetnet.co.uk
On 1998-11-19 nailed_...@junkfree.hotmail.com(barnacle) said:
:Of course, Intel improve things no end with the x86/87 where you
:have 'mov' instructions for the cpu and fld/fst for the fpu...guess
:they couldn't make up their minds...
Oh, yes, the x86. With its multiple ways of encoding instructions, some
of which are shorter and execute more quickly than others (and sometimes
it's the long variants which are the quick variants!), you gotta love
that one.
(Oh, and MOV gt used for everything, whether or not it was appropriate.)
Arargh!
wrote:
>Charlie Gibbs wrote:
>
<snip>
>In the IBM 1401 Move and Load both did a copy operation from one
>memory location to another (there were no programmer accessible
>registers) but Move only copied the data bits and Load copied the Word
>Marks as well.
Sure there were, if you had paid for the advanced programming feature.
They just happened to be in memory, but were used as registers.
arargh
phil
<eric-no-s...@brouhaha.com> wrote:
>skr...@home.com writes:
>> But I thought the Altair 8800 used a Zilog chip.
>
>Nope. It used the good 'ol 8080. The Zilog chip wasn't even announced
>until more than a year after the Altair 8800 shipped.
>
>The Z-80 is nowhere near pin-compatible with the 8080. The 8080 requires
>a two-phase non-overlapping clock at MOS levels, and requires some external
>logic to decode the bus status. Intel offered support chips for clock
>generation and bus interfacing, but AFAIK the Altair did not use them,
>probably because they were expensive. The Z-80 was much easier to design
>with, because it only required a single-phase clock (almost but not quite
>TTL compatible), and had internal bus signal decoding.
Didn't the Z80 also offer some decent support for refreshing dynamic
ram?
>Software-wise, the Z-80 is mostly upward compatible from the 8080. I've heard
>that there was a change in how one of the flag bits was affected by one
>instruction, but I'm not sure if that is true. Zilog adopted a different (and
>more logical) set of mnemonics, possibly because Intel claimed that the 8080
>mnemonics were copyrighted. However, the object code was identical.
The big attraction of the 8080 mnemonics is that you can write haikus
using them and the result may actually assemble (with appropriate
comment lines). The Z80 mnemonics were far too logical.
phil.
lxi h,99
push l
pop h
lxi h,99
ret ;all is the same
jmfb...@aol.com
Actually no. I always used a CONTINUE statement to close a
DO loop. I realize it wasn't necessary at the time but became
more so as we transported our programs to other manufacturer's
compilers.
Andrew Cadley
lis...@zetnet.co.uk wrote in message <7357vh$uiv$9...@irk.zetnet.co.uk>...
:Yes, but things like ADD get difficult. :> However, in machines where
:you have the PC and other important registers in the general register
:set, you can dispose of the JMP instructions entirely (eg. ARM) - but
:the assemblers seem to define those instructions anyway. (Why?)
I believe the word you're looking for is readability.
It makes far more sense to have a JMP rather than an LD PC type instruction.
In much the same way that my Z80 assembler supports LD HL,BC as a
replacement for LD H,B; LD L,C or EX HL,DE for EX DE,HL.
AndyC
Dr. Peter Kittel
>
>Well, at least that set of instructions is completely consistent,
>self-contained and sane, unlike the rest of the LD & CP groups, and
>streets ahead of Intel's MOVS WORD PTR [SI], WORD PTR ES:[DI] notation.
Yes, the Intel "MOV to, from" is just so illogical, it hurts. The Z80
repaired this by rewording it to "LD" far enough that I could stand it.
>Incidentally, the thing I really liked about
>the 6502 was that all the instructions had TLMs. For some reason I
>enjoyed the consistency...
Fully agreed. I learnt the 6502 shortly after the 8085, and practically
fell in love immediately. This consistency, these neatly equally sized
mnemonics, this (in comparison) orthogonal command set, I like it much
better.
--
Best Regards, Dr. Peter Kittel // E-Mail:
Private Site in Frankfurt, Germany \X/ peterk @ combo.ganesha.com
Don Stokes
Dr. Peter Kittel <peterk @ combo.ganesha.com> wrote:
>Fully agreed. I learnt the 6502 shortly after the 8085, and practically
>fell in love immediately. This consistency, these neatly equally sized
>mnemonics, this (in comparison) orthogonal command set, I like it much
>better.
Orthogonal? 6502? Huh?
The 6502 I grew up with couldn't put an index register on the stack,
could transfer between X or Y and A, but not between X & Y, had one kind
of indexing that could only be done using X and another that could only
be done with Y, and so-on.
Still, it might have been a finicky damn thing, but it ran like a
scalded cat and that's what mattered. 8-)
--
Don Stokes, Networking Consultant http://www.daedalus.co.nz +64 25 739 724
Tim Shoppa
> Fully agreed. I learnt the 6502 shortly after the 8085, and practically
> fell in love immediately. This consistency, these neatly equally sized
> mnemonics, this (in comparison) orthogonal command set, I like it much
> better.
6502? Orthogonal command set? Surely you're joking!
Maybe you mean that wherever there's an "A" in a mnemonic,
you can almost always only use A, wherever there's a "X" in an
mnemonic, you can almost always only use X, and wherever there's
a "Y" in an instruction, you can almost always only use Y.
Maybe you're referring to the 255 registers that MOS Technology
called "zero page" :-) ?
I will agree that the 6502 is a nice microprocessor to program
at the machine code level. And it'd beat the pants off a Z80
clocked several times faster on most anything.
Tim. (sho...@trailing-edge.com)
AutismUK
In article <36593972...@trailing-edge.com>, Tim Shoppa
<sho...@trailing-edge.com> writes:
>6502? Orthogonal command set? Surely you're joking!
The design is much more orthogonal than it looks ; it looks
messy because many opcode tables include the non-std
instructions. In terms of emulating the functionality by
code generation of repeated opcode types almost
everything works except the logically impossible (store
immediate) and things like INX. But the LDA group, the INC
group, the ROL group the branches and the flag instructions
follow a fairly regular pattern.
Compared to an ARM or sim it isn't very orthogonal tho'
Eric J. Korpela
Tim Shoppa <sho...@trailing-edge.com> wrote:
>I will agree that the 6502 is a nice microprocessor to program
>at the machine code level. And it'd beat the pants off a Z80
>clocked several times faster on most anything.
Ahhh, the myth of the "fast" 6502 rears its (ugly) head again. The
reason that this was the case is that the clock speeds were not directly
comparably because the interface between the clock and the chip internals
was different. In a comparison to recent Intel processors (to give the
newbies a reference point), I'd say that the Z80 to a 66 MHz 486 as
the 6502 is to a 66 MHz 486 DX2 processor. Externally, the DX2 is
clocked at 33 MHz, so it looks like it does twices as much per (external)
clock cycle. That does NOT make it a faster or more efficient processor.
The important thing is that when viewed contemporaneously, at the available
clock speeds, the Z80 would outperform the 6502 on most tasks, albeit by
a miniscule margin. When 4 MHz Z80's were the norm, the 6502 was still limited
to 1 MHz. Therefore it didn't matter that the Z80 typically took 3 times as
many clock cycles to execute an instruction.
I've often felt that this berating Z80 performance was precipitated by
Microsoft SoftCards showing up in Apple ][s. The design sucked. Fifty
percent of the memory bandwidth was still given to the 6502, resulting in
a 2 MHz Z80 operating at an effective 1 MHz. Of course Apple ][ owners were
going think the Z80 was slow, because the one they had access to was running
a 1/4 the speed of a typical Z80 system.
Eric
--
Eric Korpela | An object at rest can never be
kor...@ssl.berkeley.edu | stopped.
<a href="http://sag-www.ssl.berkeley.edu/~korpela">Click for home page.</a>
Andrew Cadley
Eric J. Korpela wrote in message <73c6kh$ptv$1...@agate.berkeley.edu>...
:In article <36593972...@trailing-edge.com>,
:Tim Shoppa <sho...@trailing-edge.com> wrote:
:The important thing is that when viewed contemporaneously, at the available
:clock speeds, the Z80 would outperform the 6502 on most tasks, albeit by
:a miniscule margin. When 4 MHz Z80's were the norm, the 6502 was still
limited
:to 1 MHz. Therefore it didn't matter that the Z80 typically took 3 times
as
:many clock cycles to execute an instruction.
Very true. Although there are of course examples where the 6502 can out
perform the Z80, but not as many.
:I've often felt that this berating Z80 performance was precipitated by
:Microsoft SoftCards showing up in Apple ][s. The design sucked. Fifty
:percent of the memory bandwidth was still given to the 6502, resulting in
:a 2 MHz Z80 operating at an effective 1 MHz. Of course Apple ][ owners
were
:going think the Z80 was slow, because the one they had access to was
running
:a 1/4 the speed of a typical Z80 system.
The Commodore 128 was another example of this. In order to operate correctly
with the VIC video chip both the 6502 and Z80 were limited to a 2Mhz clock
rate. Effectively crippling the Z80 while allowing the 6502 to shine.
AndyC
Neil Franklin
>
> Tim Shoppa <sho...@trailing-edge.com> wrote:
> >at the machine code level. And it'd beat the pants off a Z80
> >clocked several times faster on most anything.
>
> Ahhh, the myth of the "fast" 6502 rears its (ugly) head again. The
> reason that this was the case is that the clock speeds were not directly
> comparably because the interface between the clock and the chip internals
Thanks.
> was different. In a comparison to recent Intel processors (to give the
> newbies a reference point), I'd say that the Z80 to a 66 MHz 486 as
> the 6502 is to a 66 MHz 486 DX2 processor. Externally, the DX2 is
> clocked at 33 MHz, so it looks like it does twices as much per (external)
Replace that with DX/4 (or DX/5 as DX/4 is actually an DX/3).
The 8080 and Z80 used 4 clocks per memory cycle. While the 6800, 6809
and 6502 used one clock per memory cycle.
Generally 4MHz *80 were the same speed as 1MHz 6*0*.
The *80 started though at 2.5MHZ and went to 8MHZ. The 6*0* started at
1MHz and went to 4MHz. But 4 and 1 were the widest spread versions.
> The important thing is that when viewed contemporaneously, at the available
> clock speeds, the Z80 would outperform the 6502 on most tasks, albeit by
> a miniscule margin.
As minuscle as zero, IMHO. I used both, never noticed any difference. I
did prefer the 6809 instruction set the most. That 4 byte Forth
interpreter was nifty. Forth ran at 2/3 assembly speed.
> When 4 MHz Z80's were the norm, the 6502 was still limited
> to 1 MHz. Therefore it didn't matter that the Z80 typically took 3 times as
> many clock cycles to execute an instruction.
4 times as many.
> I've often felt that this berating Z80 performance was precipitated by
> Microsoft SoftCards showing up in Apple ][s. The design sucked. Fifty
Is anyone surprised?
--
Neil Franklin, Nerd, Geek, Unix Guru, Hacker, Mystic
ne...@franklin.ch.remove http://neil.franklin.ch/
"No, it was a JOKE! You can't RUN this!" Ken Thompson
Andrew Cadley
Neil Franklin wrote in message ...
:kor...@islay.ssl.berkeley.edu (Eric J. Korpela) writes:
:> The important thing is that when viewed contemporaneously, at the
available
:> clock speeds, the Z80 would outperform the 6502 on most tasks, albeit by
:> a miniscule margin.
:
:As minuscle as zero, IMHO. I used both, never noticed any difference. I
:did prefer the 6809 instruction set the most. That 4 byte Forth
:interpreter was nifty. Forth ran at 2/3 assembly speed.
Consider the following code fragment in Z80 to fill from 1000h to 10FFh with
44h (an example I cheekily swiped from a recent flamewar) :-)
LD HL,1000h
LD DE,1001h
LD BC,255
LD (HL),44h
LDIR
which takes 5390 cycles.
Or in 6502...
LDA #$44 (2 Cycles)
LDX #$00 (2 Cycles)
-loop STA $1000,X (5 Cycles)
DEX (decrement X-register, 2 Cycles)
BNE loop (Branch if not equal Zero, 2 Cycles)
Which is 2306 cycles.
At 4Mhz you'll find the Z80 is nearly twice as fast as the 1Mhz 6502
routine. There is even a Z80 stack based version which is capable of doing
it in LESS CYCLES than the 6502 version. This is a classic example of where
the Z80 is *significantly* faster.
:> When 4 MHz Z80's were the norm, the 6502 was still limited
:> to 1 MHz. Therefore it didn't matter that the Z80 typically took 3
times as
:> many clock cycles to execute an instruction.
:
:4 times as many.
Nope, it's about 3:1. This discussion has come up many, *many* times between
comp.sys.sinclair and comp.sys.cbm, with the overall result that, on
average, the Z80 will be faster.
AndyC
Eric J. Korpela
Neil Franklin <ne...@franklin.ch.remove> wrote:
>
>> When 4 MHz Z80's were the norm, the 6502 was still limited
>> to 1 MHz. Therefore it didn't matter that the Z80 typically took 3 times as
>> many clock cycles to execute an instruction.
>
>4 times as many.
Well, of course, this depends upon the instruction.
For example, (I may have the addressing syntax wrong on the 6502.
And of course many are not exact equivalents.)
6502 Z80
instruction clocks instruction clocks ratio
LDA $NNNN 4 LD A,(NNNN) 13 3.25
In general, the ratio for instructions which access memory is closer
to 3 than to two. For instructions that don't access memory (for example
register increments) the ratio is closer to two. And, of course for
adding two registers together, well, the 6502 can't do that.
Given two 16 bit pointers to 16 bit numbers on the stack add them and
return the result on the stack and the original numbers unchanged. I'll
pretty much guarantee that the Z80 will run in less than 4 times the clock
cycles.
POP HL ; 10
POP BC ; 10
LD A,(BC) ; 7
ADD A,(HL) ; 7
LD E,A ; 4
INC BC ; 6
INC HL ; 6
LD A,(BC) ; 7
ADD A,(HL) ; 7
LD D,A ; 7
PUSH DE ; 11
RET ; 10 Total 89 cycles
I don't remember my 6502 very well. As a handicap, I'll let the operands
be passed in zero page locations $4A,B and $4C,D and the result to be on
the stack in the wrong (IMHO) byte order.
LDY #0 ; 2
CLC ; 2
LDA ($4A),Y ; 5
ADC ($4C),Y ; 5
PHA ; 3
INY ; 2
LDA ($4A),Y ; 5
ADC ($4C),Y ; 5
PHA ; 3
RTS ; 6 Total 38 cycles
If I chose the wrong indirect addressing mode, you can add another 4 cycles
to that.
Both of these are, of course, unoptimized. I'm sure a 6502 programmer
could shave off 25% in cycles, but I'm just as sure that a Z80 programmer
could shave off as many. The ratio in this case is 2.3:1.
Don Stokes
Andrew Cadley <a.p.c...@uea.ac.uk> wrote:
>Consider the following code fragment in Z80 to fill from 1000h to 10FFh with
>44h (an example I cheekily swiped from a recent flamewar) :-)
>
>LD HL,1000h
>LD DE,1001h
>LD BC,255
>LD (HL),44h
>LDIR
You're cheating.
Much of the reason the 6502 is fast is because it has a primitive
pipeline, which the Z80 lacks, thus the overhead of executing each
instruction is much lower, hence less clock cycles to acomplish a given
number of instructions. The above executes eleven opcode/operand
fetches and five instruction decodes, whereas your 6502 example executes
1,540 opcode/operand fetches and 770 instruction decodes.
Apples to apples comparison? I don't *think* so.
Not every operation is amenable to LDIR. Strange but true.
(Admittedly, LDIR & friends were a pretty major improvement on the 8080,
except that to maintain 8080 combatibility, hardly any CP/M code used it...)
>At 4Mhz you'll find the Z80 is nearly twice as fast as the 1Mhz 6502
My cheap off-the-shelf 6502 based box ran at 2MHz. Contemporary Z80
based boxen couldn't catch it. Even 1MHz 6502s still *felt* faster than
anything I ever used with a Z80 in it.
Kevin Connolly
>
> In article <m367c6x...@chonsp.franklin.ch>,
> Neil Franklin <ne...@franklin.ch.remove> wrote:
> >
> >> When 4 MHz Z80's were the norm, the 6502 was still limited
> >> to 1 MHz. Therefore it didn't matter that the Z80 typically took 3 times as
> >> many clock cycles to execute an instruction.
> >
> >4 times as many.
>
I seem to recall the SY6502A being available at the same time as
the 4MHz Z80 and IIRC it ran at 2.5MHz
The H/W designs were cleaner too and I often had two processors
sharing the same RAM on the same address and data buses, one using
the bus when PhiClock was high and one when it was low.
--
Remove the NOSPAM from the reply address
Kevin Connolly, EI4ANB
ROT13: xriva.p...@nafs.nypngry.se
ICBM: 51 40.2'N 08 29.7'W
Andrew Cadley
Don Stokes wrote in message <73e4j9$ssh$1...@news.wlg.netlink.net.nz>...
:In article <73d0i7$c...@cpca3.uea.ac.uk>,
:Andrew Cadley <a.p.c...@uea.ac.uk> wrote:
:>Consider the following code fragment in Z80 to fill from 1000h to 10FFh
with
:>44h (an example I cheekily swiped from a recent flamewar) :-)
:>LDIR
: ^^^^
:
:You're cheating.
Not really. You can do it *much* faster on the Z80 with the following code:
LD SP,1100h 10 cycles
LD HL,0 10
LD B,128 7
loop PUSH HL 11
DJNZ loop 13/8
Which is only 3094 cycles and isn't using the LDIR instruction. Even a 2Mhz
6502 can't outperform that. Unrolling the loop even a little bit, as I said
before, can actually take it down to less cycles than the equivalent 6502.
In case you were wondering, the original problem was suggested by a 6502
advocate...
:Much of the reason the 6502 is fast is because it has a primitive
:pipeline, which the Z80 lacks, thus the overhead of executing each
:instruction is much lower, hence less clock cycles to acomplish a given
:number of instructions. The above executes eleven opcode/operand
:fetches and five instruction decodes, whereas your 6502 example executes
:1,540 opcode/operand fetches and 770 instruction decodes.
Wrong, wrong, absolutely brimming over with wrongability. The Z80 LDIR
version executes no less than 521 operand/opcode fetches and 514 instruction
decodes. The stack based version is 392 operand/opcode fetches and 259
instruction decodes.
The thing is, it can be difficult to find like for like examples because the
Z80s larger register and instruction set generally require less instructions
for similar operations.
:Not every operation is amenable to LDIR. Strange but true.
True, but LDIR is not the most effcient instruction in the Z80 by a long
shot.
:>At 4Mhz you'll find the Z80 is nearly twice as fast as the 1Mhz 6502
:
:My cheap off-the-shelf 6502 based box ran at 2MHz. Contemporary Z80
:based boxen couldn't catch it. Even 1MHz 6502s still *felt* faster than
:anything I ever used with a Z80 in it.
6502 may have *felt* faster, but Z80 *was* faster.
AndyC
John Savard
>>>>Let's see, the 360 has things like MVC, MVN, and MVZ, which again
>>>>are easier to just spell out. But it also has ZAP, which is kind
>>>>of fun. Then there are the inbetween ones like BXLE. Most people
>>>>pronounce that one "bixel", but I once heard someone pronounce it
>>>>"boxel" and I liked it so much I adopted it. No such luck with its
>>>>sister instruction BXH, though...
Ah, yes.
MVC: Move Character - for copying a string of bytes from one location
to another.
MVN, MVZ: Move Numeric, Move Zone: for overlaying the high or low
nibbles of a series of bytes, useful in converting from packed decimal
to character form.
ZAP: Zero and Add Packed: the equivalent of a load instruction for
packed decimal.
BXLE, BXH: Branch on Index Low or Equal, Branch on Index High: these
instructions were used at the end of DO-loops.
Despite their names, therefore, these were all fairly sensible
computer instructions, doing perfectly prosaic things.
The 360 used A for Add, and AH for Add Halfword (16-bit add), and so
the Zilog Z-80 mnemonics were somewhat inspired by the 360, while the
original 8080 mnemonics were more along the lines of the mnemonics
used in the 7090 (and the PDP-8, and the Honeywell 316, and virtually
all the pre-360 architectures).
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
Marat Fayzullin
: 6502 may have *felt* faster, but Z80 *was* faster.
Who says "was"? Low-end TI graphing calculators, TI Avigo, Franklin
electronic dictionaries, Nintendo GameBoy, SEGA GameGear all use Z80 or
its close derivatives. This is only to name a few. Lately, the focus
seems to shift toward 68000 though (TI92, PalmPilot).
Andrew Cadley
Tim Shoppa wrote in message <365A97C3...@trailing-edge.com>...
:Andrew Cadley wrote:
:> Or in 6502...
:>
:> LDA #$44 (2 Cycles)
:> LDX #$00 (2 Cycles)
:> -loop STA $1000,X (5 Cycles)
:> DEX (decrement X-register, 2 Cycles)
:> BNE loop (Branch if not equal Zero, 2 Cycles)
:> Which is 2306 cycles
:
:Actually, the BNE takes 3 Cycles when the branch is taken to
:the same page; 4 if the branch is taken to an adjacent page.
:So there's really at least 255 more cycles, coming out at 2563
:(you seem to have left two out of your original calculation).
Tch. I should have known not to trust the timings given my a Commode owner.
:-) The crap maths though, is entirely my fault...
:Or, with a slight loop unrolling:
:
: LDA #$44 (2 Cycles)
: LDX #$40 (2 Cycles)
:-loop STA $1000-1,X (5 Cycles)
: STA $1040-1,X (5 Cycles)
: STA $1080-1,X (5 Cycles)
: STA $10C0-1,X (5 Cycles)
: DEX (2 Cycles)
: BNE loop (3 Cycles except on last)
:
:Which is 1603 cycles - less than one-fourth the number on the Z80.
:
:> There is even a Z80 stack based version which is capable of doing
:> it in LESS CYCLES than the 6502 version.
:
:That sounds interesting - I'd like to see that.
I gave the basic form elsewhere, but more specifically:
LD SP,1100h (10 cycles)
LD HL,0 (10 cycles)
LD B,16 (7 cycles)
loop PUSH HL (11 cycles)
PUSH HL (11 cycles)
PUSH HL (11 cycles)
PUSH HL (11 cycles)
PUSH HL (11 cycles)
PUSH HL (11 cycles)
PUSH HL (11 cycles)
PUSH HL (11 cycles)
DJNZ loop (13/8 cycles)
Which is a total of 1638 cycles, significantly less than the 2563 mentioned
above. Naturally you can continue to unroll this and get less than the 1603
cycles you mention above. Although, even when comparing a 2Mhz 6502 to a
4Mhz Z80, it is a *lot* faster as it is.
And it takes one less byte than the unrolled 6502. :-)
AndyC
barnacle
>I seem to recall the SY6502A being available at the same time as
>the 4MHz Z80 and IIRC it ran at 2.5MHz
>
>The H/W designs were cleaner too and I often had two processors
>sharing the same RAM on the same address and data buses, one using
>the bus when PhiClock was high and one when it was low.
>
>
active clock phase to address the video - even run code *in* the video memory
without twinklies. It was also a dream if you had to genlock your output to
input video (graphics displays, counters etc) - you could just use a VCO to a
suitable multiple of line frequency.
barnacle
p.s. when i (later) had a z80 based cpm machine, i only ever had an 8085
assembler so i never used *any* of the z80 clever-bugger ops...forth didn't
half fly though!
barnacle
nailed-barnacle.home.ml.org
Neil Franklin
>
> 44h (an example I cheekily swiped from a recent flamewar) :-)
>
> LDIR
According to this list here (Rodney Zaks) the LDIR will use 256 times
21 cycles. Seems to be right.
> Or in 6502...
>
> -loop STA $1000,X (5 Cycles)
> DEX (decrement X-register, 2 Cycles)
> BNE loop (Branch if not equal Zero, 2 Cycles)
> Which is 2306 cycles.
Here I dispute the cycle numbers.
IIRC (from reading a borrowed MOS Technology manual over 10 years ago)
STA $aabb,X has 4/5 cycles depending on bb+X carrying over*. In this
example 00+X you actually never have an carry. So ca 2050 cycles.
* it actually outputs the 256 too low address, forces R/W pin to R and
then throws away the input! The 6502 is an true 8bit processor, no
16bit address calculations.
The DEX I am not sure of. Could also be 1 cycle (fetch next
instruction while doing the DEXing). So ev 1800 cycles.
BNE is 2/3 depending on where in memory the code is (again carry over).
> At 4Mhz you'll find the Z80 is nearly twice as fast as the 1Mhz 6502
So we may already be down to 1.5.
And then there is the question of the LDI/D*. It only works if it is
applicable. Special purpose hardware usually beats software if it can
be used.
> routine. There is even a Z80 stack based version which is capable of doing
> it in LESS CYCLES than the 6502 version.
No re-reading the data (as the LDIR does) and 2 bytes per PUSH. Very
neat hack, but also a very special case, not representative.
Also requires you to DI/EI to missuse SP. The OS may not allow this.
> This is a classic example of where
> the Z80 is *significantly* faster.
Classic (= representative) example? More a special case.
Loops and indirect addressing are generally the weak points on the
6502. Try some code that does lots of direct accesses to random
variables in RAM. Thats difficult to write short benchmarks for, but
that is where the 6502 runs good.
Take an realistic (from user standpoint) job such as Basic interpreter
doing an print "Hello, world". For that the Z80-4 = 6502-1 was a good
approximation.
But perhaps all the Z80s around here were slow ones (they often used
an extra wait state because 250ns was too little for DRAM, while the
500ns on the 6502 never required that).
> Nope, it's about 3:1. This discussion has come up many, *many* times between
> comp.sys.sinclair and comp.sys.cbm, with the overall result that, on
> average, the Z80 will be faster.
CBMs (at least the wide spread C64) had an 40% cycle loss (= they were
running at effective 0.6MHz) due to the video chips wanting to get at
80bytes of video data for each screen line. Sinclairs did not.
Eric J. Korpela
Neil Franklin <ne...@franklin.ch.remove> wrote:
>> Nope, it's about 3:1. This discussion has come up many, *many* times between
>> comp.sys.sinclair and comp.sys.cbm, with the overall result that, on
>> average, the Z80 will be faster.
>
>CBMs (at least the wide spread C64) had an 40% cycle loss (= they were
>running at effective 0.6MHz) due to the video chips wanting to get at
>80bytes of video data for each screen line. Sinclairs did not.
As much as I'm sure that the Z80 @ 4MHz is faster than the 6502 @ 1MHz,
I don't think anyone should be pointing to the Sinclair as a speed demon.
The sinclair lost far more than 40% of its cycles to video. The only
advantage was that its video could be shut off to increase processing speed.
Eric J. Korpela
Kevin Connolly <Kevin.C...@ansf.alcatel.NOSPAM.fr> wrote:
>Eric J. Korpela wrote:
>I seem to recall the SY6502A being available at the same time as
>the 4MHz Z80 and IIRC it ran at 2.5MHz
The SY6402A may have been available at a time when 4MHz Z80s were
still available, but I'd be really really suprised if the 4 MHz Z80
wasn't avaiable at least 1 year earlier. I'd also like you to point me
to a system available before 1982 that used a 6502 at anything faster
than 1.3 MHz.
>The H/W designs were cleaner too and I often had two processors
>sharing the same RAM on the same address and data buses, one using
>the bus when PhiClock was high and one when it was low.
Cleaner until you wanted to use DRAMs.
Eric Smith
> used a 6502 at anything faster than 1.3 MHz.
Easy.
The Apple ///. (Whether anyone *WANTED* an Apple /// is another story.)
Some of the bigger Ohio Scientific machines (not the C1P) supported 6502s
at 2 MHz, and I recently noticed that one of their ads on the back cover of a
1979 Byte offered a 4 MHz 6502C as an option on the C3.
In 1978 I built a small homebrew system using a 4 MHz 6502C. This required
RAMs with an access time under 100 ns. The only fast enough RAM chips at the
time were expensive bipolar 1K*1 SRAMs in ceramic DIPs, and it was necessary
to attach heat sinks to them in addition to using forced air cooling. By 1980
there were fast enough CMOS 2K*8 SRAMs (Hitachi HM6116P-100), so I was finally
able to expand my system to 60K.
The 4 MHz 6502C blew the doors off any Z-80 available at the time (and until
some years later, when Zilog finally introduced CMOS Z-80 CPUs that broke the
8 MHz barrier).
Note that the C in 6502C denoted the 4 MHz rating, vs. A=2 MHz, B=3 MHz,
none=1 Mhz. This is distinct from the 65C02, in which the C denotes
CMOS. And it is also different than the Atari 6502C, which was NOT
rated at 4 MHz, but was in fact a customized 6502 with a small amount
of glue logic added.
Eric
Dr. Peter Kittel
>In article <peter...@combo.ganesha.com>,
>>
>>Fully agreed. I learnt the 6502 shortly after the 8085, and practically
>>fell in love immediately. This consistency, these neatly equally sized
>>mnemonics, this (in comparison) orthogonal command set, I like it much
>>better.
>
Read closer: "in comparison", to the 8080/8085, of course. And I still
claim this.
>The 6502 I grew up with couldn't put an index register on the stack,
>could transfer between X or Y and A, but not between X & Y, had one kind
>of indexing that could only be done using X and another that could only
>be done with Y, and so-on.
But the LDA, STA, and some more commands were available in nearly all
addressing modes, something completely unknown to the 8080, *and* its
x86 successors...
Dr. Peter Kittel
>In article <36593972...@trailing-edge.com>,
>Tim Shoppa <sho...@trailing-edge.com> wrote:
>>
>>clocked several times faster on most anything.
>
>Ahhh, the myth of the "fast" 6502 rears its (ugly) head again.
Huh? But it *is* fast. If you cautiously design the software (like it
was done in the CBM 8032 and the C64), you can exploit the extremely
fast access to Zero Page addresses (only 2 clock cycles) for all your
time critical SW parts. This really makes it fly.
>The important thing is that when viewed contemporaneously, at the available
>clock speeds, the Z80 would outperform the 6502 on most tasks, albeit by
>a miniscule margin. When 4 MHz Z80's were the norm, the 6502 was still limited
>to 1 MHz. Therefore it didn't matter that the Z80 typically took 3 times as
>many clock cycles to execute an instruction.
Well, our results (with an accent on floating point number crunching)
gave us a ration of 2.5, i.e. a 2.5 MHz Z80 has approximately the same
performance as a 1 MHz 6502. And there were 6502 with 2 MHz clock in
wide use, e.g. in the C128. And a 4 MHz "Turbo Board" for the C64 was
also sold.
>I've often felt that this berating Z80 performance was precipitated by
>Microsoft SoftCards showing up in Apple ][s.
No Apples here far and wide, my colleague had a Tandy Model II.
Neil Franklin
>
> Not really. You can do it *much* faster on the Z80 with the following code:
>
> DJNZ loop 13/8
That certainly is neat. Just hope the stack is not needed for interrupts.
> Which is only 3094 cycles and isn't using the LDIR instruction. Even a 2Mhz
> 6502 can't outperform that.
But that is really special case. Not average code, which is what the
user waiting in front of the machine sees.
> Unrolling the loop even a little bit, as I said
> before, can actually take it down to less cycles than the equivalent 6502.
Hmm, I doubt that. You can reduce the DJNZes with unrolling. But the
6502 can reduce the DEXes* and BNEs with unrolling.
* Use the STAs with different base adresses:
lda #$44
ldx #$80
loop dex
sta $1000,X ; doesn't change flags from dex
sta $1080,X
bne loop
> The thing is, it can be difficult to find like for like examples because the
> Z80s larger register and instruction set generally require less instructions
> for similar operations.
And that os why examples that use many random memory accesses foul
up the Z80 by killing its register advantage. Initialisation loops are
fast, but actual programs spend time doing other things.
> :>At 4Mhz you'll find the Z80 is nearly twice as fast as the 1Mhz 6502
> :My cheap off-the-shelf 6502 based box ran at 2MHz. Contemporary Z80
> :based boxen couldn't catch it. Even 1MHz 6502s still *felt* faster than
> :anything I ever used with a Z80 in it.
>
> 6502 may have *felt* faster, but Z80 *was* faster.
In loop benchmarks, not on user code. At least none I ever saw.
Of course my 1.9MHz 6809 ran rings around both of them :-).
Andrew Cadley
Eric J. Korpela wrote in message <73fggl$9b4$1...@agate.berkeley.edu>...
:In article <m3r9usd...@chonsp.franklin.ch>,
:Neil Franklin <ne...@franklin.ch.remove> wrote:
:>> Nope, it's about 3:1. This discussion has come up many, *many* times
between
:>> comp.sys.sinclair and comp.sys.cbm, with the overall result that, on
:>> average, the Z80 will be faster.
:>
:>CBMs (at least the wide spread C64) had an 40% cycle loss (= they were
:>running at effective 0.6MHz) due to the video chips wanting to get at
:>80bytes of video data for each screen line. Sinclairs did not.
Actually it was only slowed to about 0.98Mhz, although the video display had
"bad" lines which added a additional slowdown every 8 lines. The spectrum
also suffers from memory contention under certain circumstances, but it can
be avoided if you aren't altering the screen. Although it was only clocked
at 3.54 MHz.
:As much as I'm sure that the Z80 @ 4MHz is faster than the 6502 @ 1MHz,
:I don't think anyone should be pointing to the Sinclair as a speed demon.
:The sinclair lost far more than 40% of its cycles to video. The only
:advantage was that its video could be shut off to increase processing
speed.
You're thinking of the ZX81. It wasn't actually losing cycles as such, the
video display was produced in software by the Z80. The spectrum is a
different matter, the video was produced by the ULA and the processor was
always running in the equivalent of the ZX81's FAST mode.
AndyC
Andrew Cadley
Neil Franklin wrote in message ...
:>
:> Not really. You can do it *much* faster on the Z80 with the following
code:
:>
:> loop PUSH HL 11
:> DJNZ loop 13/8
:
:That certainly is neat. Just hope the stack is not needed for interrupts.
That's what DI is for. :-)
:> Which is only 3094 cycles and isn't using the LDIR instruction. Even a
2Mhz
:> 6502 can't outperform that.
:
:But that is really special case. Not average code, which is what the
:user waiting in front of the machine sees.
That is admittedly a somewhat specialised case. Normally you'd be looking at
requiring about 3 times as many cycles as the 6502. To give a third example
of the above routine:
ld hl,$1100 10
ld b,0 7
ld a,b 4
loop ld (hl),a 7
inc l 4
djnz loop 13/8
Which is 6165 cycles. *Still* faster than in Z80@4Mhz than a 6502@1Mhz
although you would never code Z80 like that unless you were thick as Devon
custard. :-)
:> Unrolling the loop even a little bit, as I said
:> before, can actually take it down to less cycles than the equivalent
6502.
:
:Hmm, I doubt that. You can reduce the DJNZes with unrolling. But the
:6502 can reduce the DEXes* and BNEs with unrolling.
See another post for the actual timing.
:* Use the STAs with different base adresses:
:
: lda #$44
: ldx #$80
:loop dex
: sta $1000,X ; doesn't change flags from dex
: sta $1080,X
: bne loop
The thing is though, each additional STA adds three bytes to the length of
the code. Each additional PUSH adds only one, so it is more feasible to
unroll the Z80 further.
:> The thing is, it can be difficult to find like for like examples because
the
:> Z80s larger register and instruction set generally require less
instructions
:> for similar operations.
:
:And that os why examples that use many random memory accesses foul
:up the Z80 by killing its register advantage. Initialisation loops are
:fast, but actual programs spend time doing other things.
It isn't actually as fast as you might think. There are table based
algorithms that execute faster in 6502 (fast multiply is one example) but a
well coded Z80 routine often comes in very close if not faster.
:> 6502 may have *felt* faster, but Z80 *was* faster.
:
:In loop benchmarks, not on user code. At least none I ever saw.
In the majority of cases. Perhaps you haven't looked hard enough?
AndyC
Andrew Cadley
:> Or in 6502...
:>
:> -loop STA $1000,X (5 Cycles)
:> DEX (decrement X-register, 2 Cycles)
:> BNE loop (Branch if not equal Zero, 2 Cycles)
:> Which is 2306 cycles.
:
:Here I dispute the cycle numbers.
Well they were given to me by a C64er, who of course I trust implicitly. The
variation may be down to the fact a C64 uses a 6510, I think. Or he may have
just been wrong.
:> At 4Mhz you'll find the Z80 is nearly twice as fast as the 1Mhz 6502
:
:So we may already be down to 1.5.
But given that was an "all the time in the world" type Z80 routine, it's
hardly surprising hat optimised 6502 is going to be closer in speed terms.
:And then there is the question of the LDI/D*. It only works if it is
:applicable. Special purpose hardware usually beats software if it can
:be used.
It can still be written idiot-fashon, without LDIR or PUSH, and go faster
than the 6502. Not that real Z80 ever looks anything like that.
:Also requires you to DI/EI to missuse SP. The OS may not allow this.
OS? Pah! Sod that and write directly to the hardware. :-) Not that any OS
could *stop* you doing a DI...
:> This is a classic example of where
:> the Z80 is *significantly* faster.
:
:Classic (= representative) example? More a special case.
Classic in the same sense that a fast multiply is used to try and
demonstrate that 6502 is faster. However the difference in that case is
*much* smaller.
:Loops and indirect addressing are generally the weak points on the
:6502. Try some code that does lots of direct accesses to random
:variables in RAM. Thats difficult to write short benchmarks for, but
:that is where the 6502 runs good.
Branching and jumping are generally slower in Z80, as is memory indexing.
Algorithms that work almost exclusively with large-ish tables tend to do
better on 6502. Z80 code tends to rely more on page alignments to allow HL
to be used as an pseudo-index register and will do better with algorithms
that fit into the registers and don't need to branch too much.
:Take an realistic (from user standpoint) job such as Basic interpreter
:doing an print "Hello, world". For that the Z80-4 = 6502-1 was a good
:approximation.
Hmmm. That's entirely dependent on the type of display you have though. A
character based version will obviously lend itself to yet another LDIR. A
bitmapped one can get tricky, but not nessecarily slower in Z80. Perhaps you
could supply some 6502 examples?
AndyC
David Given
>>The 6502 I grew up with couldn't put an index register on the stack,
>>could transfer between X or Y and A, but not between X & Y, had one kind
>>of indexing that could only be done using X and another that could only
>>be done with Y, and so-on.
Don't you remember...
PHA
TXA
PHA
TYA
PHA
...
PLA
TAY
PLA
TAX
PLA
for interrupts?
The 65C102, the next generation, had a slightly better rounded instruction
set.
PHA
PHX
PHY
...
PLY
PLX
PLA
It also had STZ, which stored zero to a memory location. Handy.
--
+- David Given ----------------+ This is a test. This is only a test.
| Work: d...@tao.co.uk | Had this been a real emergency, you
| Play: dgi...@iname.com | would all be dead by now.
+- http://wiredsoc.ml.org/~dg -+
Andrew Cadley
Dr. Peter Kittel wrote in message ...
:In article <73c6kh$ptv$1...@agate.berkeley.edu> kor...@islay.ssl.berkeley.edu
(Eric J. Korpela) writes:
:>In article <36593972...@trailing-edge.com>,
:>Tim Shoppa <sho...@trailing-edge.com> wrote:
:>Ahhh, the myth of the "fast" 6502 rears its (ugly) head again.
:
:Huh? But it *is* fast. If you cautiously design the software (like it
:was done in the CBM 8032 and the C64), you can exploit the extremely
:fast access to Zero Page addresses (only 2 clock cycles) for all your
:time critical SW parts. This really makes it fly.
And your point is? If your clever about the way you write Z80 routines then
they can also fly. They just usually fly faster. :-)
Zero page isn't that much of an advantage in real terms. If we set H to be
the base address, we can index any value in a 256 byte, page aligned, table
using L as the index. Since LD (HL),A requires just 7 cycles the Z80 is
ahead with a 4:1 clock ratio. And of course we can access more than one
table.
:Well, our results (with an accent on floating point number crunching)
:gave us a ration of 2.5, i.e. a 2.5 MHz Z80 has approximately the same
:performance as a 1 MHz 6502. And there were 6502 with 2 MHz clock in
:wide use, e.g. in the C128. And a 4 MHz "Turbo Board" for the C64 was
:also sold.
I think you'll find more generic results lean towards a 3:1 time ratio. In
either case the Z80 was faster. 2Mhz 6502s came along later (the C128 was
1985) which should be faster, but faster Z80s like the 6MHz Z80B were also
widely available.
Surely the real testement to the Z80 is that it is still commonly used in
embeded controllers.
AndyC
Michael Black
was what was inside the C1P, and the II only added slightly wider screen
length) was rated for 1MHz. I jacked it up to 2MHz by moving the clock
pin to the input of the divider stage that normally fed it. I could
notice the speedup right away. I don't think the 6502 was anything
special. I never had any problems with running it at that speed; I put a
switch in to allow a return to 1MHz, but I never used it.
I did it in 1981 or '82, but the Superboard came out a few years earlier,
and others had doubled the speed before me.
Michael
On 24 Nov 1998, Eric Smith wrote:
> kor...@islay.ssl.berkeley.edu (Eric J. Korpela) writes:
lis...@zetnet.co.uk
On 1998-11-24 a.p.c...@uea.ac.uk said:
:Consider the following code fragment in Z80 to fill from 1000h to
:10FFh with 44h (an example I cheekily swiped from a recent
:flamewar) :-)
[conservative programming examples snipped]
:At 4Mhz you'll find the Z80 is nearly twice as fast as the 1Mhz 6502
:routine. There is even a Z80 stack based version which is capable
:of doing it in LESS CYCLES than the 6502 version. This is a classic
:example of where the Z80 is *significantly* faster.
But that version will die if the Z80 gets an interrupt halfway through
the loop. Turning them off won't help with the NMIs.
:Nope, it's about 3:1. This discussion has come up many, *many*
:times between comp.sys.sinclair and comp.sys.cbm, with the overall
:result that, on average, the Z80 will be faster.
Actually, it depends on a hell of a lot more factors than simple CPU
speed. For example, the 6502 could usually arrange itself so that it
never encountered a wait state on memory (you were guaranteed that the
bus was free for half of every clock cycle; a fair few video generators
used this, including the BBC's). The Z80 had a far less predictable
memory cycle, which meant that video would probably trip up the CPU and
take the effective speed down 20%. (The Spectrum was even worse here,
since the video circuitry was used to refresh all the RAM, eating about
50% of memory bandwidth.) There's also the issue of how amenable the
instruction set is to real speed-intensive hacking, and I believe that
the 6502 was felt to be a little friendlier in that respect. And then
there's the "it just feels..." factor, and I think that's where the
consensus arose. Also, there's the issue of what the chips were designed
for; the 6502 for washing machines, and the Z80 for shifting lots of
data around in a way wordprocessors would appreciate.
And how often do you need to fill an area of memory without more
complicated range tests anyway..?
--
Communa (lis...@zetnet.co.uk) -- you know soft spoken changes nothing
lis...@zetnet.co.uk
On 1998-11-23 ne...@franklin.ch.remove said:
:As minuscle as zero, IMHO. I used both, never noticed any
:difference. I did prefer the 6809 instruction set the most. That 4
:byte Forth interpreter was nifty. Forth ran at 2/3 assembly speed.
Now you're talking. :> I didn't realise it was as little as 4 bytes;
even the x86s (hell, even 68000s!) are more than that.
I wonder if a 6809 emulator would run at full speed on a 486/33..? ;>
(Oh, that's a point, there's a Dragon emulator I should really look at
first.)
--
Communa (lis...@zetnet.co.uk) -- you know soft spoken changes nothing
Net-Tamer V 1.08X - Test Drive
William Hamblen
<a.p.c...@uea.ac.uk> wrote:
>At 4Mhz you'll find the Z80 is nearly twice as fast as the 1Mhz 6502
>routine. There is even a Z80 stack based version which is capable of doing
>it in LESS CYCLES than the 6502 version. This is a classic example of where
>the Z80 is *significantly* faster.
4 MHz was the "fast" Z80A. The "normal" Z80 ticked over at 2.5 MHz.
An instruction fetch took 4 clocks and other memory references took 3.
So a 2.5 MHz Z80 was roughly equivalent to a 1 MHz 6800 or 6502.
A Z80A would be like a 68B00 (2 MHz clock). I don't recall the part
number for a 2 Mhz 6502.
The big advantage of the MOS Technology 6502 back in 1975 was that it
was a lot cheaper than the parts produced by the other manufacturers.
That was important for garage inventors.
Neil Franklin
>
> Andrew Cadley (a.p.c...@uea.ac.uk) wrote:
> : Z80 *was* faster.
> Who says "was"? Low-end TI graphing calculators, TI Avigo, Franklin
> electronic dictionaries, Nintendo GameBoy, SEGA GameGear all use Z80 or
And don't forget the Adaptec 1542-CF SCSI controller that was once
popular in the PC server world. It has an 10 MHz Z-80 on it. The
1542-B had an 8085-8.
That would make some damn fast CP/M systems.
The Z-80 is most likely the cheapest full CPU, ca $1 for single
parts retail. As part of an ASIC in 1000er batches most likely 10c.
Neil Franklin
> >
> >CBMs (at least the wide spread C64) had an 40% cycle loss (= they were
> >running at effective 0.6MHz) due to the video chips wanting to get at
> >80bytes of video data for each screen line. Sinclairs did not.
> I don't think anyone should be pointing to the Sinclair as a speed demon.
> The sinclair lost far more than 40% of its cycles to video. The only
Aha. So they also did that.
> advantage was that its video could be shut off to increase processing speed.
No advantage. The C64 also had an video-off control bit (0xd011, bit 4).
Various fast tape and fast* disk programs used it to allow faster
sending of bits over the software implemented serial ports.
* relatively, that is. C64 disks were never anywhere near real fast.
David Given
Goran Larsson <h...@approve.se.NO_JUNK_EMAIL> wrote:
[...]
>One way the 6502 really sucks is the page 0 stuff and the fixed
>location for the stack. It is fast and convenient for small programs,
>but a total disaster for multitasking.
True.
The way out, of course, is to shadow the relevant bits of memory so
different process' zero-page and stack live in different address spaces.
This does require extra hardware, of course.
--
+- David Given ----------------+
| Work: d...@tao.co.uk | Truth is stranger than fiction, because
| Play: dgi...@iname.com | fiction has to make sense.
+- http://wiredsoc.ml.org/~dg -+
Don Stokes
David Given <dg@> wrote:
[65C02]
>It also had STZ, which stored zero to a memory location. Handy.
So did the vanilla 6502, but it wasn't documented. I can't remember if
it was the same opcode.
The 65C02 also had BRA, which got rid of the CLC BCC or equivalent
sequences for writing position independent code.
--
Don Stokes, Networking Consultant http://www.daedalus.co.nz +64 25 739 724
David Given
Don Stokes <d...@news.daedalus.co.nz> wrote:
>In article <911998648.19989.0...@news.demon.co.uk>,
>David Given <dg@> wrote:
>[65C02]
>>It also had STZ, which stored zero to a memory location. Handy.
>
>So did the vanilla 6502, but it wasn't documented. I can't remember if
>it was the same opcode.
>
>The 65C02 also had BRA, which got rid of the CLC BCC or equivalent
>sequences for writing position independent code.
Unfortunately it only took a single byte operand, so you could only jump
+-128 bytes. That made it not very useful.
Hmm...
JSR next
next: PLA
CLC
ADC #offsetlo
TAX
PLA
ADC #offsethi
PHA
TXA
PHA
RTS
Eeek!
--
+- David Given ----------------+
| Work: d...@tao.co.uk | In capitalism, man exploits man. With
| Play: dgi...@iname.com | communism, it's exactly the opposite.
+- http://wiredsoc.ml.org/~dg -+
Don Stokes
David Given <dg@> wrote:
>>The 65C02 also had BRA, which got rid of the CLC BCC or equivalent
>>sequences for writing position independent code.
>
>Unfortunately it only took a single byte operand, so you could only jump
>+-128 bytes. That made it not very useful.
CLC
BCC hop
... ; < 128 bytes
hop: BCC target
... ; < 128 bytes
target: ...
What's bothersome is that I use the same trick in the VAX because althoug
the VAX has a lovely programmer friendly (and CPU designer hostile) three
operand architecture with lots of niceties, some halfwit spoiled it by
having only byte-relative conditional branches. Admittedly the intermediate
branches can be BRW instructions, so you don't need several hops for long
branches. Heck, at least the pdp11 had *word* relative branches, giving a
+-255 byte range, and VAX instructions are on averagge bigger.
Charles Richmond
>
> [snip...] [snip...] [snip...]
>
> As minuscle as zero, IMHO. I used both, never noticed any difference. I
> did prefer the 6809 instruction set the most. That 4 byte Forth
> interpreter was nifty. Forth ran at 2/3 assembly speed.
>
in the 8-bit era that it was essentially stillborn. What made it so good for
FORTH was that it has *two* hardware supported stacks. And also it has a JMP
instruction format that will branch to the address pointed to by the operand.
(indirection, yeh).
The 6809 *is* fairly orthogonal. Data can be moved between any two like sized
registers (with one exception), and any two like sized registers can have
their contents *exchanged* with one assembly instruction. These used a
bit-mask for the registers to be exchanged, and the PSH/PUL instruction used a
bit-mask to identify registers to operate on. So *one* instruction could push
the entire register file.
The exception to the data transfer (but *not* to data exchange) is the direct
page register. The direct page register contains the upper byte of the
address of the direct page (which is limited to the first 256 locations on the
6800 and 6502). So changing this register lets you use direct page
instructions for *anywhere* in memory.
There was a three part article in BYTE magazine about the design of the 6809
(I think in the summer of 1980 or 1981). There was an attempt to take
statistical measures of the instruction frequency used in 6800 programs, and
to make the most used instructions execute fastest on the 6809.
--
+-------------------------------------------------------------+
| Charles and Francis Richmond <rich...@plano.net> |
+-------------------------------------------------------------+
Neil Franklin
>
> :Neil Franklin <ne...@franklin.ch.remove> wrote:
> :>
> :>CBMs (at least the wide spread C64) had an 40% cycle loss (= they were
> :>running at effective 0.6MHz) due to the video chips wanting to get at
> :>80bytes of video data for each screen line. Sinclairs did not.
>
[go digging for 64 internals book, page325ff
C64 circuit diagram reprint, (C) 1983 CBM
Yup, in those days we still got diagrams]
All numbers are NTSC|PAL.
Quarz 14.31818|17.724472 divided 1:18|1:14 (74LS193+flipflop) goes to
PLL (MC4044). Other input is from an PLL controlled VCO divided 1:8
(6567|6565, the VIC chip). VCO is used for pixel clock, which is 8
times CPU clock (1.0227|0.985248).
After this you then get the problem that the VIC wants for every 8
pixels 1 byte character number and 1 byte pixel pattern = 80 bytes
from DRAM (plus 40 nibbles color number over separate bus from an 2114).
So to do this the VIC has to use both halfs of the CPU clock, so it
stops the 6510 dead for 40 clocks per line. That is 200*40 = 8000
clocks per frame, 8000 * 60|50 = 480000|400000 clocks per second.
That gives 1.0227|0.985248 - 0.48|0.40 = 0.54|0.58 MHz effective clock.
Sprites costed an additional 21*4 clocks per frame and per sprite.
Then there is the normal DRAM refresh, also done by the VIC.
> although the video display had
> "bad" lines which added a additional slowdown every 8 lines.
What process would this be?
Dr. Peter Kittel
>
>My Ohio Scientific Superboard II (if I remember properly, the Superboard
>was what was inside the C1P, and the II only added slightly wider screen
>length) was rated for 1MHz. I jacked it up to 2MHz by moving the clock
>pin to the input of the divider stage that normally fed it.
Yes, OSI Superboard II was a nice toy. A colleague had one and he also
upped the clock to 2 MHz. He also tried 2.5 MHz, but then it began to
act unreliably.
> I could
>notice the speedup right away.
Yes, it was really fast, a nice device.
Neil Franklin
>
> On 1998-11-23 ne...@franklin.ch.remove said:
> :As minuscle as zero, IMHO. I used both, never noticed any
> :difference. I did prefer the 6809 instruction set the most. That 4
> :byte Forth interpreter was nifty. Forth ran at 2/3 assembly speed.
>
The following is from memory, read it 15 years ago in a book (Author R
Zaks, title I can't remember).
It had an comparison table of the inner interpreter in 6502, 8080,
LSI-11, 6809, 8086 of how FIGforth does it.
6809 register usage was:
return stack S (hardware return stack, Forth has no JSR/RTS)
data stack U (user stack)
forths "instruction" pointer Y
forths loaded "instruction" (address of primitive) X
"do" was something like:
do: LDX (Y++)
JMP (X)
My 6809 instruction set sheet (incomplete, postbytes not explained)
plus a code example (Dragon 32 Basic ROM disassembly) here would
translate this to:
AE A1
6E 84
As the JMP do: at the end of every primitive would be 3 Bytes (7E xx
xx) and there are not that many primitives it was actually worth it to
put a copy of do: at the end of every primitive to save even more time.
Secondaries would start with an JSR to semis (here memory is very
unreliable, I have reconstructed this code):
semis: LDD , S++ ; EC E1 addr of first word, from JSR
STY ,--S ; 10 AF E3
TFR Y,D ; 1F 20
MACRO do: ; AE A1 6E 84
Then there are of course the fully orthogonal Arithmetic and stacking,
making "+" simply:
plus: LDD ,U++ ; EC C1
ADDD ,U++ ; E3 C1
STD ,--U ; ED C3
MACRO do ; AE A1 6E 84
Thats compact and fast. Terrific chip. At 2MHz, 1 clock per memory access.
> I wonder if a 6809 emulator would run at full speed on a 486/33..? ;>
> (Oh, that's a point, there's a Dragon emulator I should really look at
> first.)
I don't know, never tried. Have got an hardware Dragon, so why use an
emulator? :-)
This post was great fun. Assembler again. Ahhhh.
What klutz had the idea of high level languages. Should be
retroactively killed. Anyone got an time machine? :-)
Eric Smith
> apparently, one beer-lubricated evening at MOSTEK, some of the boys
> in the lab decided to see how fast a 6502 would go before it let that
[...]
> [told to me by one of the "flying tramiel brothers," whose dad ran
> commodore & owned MOSTEK at the time...]
That's MOS Technology, NOT MOSTEK!
Commodore never owned MOSTEK, and MOSTEK never made 6502s.
MOSTEK was a second-source for the Fairchild F8 and Zilog Z-80 microprocessor
families, the Motorola 68000, and developed the 3870 and 68200 families
of single-chip microcontrollers. They also offered quite a selection of
memory, peripheral, and telecommunications chips, and had a thriving
foundry business. MOSTEK is perhaps best known for inventing the
multiplexed-address DRAM, with the RAS and CAS lines engineers know and
love.
MOSTEK was acquired by United Technologies, then sold to SGS-Thomson,
which is now known as ST Microelectronics.
But they never made 6502s.
Landon Dyer
:>
:>Yes, OSI Superboard II was a nice toy. A colleague had one and he also
:>upped the clock to 2 MHz. He also tried 2.5 MHz, but then it began to
:>act unreliably.
[don't get me started on OSI systems... gad]
:>Yes, it was really fast, a nice device.
apparently, one beer-lubricated evening at MOSTEK, some of the boys
in the lab decided to see how fast a 6502 would go before it let that
all-important, enabling smoke out. i think the world's record for a
6502 (circa '83) was 25Mhz before it, ah, got tired...
[told to me by one of the "flying tramiel brothers," whose dad ran
commodore & owned MOSTEK at the time...]
-landon
Michael Kircher
> Quarz 14.31818|17.724472 divided 1:18|1:14 (74LS193+flipflop) goes to
> PLL (MC4044). Other input is from an PLL controlled VCO divided 1:8
> (6567|6565, the VIC chip). VCO is used for pixel clock, which is 8
> times CPU clock (1.0227|0.985248).
>
> After this you then get the problem that the VIC wants for every 8
> pixels 1 byte character number and 1 byte pixel pattern = 80 bytes
> from DRAM (plus 40 nibbles color number over separate bus from an 2114).
The character numbers were only read in the first raster of the
respective line, leading to a dead stop of the CPU for only
40*25 cycles per frame. In the following 7 rasters the VIC used
something like a cache => 1000 * 60|50 = 60000|50000 cps.
> That gives 1.0227|0.985248 - 0.48|0.40 = 0.54|0.58 MHz effective clock.
My correction gives 1.0227|0.985248 - 0.06|0.05 = 0.9627|0.935248
effective clock.
> Sprites costed an additional 21*4 clocks per frame and per sprite.
21*3 clocks as sprites were fixed 24 pixels (3 Bytes) width.
> Then there is the normal DRAM refresh, also done by the VIC.
In fact the bus had 2MBytes/sec bandwidth, used by the VIC to
read the character patterns every other cycle, with said exception
above. However the CPU was unable to use the free cycles in the border.
To give the VIC priority for memory accesss was a far better solution
than some Sinclair clones employed to resolve bus contention: In some
cases a busy CPU could lead to "snow" on the screen :).
Greetings,
Michael
Ralph Wade Phillips
William Hamblen wrote in message <365b7e1c...@news.nashville.com>...
>On Tue, 24 Nov 1998 01:00:16 -0000, "Andrew Cadley"
><a.p.c...@uea.ac.uk> wrote:
>
>>At 4Mhz you'll find the Z80 is nearly twice as fast as the 1Mhz 6502
>>routine. There is even a Z80 stack based version which is capable of doing
>>it in LESS CYCLES than the 6502 version. This is a classic example of
where
>>the Z80 is *significantly* faster.
>
>4 MHz was the "fast" Z80A. The "normal" Z80 ticked over at 2.5 MHz.
>An instruction fetch took 4 clocks and other memory references took 3.
>So a 2.5 MHz Z80 was roughly equivalent to a 1 MHz 6800 or 6502.
>A Z80A would be like a 68B00 (2 MHz clock). I don't recall the part
>number for a 2 Mhz 6502.
6502B, IIRC. The 65C02 was the CMOS 2MHz version, with the extended
instruction set (again, IIRC from my Apple ][ Service Center days. ORAM
failures may have occured ... )
>
>The big advantage of the MOS Technology 6502 back in 1975 was that it
>was a lot cheaper than the parts produced by the other manufacturers.
>That was important for garage inventors.
I remember reading an article where Woz mentioned that the main
reason for the Apple and the Apple ][ using a 6502 was that the 6800 was
still $400 in singles, the 8080 was $495 in singles, and the 6502 was under
$10 in singles ... You can put in a HELL of a lot of support TTL for that
difference!
Actually, I THINK it was the 6500 that was $10 - a pin compatible to
the 6800, which wasn't made very long (the 6502 wasn't pin compatible to
forstall a lawsuit from Motorola, IIRC.)
RwP