Subject: Re: Spectrum Emulator for C64

From: [email-masked] (Ian Collier)
Date: 20 Jun 1997 17:11:46 GMT

In article <[email-masked]>, "Alvin R. Albrecht" <[email-masked]> wrote:
>I agree but that doesn't mean the z80 isn't microcoded.  The biggest
>suggestion otherwise is the presence of undocumented instructions.

The biggest suggestion otherwise is the sentence in Tanenbaum's book on
computer architecture saying "The Z80 is not microcoded."  :-)
-- 
---- Ian Collier : [email-masked] : WWW page (including Spectrum section):
------ http://www.comlab.ox.ac.uk/oucl/users/ian.collier/imc.html

---

From: "Bruce R. McFarling" <[email-masked]>
Date: Sun, 22 Jun 1997 17:28:07 +1000

On Thu, 19 Jun 1997, Alvin R. Albrecht wrote:

> On Thu, 19 Jun 1997, Bruce R. McFarling wrote:
>...
> > 	OTOH, the reason that it is still being used today is because of
> > its efficiency. <4,000 gates leaves a hell of a lot of real estate on a
> > chip mask: plenty for ample ROM, a good chunk of RAM for some zero page
> > and stack page locations, a couple three special support circuits on the
> > level of a VIA.
 
> Efficiency?  Low gate count you mean.  The z80 is around because it is the
> favoured discrete choice for controllers.

	An efficiency is an output divided by an input.  As a core cell
for an ASIC, a chip that can do what the 65C02 can do in <4,000 is
efficient -- space efficiency, energy efficient, time efficient (the
smaller the processor core, the easier to work around it) etc.

	As far as the Z180, if you start making next gen comparisons, you
have to compare with the 65816 family.  Which is a 'whole other
discussion.

Virtually,

Bruce R. McFarling, Newcastle, NSW
[email-masked]

---

From: "Bruce R. McFarling" <[email-masked]>
Date: Sun, 22 Jun 1997 17:32:54 +1000

> computer architecture saying "The Z80 is not microcoded."  :-)

No, the Z80 is not microcoded.  Don't confuse the multi-phase
interface to the memory bus with a "decode opcode, execute microcode'
cycle.

Virtually,

---

From: [email-masked] (Stephen Judd)
Date: 24 Jun 1997 04:37:09 GMT

In article <[email-masked]>, Stephen Judd <[email-masked]> wrote:
>In article <[email-masked]>,
>Alvin R. Albrecht <[email-masked]> wrote:
>>There is 
>>a point of diminishing returns. In my experience, for
>
>Ah, an interesting point: what does your experience in these matters
>consist of?  That is, what kinds of programs have you written, and
>how large/involved were they?  Z80 assembly programs of course.

>>This
>>is your 4:1 number popping up if the z80 acts like a 6502.
>
>You just don't seem to get it: Bruce is saying, "Based on the

Ugggghhhh...

Well, for what it's worth, I actually don't give a flying rat's butt
about any experience, etc. and I think from now on I will try to just
stick to the technical side of things, and otherwise await your code
in textual silence.

Sigh... it's time for me to retreat from the verbal battlefront, I'm too
wound up in it.

-S

---

From: "Alvin R. Albrecht" <[email-masked]>
Date: Mon, 23 Jun 1997 19:37:50 -0600

On 21 Jun 1997, Stephen Judd wrote:

> >But how many subroutines that you write need all 256 registers?
 
> Sigh...

I think you miss the point.  Reflect on how useful it would be to have
more than one accumulator or even a couple of fast page 0 locations on
chip.  How many of your algorithms would save significant time by not
having to operate on slower memory so frequently?

If that doesn't convince you, reflect on how many modern day processors
use a page 0 like architecture and wonder why they are so rare.

> how large/involved were they?  Z80 assembly programs of course.

All for z80 controllers.  They have included:  simple
operating systems (streams, multitasking), simple interpretters, bitmap
display drivers and of course mundane hardware associated stuff (read
keypads, output a couple of bits to turn on relays, interrupt
handlers, etc.) All easily fit in 8k ROM.

> You just don't seem to get it: Bruce is saying, "Based on the

