Subject: Re: Spectrum Emulator for C64

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

On Wed, 25 Jun 1997, Geoff wrote:

>  Greg King wrote in article <[email-masked]>...
> >"Relocatable" means that the stack's DOMAIN can be moved.
> [snip
> ]
> >The Z80, on the other hand, runs its stack from 0000h all the way to
> >0FFFFh, so it doesn't need to be relocatable!
> 
> The z80 stack pointer can be moved at any time by any program - which
> means that you can have more than one stack domain: if you know (for
> example) that an interrupt routine is going to use 32 bytes of stack you
> can put it in a particular piece of memory to avoid overwriting other
> people's use of the stack, then put it back when you return. Thus
> effectively changing the stack domain.

	So can the 6502 stack.  Since a Forth program doesn't need
anywhere near 256 bytes of return stack, you can use that to support 4 or
more multi-tasking Forth processes.

Virtually,

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

---

From: "Bruce R. McFarling" <[email-masked]>
Date: Mon, 30 Jun 1997 13:23:45 +1000

On 27 Jun 1997, Spike wrote:

> Bruce R. McFarling ([email-masked]) wrote:
> : 	So can the 6502 stack.  Since a Forth program doesn't need
> : anywhere near 256 bytes of return stack, you can use that to support 4 or
> : more multi-tasking Forth processes.
> 
> Ahhhh, but the Z80 doesn't have a memory limit on the size of stack.
> You could quite easily have a stack 20K in size, if you wanted.....

	Why would you want, unless you were using a language with an
inefficient stack frame approach? 8-)# Obviously the 6502 assembly
language programmer does not use the stack pointer for all the different
things that the Z80 used the stack pointer for, but restricts it for
mostly hardware stack usage, and uses the zero page to hold vectors for
larger stack frames.
	BTW, how well does the stack pointer work at fetching an array in
ravel order when you use a ladder approach and perform transposes or
reverses by modifying the i, j, or k increment and first address location,
instead of by manipulating the array data?  I'm still on the trail of the
throughput advantage that was thought to be the case in the late 70's /
early 80's.  Current list of suspects: 

	- applications relying on scattered memory references involve
register loading / restoring overhead in the Z80, maintained in place on
the zero-page in the 6502.  This is an inner-loop / outer-loop problem,
so the question is whether inner loops are / were short or long
	- Early on there was an incentive to write vanilla CP/M code,
which means within the limitations of the 8080. How much better throughput
does the Z80 have compared to the 8080?  Is the roughly 4:1 comparison a
6502 vs 8080 comparison that was applied to the Z80 before it was well
understood how much the Z80 added to the mix? If that was the case, what
divider would you apply to the 4 in the 4:1?
	- Z80 code that is relocatable can not be efficiently performed in
the 6502, but will there be a speed savings in the jump-table version?  Of
course, there's a 6502 / 65C02 discrepency here, in that you can vector
the jump table in the 65C02 with the JMP (absolute,X) instruction
	- there's the polish (soft o, not hard o) question: with the
hardware layouts of 6502 based machines more set in place precisely
*because* of the redirection limitations of the 6502, was there more
optimized-to-the-last-cycle assembler code for the 6502?  Certainly the
action in the mid-80's seemed to be more in migrating Z80 code to the
8086, while the action on the 6502 side was in expanding capabilities
within the hardware limitations of the millions of C64's being sold.

	I don't know how to write a 16-bit BCD addition for the Z80, and
am not about to learn how to add the cycles (T cycles? M cycles?  What's
the diff?).  Just write one up: two positive numbers (it's sensible to
assume that the calling routine will know where the sign information is
and determine whether to find the sum or the difference and handle the
sign of the result): one at a fixed, 8-byte location in memory (either
order), the other at an 8-byte location referred to in register
(specifiable), the result returned in the fixed location.  Fair game to
send the length of the operand and retain the length of the result
somewhere.  How does it look and how many cycles does it take?

Virtually,

---

From: "Geoff" <[email-masked]>
Date: Fri, 4 Jul 1997 17:19:30 +0100

Ian Collier wrote in article <[email-masked]>...
>Unless you happen to have written a recursive program.  They can be
quite
>useful sometimes, you know.

Rarely. Haven't yet seen a recursive program that couldn't be written
iteratively. Funnily enough, there's no such thing :)

Personally I always found iteration easier to understand, too... and it
tends to use up less memory aswell.

Geoff

---

From: [email-masked] (Ian Collier)
Date: 7 Jul 1997 13:35:46 GMT

In article <[email-masked]>, "Alvin R. Albrecht" <[email-masked]> wrote:
>Try solving the Towers of Hanoi problem without recursion directly and
>without resorting to writing an iterative version of the easily formulated
>recursive version.

An interesting problem.  The following algorithm might make a good IOCCC
entry...

for i = 1 to 2^N-1
   for j = N-1 to 0 step -1: if (i AND 2^j) = ((i-1) AND 2^j) then next j
   print "Move disk ";j+1;
   if ((j XOR N) AND 1) = 1 then print " left" else print " right"
next i

(where disk 1 is the smallest, "right" means A->B->C->A and "left" means
C->B->A->C).
-- 
---- Ian Collier : [email-masked] : WWW page (including Spectrum section):
------ http://www.comlab.ox.ac.uk/oucl/users/ian.collier/imc.html

---

From: [email-masked] (Stephen Judd)
Date: 9 Jul 1997 04:16:32 GMT

In article <[email-masked]>,
Bruce R. McFarling <[email-masked]> wrote:
>On Sun, 6 Jul 1997, Alvin R. Albrecht wrote:
>
>> ...
>> This kind of problem where:
>> - There are few variables (index, one var for add)
>> - There are a lot of memory references to a table
>> - There are a lot of branches (not in this example)
>> is where the 6502 will do well against a z80.
>> 
>> Needless to say, this doesn't include the lion's share of problems by far.
>
>	Rather 'many' than 'few' variables.  Having few enough variables
>that they can be maintained in the Z80 register set without shuffling is
>an *advantage* for the 6502.
  dis

or

			Z80

:)

-S