6501
Trevor James
mj> Does anyone know anything about this microprocessor? Ten years ago I
mj> read something in a back issue of a technical journal regarding the
mj> 6501. I don't recall if it was only a protoype or actually made it
mj> into production. Anyway, the 6501 had a bug or two, as well as some
mj> copyright problems. The new mask is
mj> what became the 6502, according to the article.
As far as I know Motorola stomped on the 6501 because it was a direct
clone of the 6800, both pin and code compatible. They changed the
instruction set a bit and the pin out and it became the 6502.... There
may be a bit more too it than that though...
Geoffrey Welsh
tc...@cloud.net.au (Trevor James) wrote:
Although I have no proof either way, I disagree.
I believe that the 6501 was instruction (and pin-?) compatible with
the 6502, but had only fourteen, in stead of sixteen, address bits,
giving it a 16K address space. It was used in some microcontroller
applications; I think I remember seeing one in a Commodore 4040
IEEE-488 intelligent dual disk drive, but I don't see it listed in the
Complete Commodore Inner Space Anthology, the canonical authority of
such technical trivia for Commodore 8-bit equipment.
I have heard (or read) a story that the 6501 and 6502 were introduced
together, at $20 and $25 respectively, in a 'hospitality suite' at an
electronics show where Intel and Motorola had been selling the 8080
and the 6800 (again, respectively) for over $150 each... prompting
both manufacturers to halve their prices.
The 650x series of CPUs from MOS Technologies bears some resemblance
to the 6800 instruction set, but the overwhelming impression that I
get from comparing registers and instruction sets is that the 6502 was
designed to be the simplest and most efficient microprocessor that
could be made... many people I know refer to the 6502 as the start of
the RISC philosophy.
(I was going to call it the "spark" of the RISC philosophy, but
thought better of it...)
--
Geoffrey Welsh, MIS Co-ordinator, InSystems Technologies (gwe...@insystems.com)
At home: xenitec.on.ca!zswamp!geoff; Temporary: crs...@inforamp.net
DO NOT SEND ANY FORM OF ADVERTISING TO ANY OF THESE ADDRESSES
John Bayko
In article <4ul1pv$o...@news.inforamp.net>,
Geoffrey Welsh <crs...@inforamp.net> wrote:
>tc...@cloud.net.au (Trevor James) wrote:
>
>>As far as I know Motorola stomped on the 6501 because it was a direct
>>clone of the 6800, both pin and code compatible. They changed the
>>instruction set a bit and the pin out and it became the 6502.... There
>>may be a bit more too it than that though...
>
>Although I have no proof either way, I disagree.
Although it's not 'proof', in the sense that it's for
'recreational purposes only', the Great Microprocessors list also
disagrees. Here's part of what it says:
----cut here----
Great Microprocessors of the Past and Present (V 8.1.2)
Section One: Before the Great Dark Cloud.
Part IV: The 650x, Another Direction (1975)
Shortly after the 8080, Motorola introduced the 6800. Some of the
designers left to work for MOS Technologies, which introduced the 650x
series which included the 6501 (pin compatible with the 6800, taken off
the market almost immediately for legal reasons) and the 6502 used in
early Commodores, Apples and Ataris. The 650x was little endian and had
a completely different instruction set from the big endian 6800. Apple
designer Steve Wozniak described it as the first chip you could get for
less than a hundred dollars (actually a quarter of the 6800 price).
[...]
----cut here----
>I believe that the 6501 was instruction (and pin-?) compatible with
>the 6502, but had only fourteen, in stead of sixteen, address bits,
>giving it a 16K address space.
You're probably thinking of one of the other variants of the 650x
- there were many.
>The 650x series of CPUs from MOS Technologies bears some resemblance
>to the 6800 instruction set, but the overwhelming impression that I
>get from comparing registers and instruction sets is that the 6502 was
>designed to be the simplest and most efficient microprocessor that
>could be made... many people I know refer to the 6502 as the start of
>the RISC philosophy.
The 'RISC' credit clearly goes to the RCA 1802. The similarity
between the 6800 and 6502 is entirely because the same designers worked
on both, and they were both modeled on the PDP-8. You can find the
complete Great Microprocessor list (over 150K) at the CPU Into Center
at:
http://infopad.eecs.berkeley.edu/CIC/
or from my home page (below).
--
John Bayko (Tau).
ba...@cs.uregina.ca
http://www.cs.uregina.ca/~bayko
Paul DeMone
crs...@inforamp.net (Geoffrey Welsh) wrote:
[snip]
>The 650x series of CPUs from MOS Technologies bears some resemblance
>to the 6800 instruction set, but the overwhelming impression that I
>get from comparing registers and instruction sets is that the 6502 was
>designed to be the simplest and most efficient microprocessor that
>could be made... many people I know refer to the 6502 as the start of
>the RISC philosophy.
>
Maybe simple, but how was the 6502 efficient? IMHO the Z80 and
6809 were much nicer 8 bit micros to program. The only thing I
liked about the 6502 was the binary/BCD ALU mode bit to avoid
the need for DAA instructions.
The 6502 architecture had nothing to do with RISC philosophy. If
anything, the 6502 was a RTCC or Reduced Transistor Count CISC.
The 6502 was register poor, had a multitude of addressing modes,
and was a lousy compiler target; quite opposite characteristics
from RISC CPUs.
[snip]
Paul
All opinions strictly my own.
--
Paul W. DeMone The 801 experiment SPARCed an ARMs race to put
Kanata, Ontario more PRECISION and POWER into architectures with
pde...@tundra.com MIPSed results but ALPHA's well that ends well.
Satan's CPU? The P666 of course - check out Appendix H(ell) under NDA
William H. Ivey
In <4uo05b$e...@kannews.ca.newbridge.com> Paul DeMone
<pde...@tundra.com> writes:
>
> Maybe simple, but how was the 6502 efficient? IMHO the Z80 and
> 6809 were much nicer 8 bit micros to program. The only thing I
> liked about the 6502 was the binary/BCD ALU mode bit to avoid
> the need for DAA instructions.
The average cycles-per-instruction on the 6502 was about 2 (thanks to
some basic pipelining). The Intel and Zilog chips required a lot more
cycles for even basic instructions. When I moved from a 4Mhs z80 to a
1Mhz Apple IIe I was shocked at the speed improvment possible with a
bit of careful programming. (Even now, the 6502 beats out several other
processors - some of which struggle along with 11 cycles per
instruction.)
> The 6502 architecture had nothing to do with RISC philosophy. If
> anything, the 6502 was a RTCC or Reduced Transistor Count CISC.
> The 6502 was register poor, had a multitude of addressing modes,
> and was a lousy compiler target; quite opposite characteristics
> from RISC CPUs.
True, the 6502 had only three useful registers, but it had 256
pseudo registers available externally for only a 1cycle penalty. Not
much by today's cache standards, but impressive in it's time. That, and
a built in oscilator circuit made it a designer's dream. (The 65816 is
even more fun, 16 bit registers, and 24 bit addresses for many
operations. Let's you do a LOT in only 64K of code - the voice of
expereince speaks :-) -Wm
Henrik Johnsson
Paul DeMone (pde...@tundra.com) wrote:
> Maybe simple, but how was the 6502 efficient? IMHO the Z80 and
> 6809 were much nicer 8 bit micros to program. The only thing I
> liked about the 6502 was the binary/BCD ALU mode bit to avoid
> the need for DAA instructions.
I agree that both Z80 and 6809 were nice to program. The 6809 came out
quite some time later than the 6502 IIRC and was a bit expensive. At
its time the 6502 gave you a tremendous amount of bang per MHz, at least
compared to the Z80 which often took far more clock cycles to complete
each instruction. I never used the 6502 but reading the data sheet was
enough to show the areas where it would kick Z80's butt. The Z80 was
the first I learned so I'll continue to swear by it tho :-)
> The 6502 architecture had nothing to do with RISC philosophy. If
> anything, the 6502 was a RTCC or Reduced Transistor Count CISC.
> The 6502 was register poor, had a multitude of addressing modes,
> and was a lousy compiler target; quite opposite characteristics
> from RISC CPUs.
Well compiler target was not much of an issue back when the 6502 was
introduced. Most hobbyists were thrilled if they had an assembler so
they didn't have to hand code the stuff.
There are no agreed on rules for what makes a design RISC or not, the
thing that has made the 6502 a candidate probably is that it has no
microcode (or has it????). At least that's my guess.
> Paul
> All opinions strictly my own.
Same here.
/Henrik
--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/ Ericsson Microwave Systems AB _/
_/ Henrik....@emw.ericsson.se _/
_/ tel +46 31 671898, fax +46 31 673833 _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
John Bayko
In article <4up0or$p...@dfw-ixnews7.ix.netcom.com>,
William H. Ivey <wi...@ix.netcom.com> wrote:
>
>The average cycles-per-instruction on the 6502 was about 2 (thanks to
>some basic pipelining). The Intel and Zilog chips required a lot more
>cycles for even basic instructions.
This deals with the way that the clock signals are used. The 6502
was based on the 6800 bus timing, which (if I recall correctly) is
split internally into two signals 90 degrees out of phase, which is a
different idea than the clock doubling that's popular now, but has the
same general effect - one 6800/6502 clock signal equals four 8080/Z80
signals. This resulted in bus signals being somewhat asynchronous
between the clock signals (again, I'm trusting my memory).
I've seen 6809s listed in 8MHz versions which are identical to
the 2MHz version, except it uses the more common bus interface style.
>In <4uo05b$e...@kannews.ca.newbridge.com>
> Paul DeMone <pde...@tundra.com> writes:
>
>> The 6502 architecture had nothing to do with RISC philosophy. If
>> anything, the 6502 was a RTCC or Reduced Transistor Count CISC.
>> The 6502 was register poor, had a multitude of addressing modes,
>> and was a lousy compiler target; quite opposite characteristics
>> from RISC CPUs.
>
> True, the 6502 had only three useful registers, but it had 256
>pseudo registers available externally for only a 1cycle penalty. Not
>much by today's cache standards, but impressive in it's time.
The 'direct page' memory wasn't treated like registers (you
couldn't even add two DP locations). And what happened if you tried to
switch processes? Unless you wanted to copy half a K of memory for
every context switch (DP and fixed position stack)... The Texas
Instruments TMS9900 did store its registers in RAM, but they were used
like real registers. And the 6809 could relocate the DP and stack
anywhere in RAM, making multitasking systems easy to implement.
>That, and a built in oscilator circuit made it a designer's dream.
Designer maybe, but programmers have to look at its insides.
Tim Shoppa
In article <4uqoif$n...@sue.cc.uregina.ca>,
John Bayko <ba...@BOREALIS.CS.UREGINA.CA> wrote:
> The 'direct page' memory wasn't treated like registers (you
>couldn't even add two DP locations).
A moot point, as on a 6502, you couldn't even add two registers. To
call the instruction set (and the addressing modes which were seemingly
randomly allowed or disallowed) irregular is an understatement.
>>That, and a built in oscilator circuit made it a designer's dream.
>
> Designer maybe, but programmers have to look at its insides.
While the instruction set may not be "politically correct" today,
the 6502 was quite effective in its time. Writing assembly code
for it was straightforward once you got used to the bizarre
instruction set.
Tim.
William H. Ivey
In <4uqoif$n...@sue.cc.uregina.ca> ba...@BOREALIS.CS.UREGINA.CA (John
>
>In article <4up0or$p...@dfw-ixnews7.ix.netcom.com>,
> William H. Ivey <wi...@ix.netcom.com> wrote:
>>
>>The average cycles-per-instruction on the 6502 was about 2 (thanks to
>>some basic pipelining). The Intel and Zilog chips required a lot more
>>cycles for even basic instructions.
>
> This deals with the way that the clock signals are used. The 6502
>was based on the 6800 bus timing, which (if I recall correctly) is
>split internally into two signals 90 degrees out of phase, which is a
>different idea than the clock doubling that's popular now, but has the
>same general effect - one 6800/6502 clock signal equals four 8080/Z80
>signals. This resulted in bus signals being somewhat asynchronous
>between the clock signals
Actually, they were synchronised to one or the other phase, generally.
The electrical/timing interface was simple and straightforword - didn't
need the external signal latch of the 8080, for example.
>> True, the 6502 had only three useful registers, but it had 256
>>pseudo registers available externally for only a 1cycle penalty. Not
>>much by today's cache standards, but impressive in it's time.
>
> The 'direct page' memory wasn't treated like registers (you
>couldn't even add two DP locations).
So? You couldn't add to X or Y, either (except to increment/decrement),
so in that sense, the direct page was very register like.
>And what happened if you tried to switch processes? Unless you wanted
>to copy half a K of memory for every context switch (DP and fixed
position stack)...
Switch processes? Get real, this IS a 6502 we're talking about :-)
(Actually, I did do context switching on a word processor I wrote. The
WP engine was driven off of a BASIC front-end - made it easy to
customize, the custome wanted four versison - and swapped out the DP
whenever editing mode was entered. Took about .0015 seconds or so.)-Wm
William H. Ivey
In <4uqqfo$1...@nntp.ucs.ubc.ca> sho...@alph02.triumf.ca (Tim Shoppa)
writes:
>>couldn't even add two DP locations).
>
>call the instruction set (and the addressing modes which were
seemingly
>randomly allowed or disallowed) irregular is an understatement.
>
>>>That, and a built in oscilator circuit made it a designer's dream.
>>
>> Designer maybe, but programmers have to look at its insides.
>
>While the instruction set may not be "politically correct" today,
>the 6502 was quite effective in its time. Writing assembly code
>for it was straightforward once you got used to the bizarre
>instruction set.
After a while you could do it in your sleep. In fact, for a while, I
could write 6502/65816 assembly at a rate comparable to writing C. My
skills are a bit rusty now since it's been a couple of years. (I helped
do the ports of Ultima VII and Savage Empire to the SNES (65816) - only
took about 64K of code to handle the whole game. Lots of data, though
lots of data :-) -Wm
Paul DeMone
wi...@ix.netcom.com(William H. Ivey) wrote:
>In <4uo05b$e...@kannews.ca.newbridge.com> Paul DeMone
><pde...@tundra.com> writes:
>>
>> 6809 were much nicer 8 bit micros to program. The only thing I
>> liked about the 6502 was the binary/BCD ALU mode bit to avoid
>> the need for DAA instructions.
>
>some basic pipelining). The Intel and Zilog chips required a lot more
I think your CPI value for the 6502 is far too optimistic. IIRC
the fastest 6502 instructions (immediate to accum) ran in 2 clocks,
the others piled on cycles in a hurry. Regardless, it is not a
meaningful comparison since the Z80 spread its memory access over
3 clocks (4 ?) while the 6502 required an entire memory access to
take place in a single clock period to avoid wait states. Consider
the effect of adding a single wait state to memory bandwidth of a
Z80 vs a 6502. The 6502 prefetch was a nice touch though.
Cycle count based efficiency comparisons between the 6502 and Z80
are invalid even for internal processing. The Z80 had a 4 bit ALU
that was cycled twice for 8 bit operations. On the average Z80,
instructions took more cycles but much higher Z80 clock rates were
achievable in comparable processes. This is similar to comparing
an Alpha 21164A to a PowerPC 604e or P6 on the basis of average
CPI but not considering differences in clock rate (the flip side
of this - clock rate based comparisons ignoring differences in
microarchitecture are equally invalid).
>1Mhz Apple IIe I was shocked at the speed improvment possible with a
>bit of careful programming. (Even now, the 6502 beats out several other
>processors - some of which struggle along with 11 cycles per
>instruction.)
With a 4 MHz Z80, 11 clocks is faster than 3 clocks on a 1 MHz
6502; and a lot of 6502 instructions take longer than 3 clocks.
IMHO, If you got a speed improvement moving from a 4 MHz Z80 to a
1 MHz 6502 (assuming both platforms had no wait states) then the
original code sure didn't exploit the full capabilities of the Z80
instructions and registers (or were running pretty atypical code).
My experience with both was that if you thoughtfully used all your
registers and coded with an eye on the cycle counts you could make
the Z80 really fly. OTOH, 6502 optimization tended to be limited to
clever page zero management. The manipulation of 16 bit data and
pointers was in particular a lot nicer and more efficient on the Z80
than the 6502.
>
>> The 6502 architecture had nothing to do with RISC philosophy. If
>> anything, the 6502 was a RTCC or Reduced Transistor Count CISC.
>> The 6502 was register poor, had a multitude of addressing modes,
>> and was a lousy compiler target; quite opposite characteristics
>> from RISC CPUs.
>
> True, the 6502 had only three useful registers, but it had 256
>pseudo registers available externally for only a 1cycle penalty. Not
Look at it from the on-chip perspective. The internal logic
decides in clock period 1 that it needs data from a page zero
"register" so it sets up for an access in clock period 2 by
forming the effective address. The address is driven out at
the beginning of clock period 2 and, assuming no wait states,
the data is clocked in at the end of clock period 2. It is
then available for processing in clock period 3.
In reality your pseudo registers have a 1.5 - 2.0 clock period
access time (vs < 0.5 for true register access) although some
overlap is possible on chained or sequential accesses. On a
Z80 the disparity is even greater given the multicycle memory
access. Also, the use of Z80 register pairs (BC, DE, HL) or
index registers gave quick access to any location in the 64K
address space; the 6502 would burn two accesses just to fetch
the effective address from page zero. Finally, the Z80 had a
full 16 bit stack pointer which simplified stack management.
>much by today's cache standards, but impressive in it's time. That, and
>a built in oscilator circuit made it a designer's dream. (The 65816 is
And the Z80 had a built-in refresh counter for DRAM support.
These extras are nice but hardly relevent in comparing chip
performance or "efficiency" of micro architectures.
>even more fun, 16 bit registers, and 24 bit addresses for many
>operations. Let's you do a LOT in only 64K of code - the voice of
>expereince speaks :-) -Wm
Yes, I remember when 64KB was but a hopeless, unaffordable
dream ("who could possibly afford to populate all 64K ?" - it
reminds me of current criticisms of 64 bit machines). When
16 KB was a high end machine it seemed like you could run a
city with 64KB.
Now many CPUs have 64 KB or more of on-chip cache (21164, 604e,
R5K, R10K, PA-7300LC) and Mitsubishi has put a 32 bit RISC CPU
and 2 MB of DRAM on a single chip (M32R/D)!
>
>
BTW, comparing the pros and cons of the Z80 vs the 6502 must
seem pretty distant to the kids debating Pentium vs 6x86 for
running 3D games :-)
Paul
All opinions strictly my own.
--
Paul DeMone
emw...@emw.ericsson.se (Henrik Johnsson) wrote:
>Paul DeMone (pde...@tundra.com) wrote:
>
>> Maybe simple, but how was the 6502 efficient? IMHO the Z80 and
>> 6809 were much nicer 8 bit micros to program. The only thing I
>> liked about the 6502 was the binary/BCD ALU mode bit to avoid
>> the need for DAA instructions.
>quite some time later than the 6502 IIRC and was a bit expensive. At
This is true, the 6809 tended to compete against the 8088 for
sockets rather than the Z80 or 6502.
>its time the 6502 gave you a tremendous amount of bang per MHz, at least
>compared to the Z80 which often took far more clock cycles to complete
Yes but the 6502 needed memory fast enough to access in one clock
cycle (vs three cycles for the Z80) and the Z80 could be built much
faster in an equivalent process. Its like comparing Alpha to PowerPC
in terms of bang per MHz - it is not relevant.
>each instruction. I never used the 6502 but reading the data sheet was
>enough to show the areas where it would kick Z80's butt. The Z80 was
>the first I learned so I'll continue to swear by it tho :-)
>
>> The 6502 architecture had nothing to do with RISC philosophy. If
>> anything, the 6502 was a RTCC or Reduced Transistor Count CISC.
>> The 6502 was register poor, had a multitude of addressing modes,
>> and was a lousy compiler target; quite opposite characteristics
>> from RISC CPUs.
>Well compiler target was not much of an issue back when the 6502 was
>introduced. Most hobbyists were thrilled if they had an assembler so
>they didn't have to hand code the stuff.
I agree compilers were pretty much a non-issue for 8 bit micros
back then but it is relevent in terms of being RISC like.
>There are no agreed on rules for what makes a design RISC or not, the
Yes and no. RISC isn't a set of features. Rather it represents a
rational, quantitative approach to computer architecture design, kind
of a computing equivalent of the scientific method. It happens that
most chip and computer makers share similar physical and economic
constraints. So it isn't suprising that when different companies set
out with a common aim (build a high performance general purpose CPU
suitable for running C programs and Unix) the resulting RISC archit-
ectures were very similar in many ways.
Common use of the term RISC generally means to share most of the
same characteristic as the original commercial RISC architectures
like MIPS, SPARC, and HP PA (i.e. 32 bit uniform instruction length,
triadic register based instructions, load/store memory access only,
delayed branches, large general purpose register file(s) etc).
>thing that has made the 6502 a candidate probably is that it has no
>microcode (or has it????). At least that's my guess.
The 8 bit micros were almost all hardwired (i.e. no microcode)
due to the limited complexity permitted on a 20-25 mm2 die built
in a 5 or 6 um NMOS process. The 8086 and 68K were among the
first microprocessors to use microcode. Use of microcode allowed
complex ISA's to be implemented in a regular fashion permitting
reasonable design times and late bug fixes* (at the cost of much
higher transistor count, although not necessarily larger chips).
This is clearly demonstrated by comparing the 17,500 transistor
hardwired Z8000 to the 68,000 transistor 68K. Both architectures
were roughly equivalent in complexity and chip performance was
also similar. Unfortunately, the Z8000 took much longer to
design and debug than the 68000 and was too late to make much
of an impact.
RISC processors go back to hardwired design but typically have
much simpler control logic for instruction sequencing and
exception handling than even 8 bit micros. Also the CAD tools
are much better now :-)
* imagine laying out a chip with control logic having hundreds
of states built out of manually packed flip-flops, gates and
irregular signal routing. Then imagine finding you need to
make one "little" logic fix... ;-)
[snip]
William H. Ivey
In <4usr2f$1...@kannews.ca.newbridge.com> Paul DeMone
<pde...@tundra.com> writes:
>wi...@ix.netcom.com(William H. Ivey) wrote:
>>The average cycles-per-instruction on the 6502 was about 2 (thanks to
>>some basic pipelining). The Intel and Zilog chips required a lot more
>>cycles for even basic instructions. When I moved from a 4Mhs z80 to a
>
> I think your CPI value for the 6502 is far too optimistic. IIRC
> the fastest 6502 instructions (immediate to accum) ran in 2
> clocks, the others piled on cycles in a hurry.
The most common instructions all took 2 clock cycles, including
branches if the branch wasn't taken. (I believe loading the accumulator
with an immediate value took 3.) Push and pop instructions took a
couple of more cycles since they coupled a load with an incrment or
decrement. On most code where I counted up clocks (a lot of code), the
average clocks per instruction was 2.2-2.5.
> With a 4 MHz Z80, 11 clocks is faster than 3 clocks on a 1 MHz
> 6502; and a lot of 6502 instructions take longer than 3 clocks.
Not the most frequently used ones.-Wm
Henrik Johnsson
William H. Ivey (wi...@ix.netcom.com) wrote:
> In <4uqqfo$1...@nntp.ucs.ubc.ca> sho...@alph02.triumf.ca (Tim Shoppa)
> writes:
> >
> >While the instruction set may not be "politically correct" today,
> >the 6502 was quite effective in its time. Writing assembly code
> >for it was straightforward once you got used to the bizarre
> >instruction set.
> After a while you could do it in your sleep. In fact, for a while, I
> could write 6502/65816 assembly at a rate comparable to writing C.
[snip]
This may be a myth since it concerns a friend of a friend, you know the
classic mark of an urban legend, but still...
This FOF knew the opcodes and the ASCII table well enough to write short
code snippets straight into the screen memory of his VIC-20. Suppose he
wanted an operation with the opcode 53h, he then entered 'S' and after
he had typed in the whole program this way he requested the computer to
start execution at the beginning of the scren memory!
A tale like this just has to be followed by disclaimers. I don't make
any statements about the truth of the above tale, but it sure sounds
intriguing.
Mark Hughes
Henrik Johnsson <emw...@emw.ericsson.se> spake:
>This may be a myth since it concerns a friend of a friend, you know the
>classic mark of an urban legend, but still...
>This FOF knew the opcodes and the ASCII table well enough to write short
>code snippets straight into the screen memory of his VIC-20. Suppose he
>wanted an operation with the opcode 53h, he then entered 'S' and after
>he had typed in the whole program this way he requested the computer to
>start execution at the beginning of the scren memory!
Probably true, actually. I used to write short assembly routines on the
Atari 8-bit in strings - a=usr("..."). I had to keep the ATASCII/assembly
chart handy, becuase I couldn't remember it ALL by heart (the heart was ATASCII
0, by the way, generated by typing <esc>ctrl-, (I mercifully cannot recall if
the escape was required there, but it wouldn't hurt)), and I had to look up
most constants, but it was quite doable.
>A tale like this just has to be followed by disclaimers. I don't make
>any statements about the truth of the above tale, but it sure sounds
>intriguing.
"And you try to tell today's kids this, and they won't believe you."
-<a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"In headlines today, the dreaded killfile virus spread across the country
adding aol.com to people's usenet kill files everywhere. The programmer of
the virus still remains anonymous, but has been nominated several times for
a Nobel peace prize." -Mark Atkinson
Nick Spalding
.emw...@emw.ericsson.se (Henrik Johnsson) wrote:
> This may be a myth since it concerns a friend of a friend, you know the
> classic mark of an urban legend, but still...
> This FOF knew the opcodes and the ASCII table well enough to write short
> code snippets straight into the screen memory of his VIC-20. Suppose he
> wanted an operation with the opcode 53h, he then entered 'S' and after
> he had typed in the whole program this way he requested the computer to
> start execution at the beginning of the scren memory!
Back in The Good Old Days(tm) on any IBM 1400 series machine after the
1401 itself (which didn't have a console typewriter) you could type
code straight into the machine since all 64 possible characters were
available on the keyboard. Indeed that was what you had to do to boot
a 1410, there was no load button; you had to enter a Read a record
(could be card or tape), followed by Clear Interlock and Branch to
start the ball rolling.
--
Nick Spalding
Paul DeMone
wi...@ix.netcom.com(William H. Ivey) wrote:
>In <4usr2f$1...@kannews.ca.newbridge.com> Paul DeMone
><pde...@tundra.com> writes:
>>
>>wi...@ix.netcom.com(William H. Ivey) wrote:
>>>some basic pipelining). The Intel and Zilog chips required a lot more
>>>cycles for even basic instructions. When I moved from a 4Mhs z80 to a
>>
>> I think your CPI value for the 6502 is far too optimistic. IIRC
>> the fastest 6502 instructions (immediate to accum) ran in 2
>> clocks, the others piled on cycles in a hurry.
>
>branches if the branch wasn't taken. (I believe loading the accumulator
Taken branches took an extra clock on a 6502 if a 256 byte
boundary was crossed and this was commonly overlooked. Of
course the frequency that this occured depended on the
organization of your code.
>with an immediate value took 3.) Push and pop instructions took a
>couple of more cycles since they coupled a load with an incrment or
>decrement. On most code where I counted up clocks (a lot of code), the
>average clocks per instruction was 2.2-2.5.
I guess you didn't have to do many accesses via 16 pointers
in your code; Zero page accesses are great (particularly on a
6502) if you can get away with it for the majority of your work;
as you apparently did.
>
>> With a 4 MHz Z80, 11 clocks is faster than 3 clocks on a 1 MHz
>> 6502; and a lot of 6502 instructions take longer than 3 clocks.
>
And IIRC register to register 8 bit arithmetic and logical
instructions took only 4 clocks on a Z80 and 16 bit adds
were just a bit slower.
>Not the most frequently used ones.-Wm
Depends on what you are doing. As a simple example compare
the Z80 vs 6502 coding for a subroutine to move up to 256
bytes between any two *arbitrary* 16 bit addresses ;-)
As a complex example consider implementing a Lisp interpreter
(linked list heaven!) on a 6502 as opposed to a Z80; *shudder*
William H. Ivey
In <4v23fn$i...@kannews.ca.newbridge.com> Paul DeMone
<pde...@tundra.com> writes:
>
> Taken branches took an extra clock on a 6502 if a 256 byte
> boundary was crossed and this was commonly overlooked. Of
> course the frequency that this occured depended on the
> organization of your code.
Since the max branch range was half that, it wasn't to hard to locate
critical code aways from page boundaries.
> I guess you didn't have to do many accesses via 16 pointers
> in your code; Zero page accesses are great (particularly on a
> 6502) if you can get away with it for the majority of your work;
> as you apparently did.
For every 16-bit addressed load or store, there were a lot of incs,
decs, cmps, and other relatively cheap instructions.-Wm
Gord Campbell
>And what happened if you tried to switch processes? Unless you wanted
>to copy half a K of memory for every context switch (DP and fixed
WH>Switch processes? Get real, this IS a 6502 we're talking about :-)
There was a PD program for the PET which would multi-task two BASIC
programs!
Unlike the Apple ][, the PET was by nature a multi-process machine.
Timer interrupts were used to scan the keyboard, and talking to the
IEEE-488 bus was also interrupt driven, if memory serves. Most of page
zero was allocated to documented uses, so none of it needed to be
swapped. (Except to do things like multi-task two BASIC programs, of
course....)
Once upon a time I re-wrote the keyboard scan routine to make it
interruptible, since it took about 1/600 of a second to run, and I
wanted timed interrupts more frequently than 600 a second....
---
ş DeLuxeı 1.25 #7680 ş gord.c...@ablelink.org
Geoffrey Welsh
Paul DeMone <pde...@tundra.com> wrote:
> Maybe simple, but how was the 6502 efficient? IMHO the Z80 and
> 6809 were much nicer 8 bit micros to program.
I, too, liked the 6809, but consider the Z80 very inefficient. One of
the computers I've worked with over the years was a Commodore 128,
which included both a 6502 variant and Z80. One acquaintance, working
on a then-well known word processor, decided to try flipping the
machine from 6502 mode to Z80 mode to make use of the Z80's block move
instructions... until he found out that he could do it faster in a
loop of 6502 instructions.
The 6502 used a two-phase clock, which allows it to complete a memory
transfer in a single cycle. Actually, it allows it to complete a
memory transfer in _half_ a cycle, allowing DMA to take place at the
CPU's speed (assuming that your memory could handle it) without any
performance impact on the CPU. By contrast, it appears that the Z80
requires four cycles for a memory transfer (please feel free to
correct me if I'm wrong), which is both slower and prevents consistent
non-conflicting DMA.
It was a very sad day for me when I discovered that the 68000 also
used four-cycle memory accesses.
Most 6502 instructions execute in 4 to 6 cycles, with several
executing on 2 cycles (fetch & execute). The worst instructions are
read-modify-write instructons (increment, decrement, shift, rotate)
with register-indexed absolute addresses, which require that the CPU
read four bytes (one instruction byte, two address bytes, one data
byte) and write one but take only seven clock cycles to execute.
Based on the timing value provided for various instructions, I
conclude that the folowing cycles are required:
- fetch
- decode
- fetch address low byte
- fetch address high byte
- add index register
- fetch target byte
- perform operation
- write target byte
... all done in fewer cycles than it takes for most CPUs to perform
an instruction fetch and the data fetch, leaving room for 7 DMA cycles
in between, and with a minimum of silicon.
Yes, I call that _efficient_. Not pretty, I admit, but efficient.
> The 6502 architecture had nothing to do with RISC philosophy. If
> anything, the 6502 was a RTCC or Reduced Transistor Count CISC.
> The 6502 was register poor, had a multitude of addressing modes,
> and was a lousy compiler target; quite opposite characteristics
> from RISC CPUs.
Did RISC always mean leading edge performance, or was there ever a day
when it meant reduced cost and complexity? The 6502 was obviously a
'bang for the buck' design. Also, the 68000 had a large register set
and an orthogonal instruction set; do those shared characteristics
define what is and isn't RISC?
Geoffrey Welsh
ba...@BOREALIS.CS.UREGINA.CA (John Bayko) wrote:
> This deals with the way that the clock signals are used. The 6502
>was based on the 6800 bus timing, which (if I recall correctly) is
>split internally into two signals 90 degrees out of phase, which is a
>different idea than the clock doubling that's popular now, but has the
>same general effect - one 6800/6502 clock signal equals four 8080/Z80
>signals. This resulted in bus signals being somewhat asynchronous
>between the clock signals (again, I'm trusting my memory).
That's a fair comment, and the 4:1 ratio has been commonly used... but
keep in mind that the memory cycle is only half of the CPU cycle. If
you include transparent non-conflicting DMA, you have a basis for
arguing that the ratio of bus bandwidth could be as high as 8:1.
> I've seen 6809s listed in 8MHz versions which are identical to
>the 2MHz version, except it uses the more common bus interface style.
I've also seen conventional 6502 designs pushed to 4 MHz... the
equivalent of 16 MHz on the "more common bus". Bloody fast CPU, but
held back by older I/O devices. <sigh>
>>In <4uo05b$e...@kannews.ca.newbridge.com>
>> Paul DeMone <pde...@tundra.com> writes:
>> True, the 6502 had only three useful registers, but it had 256
>>pseudo registers available externally for only a 1cycle penalty. Not
>>much by today's cache standards, but impressive in it's time.
> The 'direct page' memory wasn't treated like registers (you
>couldn't even add two DP locations). And what happened if you tried to
>switch processes? Unless you wanted to copy half a K of memory for
>every context switch (DP and fixed position stack)... The Texas
>Instruments TMS9900 did store its registers in RAM, but they were used
>like real registers. And the 6809 could relocate the DP and stack
>anywhere in RAM, making multitasking systems easy to implement.
That's a good observation, but some later 6502 derivatives also
allowed 'zero page' and the stack to be relocated. I don't think that
the 6502 was really intended for general purpose multitasking systems,
and 'multitasking' microcontroller applications usually didn't need
separate zero pages.
Geoffrey Welsh
sho...@alph02.triumf.ca (Tim Shoppa) wrote:
>A moot point, as on a 6502, you couldn't even add two registers. To
>call the instruction set (and the addressing modes which were seemingly
>randomly allowed or disallowed) irregular is an understatement.
Not really:
All accumulator-based operations (logic, math, load, store, compare)
operated in all eight addressing modes (except store immediate; you
can't store the accumulator to a literal value, naturally). Indirect
addressing mode was reserved for operations where the accumulator was
the target register.
You could increment, decrement, or transfer to/from the accumulator
any register you liked, but you couldn't transfer directly from index
register X to index register Y or vice versa.
You could not use X as an index when loading/storing X, nor Y when
loading/storing Y. Although such instructions might have been
slightly more useful than 'push stack pointer' or 'jump to random
location', I didn't miss them.
You could not use the Y register to index a read-modify-write
operation (increment/decrement, shift, or rotate), but X was OK. This
was one of two attributes that differentiated X from Y.
That's not many rules to remember (no more than the rules you'll need
to figure out which segment register will be used for any particular
8086 instruction!), and none are particularly strange... except for
two things:
When loading or storing an index register, you could index using the
opposite register (e.g. LDX <addr>,Y), _except_ when storing to an
absolute address (e.g. STX 80,Y was OK because it was a zero-page
address; LDX 0400,Y was OK because it was a load; STX 0400,Y was not
OK).
The BIT instruction is like a logical AND but, in stead of writing the
result to the accumulator, it discards th result. It was useful
because it set status flags such as zero (no "1" bits in common
between the mask in the accumulator and the target memory location).
However, although it's arguable that this instruction should fall into
the scope of the first rule that I gave above, only direct (zero page
or absolute) addressing was supported. No indirection or even
indexing was allowed. An immediate mode implementation would allow
you to specify the mask literally, in stead of loading it into the
accumulator.
>While the instruction set may not be "politically correct" today,
>the 6502 was quite effective in its time. Writing assembly code
>for it was straightforward once you got used to the bizarre
>instruction set.
Bizarre compared to whom?!? I wrote a lot of 6502 over the years, but
I'd rather write C and modify the compiler's assembly code than write
my own 8086!
Geoffrey Welsh
No myth; I did this on the Commodore PET for quick'n'dirty demos to
compare the size & speed of very simple 6502 and BASIC programs. I've
never heard of anyone doing something non-trivial this way.
The PET's screen started at 0x8000; programs typed on the screen were
started by the command "SYS 32768". The VIC's screen moved depending
on which memory expander(s) you had installed.
emw...@emw.ericsson.se (Henrik Johnsson) wrote:
>This may be a myth since it concerns a friend of a friend, you know the
>classic mark of an urban legend, but still...
>This FOF knew the opcodes and the ASCII table well enough to write short
>code snippets straight into the screen memory of his VIC-20. Suppose he
>wanted an operation with the opcode 53h, he then entered 'S' and after
>he had typed in the whole program this way he requested the computer to
>start execution at the beginning of the scren memory!
>A tale like this just has to be followed by disclaimers. I don't make
>any statements about the truth of the above tale, but it sure sounds
>intriguing.
William H. Ivey
In <4vq7vg$1...@news.inforamp.net> crs...@inforamp.net (Geoffrey Welsh)
writes:
>[...]
>The 6502 used a two-phase clock, which allows it to complete a memory
>transfer in a single cycle. Actually, it allows it to complete a
>memory transfer in _half_ a cycle, allowing DMA to take place at the
>CPU's speed (assuming that your memory could handle it) without any
>performance impact on the CPU.
Which the Apple II's took advantage of for video DMA (and memory
refresh, as I recall). As far as the CPU was concerned, it was alone on
the bus even in the current video page.
>It was a very sad day for me when I discovered that the 68000 also
>used four-cycle memory accesses.
The 68000 only accesses memory on one phase of the clock, as well.
That's why the Amiga's video hardware DMA didn't have an impact on CPU
throughput under normal circumstances - they were usually isolated from
each other by the clock phase (using a high-res format with lots of
hardware sprites WOULD start stealing CPU cycles). -Wm
Eric J. Korpela
In article <4vq7vg$1...@news.inforamp.net>,
Geoffrey Welsh <crs...@inforamp.net> wrote:
>
>I, too, liked the 6809, but consider the Z80 very inefficient. One of
>the computers I've worked with over the years was a Commodore 128,
>which included both a 6502 variant and Z80. One acquaintance, working
>on a then-well known word processor, decided to try flipping the
>machine from 6502 mode to Z80 mode to make use of the Z80's block move
>instructions... until he found out that he could do it faster in a
>loop of 6502 instructions.
That's more a statement about the poor design of the Commodore 128 than
it is about the design of the Z80. Sure, at identical clock speeds the
6502 would outpace the Z-80. But then again they didn't run at identical
clock speeds. Typical 6502 speed was 1 Mhz. Typical Z-80 speed was 4-5 Mhz.
Later machines had 2 Mhz 6502 and 8 Mhz Z-80. The Commodore 128 had a
2 Mhz 6502 and a 1.8 (effectively) Mhz Z-80.
>The 6502 used a two-phase clock, which allows it to complete a memory
>transfer in a single cycle. Actually, it allows it to complete a
>memory transfer in _half_ a cycle, allowing DMA to take place at the
>CPU's speed (assuming that your memory could handle it) without any
>performance impact on the CPU. By contrast, it appears that the Z80
>requires four cycles for a memory transfer (please feel free to
>correct me if I'm wrong), which is both slower and prevents consistent
>non-conflicting DMA.
It's not slower if the Z-80 is running at more than 4 times the speed
of the 6502 (which was typical). The DMA rates of systems with both
CPUs were fairly similar. (The other half cycle on the 6502 was usually
used for RAM refresh anyway.) In each case a byte transfer took on average
750 ns.
>It was a very sad day for me when I discovered that the 68000 also
>used four-cycle memory accesses.
Also at a much higher clock rate.
>Most 6502 instructions execute in 4 to 6 cycles, with several
>executing on 2 cycles (fetch & execute).
Change that to instructions per second and you've got 166 to 500 kIPS.
On a 4 MHz Z-80 instructions run 6 to 15 cycles so you get 267 to 667 kIPS.
How does that make the Z-80 slower?
Not to rag on the 6502, but I always used to go to my Apple ]['s Z-80 card
if I needed to do math. Frankly the Z-80 was a great FPA.
Eric
--
Eric Korpela | An object at rest can never be
kor...@ssl.berkeley.edu | stopped.
<a href="http://www.cs.indiana.edu/finger/mofo.ssl.berkeley.edu/korpela/w">
Click here for more info.</a>
John West McKenna
crs...@inforamp.net (Geoffrey Welsh) writes:
[6502 read-modify-write with indexed addressing mode]
> - fetch
> - decode
> - fetch address low byte
> - fetch address high byte
> - add index register
> - fetch target byte
> - perform operation
> - write target byte
Not quite. The first cycle is the opcode fetch, and the second cycle is
decode, but since almost all instructions use at least one byte of operand,
it will fetch the next byte while it is decoding. If it doesn't need it,
it will just throw it away.
The index register is 8 bits, and the addition occurs while the high byte
of the address is being fetched. The carry is added in during the next
cycle.
1) Fetch opcode
2) Decode instruction, fetch address low byte
3) Add index to address low byte, fetch address high byte
4) Add carry to address high byte
5) Read
6) Perform operation
7) Write.
This seems a strange way to do things, but it does make sense. Consider
ADC #12
1) Fetch opcode
2) Decode instruction, fetch operand
3) Perform operation, fetch next opcode.
So while this instruction really takes 3 cycles, one overlaps with the next
instruction, so it looks like only 2. Primitive pipelining at work.
Also consider ORA 1234,X
1) Fetch opcode
2) Decode instruction, fetch address low byte
3) Add index to address low byte, fetch address high byte
4) Read
5) Perform operation, fetch next opcode.
If there was a carry, cycle 4 will be spent adding it to the address high
byte, and another cycle will be added to read from the correct address.
In most cases, there is no carry, and the instruction only takes 4 cycles.
This is why the 6502 is little-endian.
>Did RISC always mean leading edge performance, or was there ever a day
>when it meant reduced cost and complexity? The 6502 was obviously a
>'bang for the buck' design.
The ARM (the 6502's spiritual successor) is RISC by most people's
definition, and was designed to be cheap and low power.
John West
Brian Raiter
> Anyone remember what the price difference between the two was at any
> given time? Maybe I have some old mags...
I believe in 1983 the Z-80 was going for $4.95.
b
Geoffrey Welsh
wi...@ix.netcom.com(William H. Ivey) wrote:
>>It was a very sad day for me when I discovered that the 68000 also
>>used four-cycle memory accesses.
>The 68000 only accesses memory on one phase of the clock, as well.
>That's why the Amiga's video hardware DMA didn't have an impact on CPU
>throughput under normal circumstances - they were usually isolated from
>each other by the clock phase (using a high-res format with lots of
>hardware sprites WOULD start stealing CPU cycles). -Wm
Umm, I'm pretty sure about the four-cycle thingie, which pretty much
rules out 'other phase DMA'; I do recall 'chip memory' being slower
than 'fast memory' (memory out of the reach of the Amiga's multimedia
coprocessors).
Geoffrey Welsh
kor...@islay.ssl.berkeley.edu (Eric J. Korpela) wrote:
>Change that to instructions per second and you've got 166 to 500 kIPS.
>On a 4 MHz Z-80 instructions run 6 to 15 cycles so you get 267 to 667 kIPS.
>How does that make the Z-80 slower?
I hope that I didn't say that it was; I recognize that it was commonly
installed at much higher clock speeds (although I've seen 4 MHz
Commodore PETs and 10 MHz 6502s as auxilliary processors in Macs).
However, I stand by my statement that the 6502 was damned _efficient_.
Anyone remember what the price difference between the two was at any
given time? Maybe I have some old mags...
--
Geoffrey Welsh
jo...@ucc.gu.uwa.edu.au (John "West" McKenna) wrote:
>The index register is 8 bits, and the addition occurs while the high byte
>of the address is being fetched. The carry is added in during the next
>cycle.
Ah, I'd forgotten the explanation of the 'little-endian' approach.
>This seems a strange way to do things, but it does make sense.
Quite nifty, really!
Tim Shoppa
In article <50b9um$5...@eve.speakeasy.org>,
Brian Raiter <bri...@speakeasy.org> wrote:
>> Anyone remember what the price difference between the two was at any
>> given time? Maybe I have some old mags...
>
>
>b
At the time of introduction of the 6501, it was substantially
less than the competition (Intel's 8080A and Motorola's 6800). In
early 1975, 8080A's were about US$150. I seem to recall 6800's being
about $60-$80, the 6501 about $20, and the 6502 at $25, later in 1975.
These are all "to the hobbyist" prices; I have no idea what the prices
were if you were an OEM. I suspect Intel and Motorola had larger discounts
than MOS Technologies.
In late 1975 my KIM-1 (6502-based) cost $245 and my SWTP M6800
was $450. The Z-80 was still vaporware at the time - according to my
old Byte's, it wasn't available until Feb 1976.
Tim.
William H. Ivey
In <50alc6$q...@news.inforamp.net> crs...@inforamp.net (Geoffrey Welsh)
>>That's why the Amiga's video hardware DMA didn't have an impact on
>>CPU throughput under normal circumstances - they were usually
>>isolated from >each other by the clock phase (using a high-res format
>>with lots of hardware sprites WOULD start stealing CPU cycles). -Wm
>
>Umm, I'm pretty sure about the four-cycle thingie, which pretty much
>rules out 'other phase DMA'; I do recall 'chip memory' being slower
>than 'fast memory' (memory out of the reach of the Amiga's multimedia
>coprocessors).
I've got the hardware manual with the timing diagrams. Under normal
circumstances (usual display res, average hardware sprites, no fancy
sound, etc.) the CPU wasn't bothered by the hardware's DMA - it being
on the phase in which the 68000 just can't access memory. Chip memory
was potentially slower (under heavy DMA), but not always slower. (And
throughput wasn't impacted as much since the DMA was often performing
tasks the CPU couldn't perform as well in any case.)-Wm
Geoffrey Welsh
(e-mailed and posted to alt.folklore.computers)
bri...@speakeasy.org (Brian Raiter) wrote:
>> Anyone remember what the price difference between the two was at any
>> given time? Maybe I have some old mags...
>I believe in 1983 the Z-80 was going for $4.95.
I appreciate the info, but it doesn't really compare the two, which is
what I was after.
--
Geoffrey Welsh, MIS Co-ordinator, InSystems Technologies (gwe...@insystems.com)
At home: xenitec.on.ca!zswamp!geoff; Temporary: crs...@inforamp.net
ANYONE WHO SENDS ADVERTISING TO ANY OF THESE ADDRESSES MAY RECEIVE,
FREE OF CHARGE, A DAILY COPY OF WHATEVER LARGE FILES I CAN FIND...
Bill Marcum
I seem to recall that the 6502 was the first 8-bit CPU to sell for less
than $1 (or maybe it was $10) in large quantities.
--
Bill Marcum bma...@iglou.com
"Outside of a dog, a book is man's best friend. Inside a dog, it's too
dark to read." -- Marx (or was it Twain?)
Eric J. Korpela
In article <50alj8$r...@news.inforamp.net>,
Geoffrey Welsh <crs...@inforamp.net> wrote:
>
>I hope that I didn't say that it was; I recognize that it was commonly
>installed at much higher clock speeds (although I've seen 4 MHz
>Commodore PETs and 10 MHz 6502s as auxilliary processors in Macs).
And I've seen Z-80s running at 25 Mhz. At any time the Z-80 was always
capable of higher speeds.
>However, I stand by my statement that the 6502 was damned _efficient_.
But less so when you consider that the 2 clocks 90 degrees out of phase
meant that a 1 Mhz 6502 was actually running at 2 Mhz. Would you have
called the Z-80 efficient if the clock phase splitting was done outside the
processor?
I'm not knocking the 6502. I own more 6502 machines than I do Z-80
machines. But for most of the things I do, the Z-80s available in
1981 were faster than the 6502s.
Tom Watson
In article <50hmj1$r...@agate.berkeley.edu>, kor...@islay.ssl.berkeley.edu
(Eric J. Korpela) wrote:
<<<deletia>>>
> But less so when you consider that the 2 clocks 90 degrees out of phase
> meant that a 1 Mhz 6502 was actually running at 2 Mhz. Would you have
> called the Z-80 efficient if the clock phase splitting was done outside the
> processor?
>
The 6502 used only ONE clock as input. It generated two phases (180
degrees out of phase) as outputs.
The only microprocessor that used 90 degree clocks was the 6809 (Motorola)
and it had two versions. One generated the clock internally, the other
was given clocks. The latter (6809E) was used in the Radio Shack Color
Computer.
Been there, done that.
--
Tom Watson
t...@3do.com (Home: t...@johana.com)
J. Chris Hausler
Tom Watson <t...@3do.com> writes:
>The only microprocessor that used 90 degree clocks was the 6809 (Motorola)
>and it had two versions. One generated the clock internally, the other
>was given clocks. The latter (6809E) was used in the Radio Shack Color
>Computer.
90 degrees out of phase and non overlapping to boot!
>Been there, done that.
Been there, done that too!
Andy Rabagliati
J. Chris Hausler <jcha...@delphi.com> wrote:
>Let us not forget the original 6800 which required two external clocks
>90 degrees out of phase and non overlapping to boot!
Well, the 8080 used quadrature clocks like that, and they were not even
TTL-level signals.
A great thing about Zilog's Z80 was a single, TTL level clock.
Cheers, Andy!