On Sun, 19 Aug 2001, [iso-8859-1] Gonzalo Fernández wrote:
> > sure if I can explain it properly... when I position the players in
> > the first 30-40 pixels of the display, they appear to be shifted down
> > one scanline (my kernel is 2 scanlines per iteration, low res)... I
>
> It seems like you are updating the GRPx too late, after the cycle 68, maybe
> in 98-108 (68 clock counts for H Blank). You should take care of your cycle
> counting.
>
hrmmm... yep. My kernel looked like:
scan_loop:
sta WSYNC
sta HMOVE
;XXX
lda pfdata0,y
sta PF0
lda pfdata1,y
sta PF1
lda pfdata2,y
sta PF2
lda (spriteptr),y ; YYY
sta GRP0 ; YYY
lda (sprite0ptr),y ; YYY
sta GRP1 ; YYY
cpy evpos
bne skipenemy
lda #2
bne drawenemy
skipenemy:
lda #0
drawenemy:
sta ENAM1
sta HMCLR
sta WSYNC
dey
bne scan_loop
...and moving the lines of code marked with YYY, to the location marked
with XXX (right after HMOVE), fixes the player delay. However, now the
playfield is having the same problem... part of each scanline gets moved
down one `half-pixel'... I could live with this (the playfield is static),
but would like to actually fix it... probably I shouldn't be using
(indirect),y in the first place, but it makes life really easy, the
spriteptr and sprite0ptr point to areas of ROM with lots of zeros,
followed by the sprite data, followed by lots of zeros... and I calculate
an offset & store it in the zero page pointers' low bytes during the
VBLANK period...
>
> I think everybody is using DASM, if you don't use it you will need to change
> every code posted here to try it.
I'm currently in the process of porting. I just now (yesterday) found the
source to dasm and got it to compile on Linux (the link on Nick's page
takes you to the dasm site, but the link there for the Linux binary is
broken)...
Be seeing you...
B.
---
If a trainstation is the place where trains stop, what is a workstation?
-
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