Actually, I think you've missed the point entirely.  Bruce made the claim
that tasks take anywhere from a 2:1 ratio in cycle times to 6:1.  What I
did was make the z80 behave like a 6502 to find out exactly what the worst
case could possibly be and it turned out to be ~4.2:1.  So you could
*never* get any cycle ratios greater than that.  His statement that the
average is 4:1 is having trouble proving itself.  If that is truly the
average, then it should be easy to come up with examples.  He gave an
excellent example:  the simultaneous 4 string compare, which is what he 
likely believed would demonstrate some huge cycle ratios, but it turned
out to be ~2.6:1.  He could easily extend that to 8 strings, 10 strings or
whatever, but I then suggested that it would be profitable to switch to a
deterministic automaton to compare the strings.  Then you'd see a return
to ~2:1 ratios.  If you didn't want to switch to an automaton just for a
thought exercise, then you'd probably see something approach 3:1 when
I'd start using the stack to save pointers.

> general experience from a wide variety of people who spent a lot 
> of time programming both architechtures, the general rule was 4:1".

I'm not one for celebrity endorsements (sorry Bruce :).  Even the biggest
geniuses on the planet make mistakes.  It is entirely possible that Bruce
was surrounded by a lot of talented 6502 programmers and less talented z80
programmers.  He has already made one mistake by suggesting cycle ratios
go up to 6:1.

One other thing:  this is not a prevalent attitude among all engineers.

> This is very different from your "Based on a few glaces at a spec
> sheet and these simple examples and thought problems which exactly
> prove my point, it's clear that the Z80 ought to be <2:1".
> (How very Aristotelian of you!)

:-)  A little more effective than "Oh dear; sigh; Let's reprint this and
reflect on the wisdom" - all indications that either you can't come up
with an argument against or are too closed-minded to attempt to expand
your understanding through considering another's arguments. This may not
describe you personally, but that's what it makes you look like when you
use these ineffective psychological tools.

Actually, my arguments are based on:

- the most time consuming algorithms use few variables (be they memory 
pointers or not) that can normally be held in the z80's registers (when
this is done, slightly <2:1).
- most data structures can be organized to be accessed sequentially in
memory.  In this case, I can use either the stack (~1:1 ratio when
compared to 6502 lda/sta to zero page) or HL as a pointer (lda d,x; inx
<-> ld a,(hl); inc l = ~1.6:1)
- in large data structures such as arrays, the z80 also carries an
advantage as it can calculate 16 bit addresses of random array elements
much quicker than a 6502.
- when a small table is needed (<256 bytes), in random access, the ratio
is <2:1.
- when a large table is needed (>256 bytes), the ratios dip further below
2:1 (I assume you need some self-modifying code here or maybe a double
table lookup)
- the z80 has a clear advantage in recursive algorithms.

These things probably don't mean much to you, but the following may:

- All the inherent 6502 instructions have z80 counterparts and they occur
in 2:1 ratios.
- The 6502's page 0 can be emulated on a z80 at a maximum ~4.2:1 ratio and
most of the time in the range 2.2:1 to 2.8:1.
- Z80 programmers don't write programs that way because it's quicker
to formulate algorithms in other ways.
- the opinion that cycle ratios occur on average at 4:1 is not the general
opinion of all engineers.

> It is also, of course, different from my "Based on a few glances
> at a spec sheet and my experience in writing substantial programs
> and algorithms, I expect between 3:1 and 4:1, so lets write some
> code to see what's what".

It's fine to write some code and compare, but there are millions of
problems out there and if you can't generalize some problems, you'll never
reach a conclusion.

Alvin

---

From: [email-masked] (Stephen Judd)
Date: 25 Jun 1997 14:51:21 GMT

In article <[email-masked]>,
Alvin R. Albrecht <[email-masked]> wrote:

133 lines of blahtext.

Less talk, more code.

-S

>use these ineffective psychological tools.

Could be, could be...

>problems out there and if you can't generalize some problems, you'll never

Right on, brother.

---

From: "Alvin R. Albrecht" <[email-masked]>
Date: Mon, 23 Jun 1997 18:10:17 -0600

> smaller the processor core, the easier to work around it) etc.

No argument there.  This isn't in dispute: I'd end up using a 6502 on an
ASIC as well if I ever needed an 8bit uP.
 
