<Well, Allison, you're going to force me to venture into the archives and
<fetch the data sheet.
Since I use z80s and kin often the data sheets for the z80 (all dozen or so)
starting with the 1977 ones are at hand. It helps that in my history is
applications engineering time at NEC microcomputers (they sold the uPD780
a z80).
<4mhz (shorter for M1 cycle)" is ABSOLUTELY correct. However, it took thre
<clock ticks in order to generate that cycle. IIRC, the entire M1 (opcode
<fetch + refresh) cycle took 4 or 5 (?) clock ticks, which made it the
<longest cycle. Memory cycles other than opcode fetches took 3 ticks and I
<believe I/O cycles took 4.
Don't ignore the fact that there are such thing as propagation delays
internal to the chip in the 50-80nS range or that some edges chaged on
the rising edge and some on the falling ones.
<The theory was that one execute a bunch of memory cycles to load up the
<internal registers of the Z-80, of which there are plenty, and then execut
<scads of register-register instructions which are faster, in order to
<accomplish a given computational task. It didn't easily work out that way
<a notion which wasn't lost on the designers of the 6502.
There are many schools of thought. the PDP-8 is and the 6502 have the
sparse hardware idea in common. the z80 is really a CISC machine and
reflects the more complex instruction set and the 8080 history.
<
<The MOS-Technology people who first implemented the 6502 architecture,
<recognized that although the Z-80 had plenty of registers, it still wasn't
<enough, so they shortened the memory access cycles. In fact, they used a
I don't feel that is a right way to say it. I'd go with... The mos
technology people with a limited silicone real estate (silicon costs alot
then) fewer register and a instruction set biased to use memory more.
That heritage comes from the 6800 which is a more similar part.
<done, and they opted for an 8-bit stack pointer, which gave them the abilit
<to execute stack-oriented operations faster than the Z-80 and its kin coul
they werent! Not significantly. in most cases the time to actually execute
isn't that much different.
<do so. It could look at its zero-page as extra-fast memory, or slow
<register space. In any case, a stack operation took one clock tick + one
<clock tick per byte. A zero page operation, depending on the operation in
<question, took one clock tick less time than that same instruction operatin
<on any of the rest of memory. A load or store took two cycles, and an
<indexed load or store took three.
The idea of zero page was straight from PDP-8 too. The zero page was a way
to solve the problem of too few registers. The TI9900 too an entirely
different path to solve that problem.
Which problem? Silicon real estate. registers are memory and that memory
eats silicon. back in that time frame you had some hard choices a with
regard to that. The Z80 was somewhat remarkable as there were 208 bits of
storage inside the processor for just user programable registers and bits.
<Today, we're equipped with cheap VERY fast large, SRAMs which would make i
<much easire to make a solid and objective test of the two processors.
<Unfortunately, there's little reason to do so, since neither is of any
<commercial interest.
In 1979 I had several tubes of 85nS 4kx1 rams that made a dandy memory.
They were static. I still have some of them. then in 1980 I got some slow
static 16kx1s that were only 70nS (2167) and built a z80 system that pushed
a 6mhz part to 7mhz. fast rams were available.
My NSbox had 2116s that wer 300ns and only 32 filled the memory space
on one board. that was 1981.
<Have YOU seen a 'C' compiler for any of the 6502 types?
Never. There could have been one but I'd wonder about code efficientcy.
Then again I've never seen one for 9900 bit that as CISC a machine if
there ever was one.
Allison
Received on Sun Apr 11 1999 - 21:51:18 BST