Re: coding the Z80 and 6510
                                       
   From: w_gayk@NOSPAMbielefeld.netsurf.de (Brix)
   Reply to: Brix
   Date: Tue, 3 Nov 1998 21:13:53 +0100
   Organization: [Customers of] IS Internet Services GmbH & Co, Hamburg
   References:
          <Pine.OSF.3.91.981021114642.2334B-100000@cpcw1.uea.ac.uk> 
          <70r5ec$8jp$17@newsreader1.core.theplanet.net> 
          <3635b416.21822437@news.telepac.pt> 
          <MPG.10a2d97aba2f5242989722@news.uni-x.net> 
          <16476-agent.imc@comlab.ox.ac.uk> 
          <MPG.10a526788e4c1899989738@news.uni-x.net> 
          <71fo4o$oe9@cpca3.uea.ac.uk> 
          <Pine.LNX.3.95.981031221758.409A-100000@menaxus.demon.co.uk> 
          <71g5m3$os2@cpca3.uea.ac.uk>
> The Amstrad equivalent here is 12 NOPs setup and 6/5 for each LDIR. Making a
> total of 1541 NOPs, which at 4Mhz is 1541us and *almost* as fast as the
> speccy version.

What's your definition of NOP?

In 6510-Assembler NOP is short for NO oPreation. Which means, that this opcode
does what
it claims to do: NOTHING. Just good for timing and delaying things.

> Well, I posted a challenge to produce a sprite routine elsewhere. I
> *suspect* a speccy version would be faster, although the display layout on
> the CPC might just go in our favour. :)

Sprites?
Hard to compare.
Let's say my GFX-data for the sprite is at 2000h-2040h in memory. (I'm using th
e PC
coders' display of hex numbers here.. on the C64 you'd say $2000 - $2040).

Now I just need to do this:

lda #$01   (activate sprite 1 of 8 [$01 = %00000001]
sta $d015
lda #$80   (set sprite adress to $2000 [$2000/$40 = $80])
sta $07f8
lda #xposition
sta $d000
lda #yposition
sta $d001
lda #color
sta $d027

an lda #byte costs 2 cycles, an sta $adress cost 4 cycles.
This is a total of 30 cycles to activate and set position of a usual hires-Spri
te.
setting a new position can be done in 12 cycles:
ldx #xposition  (2 cycs)
ldy #yposition  (2 cycs)
stx $d000       (4 cycs)
sty $d001       (4 cycs)

or:

lda #xposition  (2 cycs)
sta $d000       (4 cycs)
lda #yposition  (2 cycs)
sta $d001       (4 cycs)

Now, let's move a hires sprite with a kind of sinus-table ok?
Of course in X and Y direction!

(Sprites GFX-Data are in Memory from $2000 - $2040)
------------------------------

[this is the sprite-init]

lda #$01   (activate sprite 1 of 8 [$01 = %00000001]
sta $d015
lda #$80   (set sprite adress to $2000 [$2000/$40 = $80])
sta $07f8
lda #color (set sprite color)
sta $d027

[so far we had 18cycles to set color and activate sprite]
[now let's go for the movement:]

      ldx #$00             (2 cycls)-set x register to $00
.loop lda xsinustable,x    (5 cycls)-load xtable(x indexed)
      sta $d000            (4 cycls)-set xposition
      lda ysinustable,x    (5 cycls)-load ytable(x indexed)
      sta $d001            (4 cycls)-set yposition
      inx                  (2 cycls)-increase x register
      jmp loop             (3 cycls)-jump to loop

.xsinustable $50,$50,$50,$51,$51,$52,$52,$53,..... (total of $256 bytes)
.ysinustable $40,$40,$40,$41,$41,$42,$42,$43,..... (total of $256 bytes)

---------------

Of course this routine looks shitty, because it is way too fast to look good.
You have to delay it a lot or syncronize it with the screen-refresh.

> Some more challenges would be nice though.

Yo.
Why not go for a usual 1x1 scroll-routine (8x8pixel charset) ?

-Brix/Plush-