> have to compare with the 65816 family.  Which is a 'whole other

Yes, 'tis.  I just wanted to offer a reason for the missing 40MHz z80:
there's no point.  A 20MHz 6502 is great, especially as part of an ASIC.
A 40MHz z80 really isn't necessary because as a controller you don't need
that speed.  In more complex applications you really should be using a
z180 or z380 instead - which are built for speed and offer a lot of other
useful features.

If you want to convince me that the max clock ratios are not 2:1 using the
same device geometries, you have to explain this history:

z80 : 2MHz, 4MHz, 6MHz, 8MHz
6502: 1MHz, 2MHz, 3MHz, 4MHz

Alvin

---

From: "Bruce R. McFarling" <[email-masked]>
Date: Thu, 26 Jun 1997 14:39:39 +1000

On Mon, 23 Jun 1997, Alvin R. Albrecht wrote:

[quoth I]

> z180 or z380 instead - which are built for speed and offer a lot of other

	Also for the 6502 instruction set, you gain a lot with a little
fast memory (data and shadow ROM), even if devices are accessed at a
slower rate.  Access to a memory mapped I/O device address will typically
be interspersed fairly evenly with instruction and data memory accesses,
so a small, fast SRAM and a 6502 can get a lot out of a lower speed I/O
chip with clock stretching.  Isn't the Z80 approach more to add wait
states to let the processor take advantage of opporuntities on offer 
to outrun the memory/device bus cycle (when doing all that internal
register operations that give the Z80 its advantages)?

> 6502: 1MHz, 2MHz, 3MHz, 4MHz

	When max clock rations where constrained by DRAM access speed, the
2:1 processor clock is informative: that's an upshot of the different
memory bus designs of the processor. The 6502 is direct clocked to the
memory bus. That's why there aren't any such things as 'wait states' for a
6502 -- and why the fully static design of the 65C02 is such a big deal: 
you bus the 65C02 to different speed of access memories (or I/O chips) by
running it at the speed of the fastest, and stretching the low of the
processor clock when it is necessary to avoid outrunning the slow clock. 
This is something that is done by an external (or 'seperate' for an ASIC,
I guess) chip(s). 

	The 4:1 ration was directed at something else. It was a rule of
thumb that if you built a 6502 system with 1/4 the processor clock rate,
you'd get the same general throughput.  Remembering that the Apple I was a
kit computer and so were the early S-100 bus computers, a lot of this is
low level stuff: assemblers, text editors, Basic interpreters, software
cassette I/O control, etc.  The current question was, I took it, whether
this still holds for the type of throughput that these processor would be
asked to provide today in a hobbyist setting.

	Historically, the 6502 got into the Apple II, which got a
spreadsheet and from then on turned into a software driven market, and the
competing computer / game machines that were programmed with an awful lot
of expectation that one would be the same as the next.  When the Apple III
got in trouble, and Commodore winning the computer / game machine wars
with a price and mass market strategy[*] the Z80 machines caught up in
troughput due to being more open systems.  That meant better development
environment, more code (hence solution) sharing, ability to accomodate
processor speed improvements as soon as they became available, etc.  The
C128 would have contributed to that, if they had run it off the dot clock
at 8MHz, but getting the interaction with the 2MHz parts on the
motherboard (and are some of them 1MHz parts?) was complicated, so the
C128 was crippled on its CP/M side to begin with. It would have been
better if they introduced a cartridge that ran off the dot clock at 8MHz
with its own memory (and could plug into either the C64 or the 128 -- that
would have been the ticket) with DMA memory transfers and the C128
handling I/O jobs. 

Virtually,

[*] Sorry if my economics profession slips through here somewhere.

---

From: "Bruce R. McFarling" <[email-masked]>
Date: Thu, 26 Jun 1997 15:15:23 +1000

> use a page 0 like architecture and wonder why they are so rare.

	A lot of modern day architectures use a page 0 like instruction
