please have a look at my emmbedded comments below.
Dick
-----Original Message-----
From: Allison J Parent <allisonp(a)world.std.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Sunday, April 11, 1999 9:22 PM
Subject: Re: stepping machanism of Apple Disk ][ drive (was Re: Heatkit 51/4
floppies)
<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.
So I remembered these correctly? After all those years? Amazing . . .
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.
I didn't want to descend into the gate-level details of the CPU, but merely
to count clocks for comparison's sake.
<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
ability
<to execute stack-oriented operations faster than
the Z-80 and its kin
could
they werent! Not significantly. in most cases the time to actually execute
isn't that much different.
Well . . . I'd say it is significant, in view of the fact a Z-80 took three
clock ticks to access memory while a 6502 took only one. As I've said in
previous posts, the comparison at the memory bandwidth level came out in
favor of the Z-80 because it had a BETTER BASIC interpreter. If you compare
the fastest commercially available Z-80 with the fastest commercially
available 6502, the 6502 will win by a wide margin EVERY time. Compare the
Z80H (1983 or so) with the Synertek SYC6502C (1979) and you'll see that the
8 MHz Z-80 can't be counted on to win the race. If you like, you can
compare the 8 MHz Z-80H with the Rockwell 65C102, which takes a 4x clock.
Now it takes 4 clock ticks at 16 MHz to execute a bus cycle of any type.
Feed it an 8 MHz clock, it will still outdistance the Z-80H.
<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 took 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.
I remember what it was like trying to get delivery on 2147's back in '81. I
did manage to get the 55 ns parts for my 6502 based system. The bottom 16K
allowed the processor to run a 4 MHz, while the rest caused it to slow to 1
MHz. Since the assembler lived in the bottom 8K, and the editor we used
right above it, the combination was pretty fast. I eventually filled the
whole lower 48K with the fast SRAMS, as we had a card designed for the
TMS4044, which was a slow 2147.
My NSbox had 2116s that were 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.
Someone posted a small-c compiler for the 6502 as implemented in popular
machines of the early '80's. That might be worth a look. What I want is a
cross-compiler with a version for the PC as the target and one for the 6502.
That way I can debug on the PC and transfer my code to the 6502.
(Mitsubishi microcontrollers, actually)
I recently bought a couple of single board dedicated boards, and found that
they had the 4 MHz Rockwell CMOS parts on them. I didn't think I'd ever see
something like that in the scrap box. Oh well, once I've figured out the
memory map, they'll be useful for 1-of's.
Allison