set.  They're called RISC chips.  Of course, the equivalent of page 0 is
the register bank on a RISC, but you forget that the 6502 design is
clocked directly to the memory bus if you think that costs as much as all
that.  When the 6502 instruction set lets you specify exactly what you
intend to do, it's not a major slowdown

	LDA zp

	External 0 page		Internal 0 page

	fetch op		fetch op
	fetch zp, parse op	fetch zp, parse op
	load A from (zp)	load A from (zp) and fetch next op

	3:2

	LDA zp,X

	External 0 page		Internal 0 page

	fetch op		fetch op
	fetch zp, parse op	fetch zp, parse op
	index zp+X		index zp+X
	load A from (zp)	load A from (zp) and fetch next op

	4:3

	LDA (zp,X)

	External 0 page		Internal 0 page

	fetch op		fetch op
	fetch zp, parse op	fetch zp, parse op
	index zp+X		index zp+X
	fetch addlo from zp+X	fetch addlo from zp,x
	fetch addhi from zp+x+1	fetch addlo from zp+x+1
	load A from addlo,addhi	load A from addlo,addhi and fetch next op

	6:5

	It's a fairly constant 1 cycle overhead, which must be balanced
against opportunities to retain data on the zero page and work with them
directly there, rather than accessing them with the 4+ cycles required to
load them to a register with the 3 byte "lda addrlo addrhi" type
instruction, and the RISC-like facility of using the zp locations as an
X-indexed stack.

> I'd start using the stack to save pointers.

	The point here is that this ~2.6:1 is not the savings, because I
didn't present an example, I just presented an inner loop.  If they are
strings averaging 90 bytes in length, the data manipulation overhead
starts to vanish.  If they are strings that are three bytes in length, the
extra data manipulation overhead from not working with the information in
place raises its head again.  If, as in ACE, you have 126 bytes of zero
page available for the application, you can set up 12 bytes of pointers to
significant strings and leave them there.  In the Z80, you have to go and
get them and work with them, pushing down the throughput.  And the same
goes when you work with them and have to restore the values to memory
later so that the registers can be used for another purpose.

> programmers.  He has already made one mistake by suggesting cycle ratios

	My impression is that cycle ratios do go up to 6:1.  I assume that
is for BCD math (the 6502 *was* originally designed under the cover
of being a calculator chip, after all!).  So why don't the 6502 and Z80
assembly language programmers program:

	A 16 digit accuracy Addition
	A 16 digit accuracy Subtraction
	A 32 digit accuracy unsigned 16-digit by 16-digit multiply.

Add up the clocks and see where the ratios lie.  I seem to be less
committed to the 4:1 ratio than some other protagonists in the debate seem
to be (!).  It may well be that an experienced Z80 programmer and an
experienced 6502 programmer will arrive at different ratios than were
commonly experienced in the late 70's, simply because we know more about
programming these little buggers in the late 70's.  And it may well be
that the mix of processing tasks has changed.

	I could go on at this point to point out what I hink *are* the
weakness of the 65C02 instruction set as an 8-bit chip (that is, leaving
out the next-generation 65816 type approach), but I've written too much
already.

Virtually,

---

From: [email-masked] (Cookie)
Date: 27 Jun 1997 14:54:22 GMT

Alvin R. Albrecht ([email-masked]) wrote:
: If that doesn't convince you, reflect on how many modern day processors
: use a page 0 like architecture and wonder why they are so rare.

Perhaps because there's not much use for it on register-rich processors?

Simon

---

From: "Bruce R. McFarling" <[email-masked]>
Date: Mon, 30 Jun 1997 12:47:57 +1000

> Perhaps because there's not much use for it on register-rich processors?

	Because the problem that it is a solution to is fitting an
instruction set into the 256 available values in an 8-bit code (AFAIR, the
Z80 uses more, based on special prefixing opcodes that extend the
instruction set).  For the problem that this is a solution to -- fitting
inexpensive processing power to an inexpensive memory bus -- the 65816
family fills the bill nicely.  If you want to crank up the mips, you 
have to go for more parallism, either by multiplying the processors
or widening the bus / instruction width, and you pay for what you get.

Virtually,

---

From: David Spence <[email-masked]>
Date: Sun, 29 Jun 1997 23:24:13 +0100

I'm new to this stuff, but how could anyone try to emulate a Speccy 
on a C64? , and WHY????          All the C64 game/software designers 
of the eightys tried and failed.

If you can't beat it, try to copy it.    (Commodore Users Motto)

DBS