c64 asm d016 question
category: code [glöplog]
hi. c64. assembler. raster IS stable. i am in the lower border (#$f9) , d011 removal (integrated in the below example) works always flawless.
walk into a room and see dis:
dec $d016 ;6
sty $d016 ; y is #$c8 ;4
nop
nop
nop ... {loop}
wooo! border removed
but, why:
nop ; 2
stx $d016 ; x is #$c7 ; 4 (2+4 = 6, or is it?)
sty $d016 ; y is #$c8 ; 4
nop
nop
nop ... {loop}
*cries* no border removed.
as i see it, it is the *exact* same timing, and it does the exact same thing. but it doesnt. any clues?
walk into a room and see dis:
dec $d016 ;6
sty $d016 ; y is #$c8 ;4
nop
nop
nop ... {loop}
wooo! border removed
but, why:
nop ; 2
stx $d016 ; x is #$c7 ; 4 (2+4 = 6, or is it?)
sty $d016 ; y is #$c8 ; 4
nop
nop
nop ... {loop}
*cries* no border removed.
as i see it, it is the *exact* same timing, and it does the exact same thing. but it doesnt. any clues?
I guess it has to do with this:
http://www.csdb.dk/forums/index.php?roomid=11&topicid=76108&showallposts=1
http://www.csdb.dk/forums/index.php?roomid=11&topicid=76108&showallposts=1
Quote:
fetch the 0-sprite. with open borders...
hi,
ik have a little problem.. i want to open the sideborders with the 4 lowest sprites... i have two questions about it..
when i do the D016 write i use a dec d016 or a lsr or ror as opcode... why does a sty, sta, stx not work....
has it something to do with cpu takeover cycles at that point...
second question... what to do on a badline....
there are not enough free cycles. with 4 sprites for a inc, ror or lsr d016 instead of a sta, sty or stx...
i realize it is common knowledge.. but sorry i dont. know it...
bye...
Quote:
See this graph: In cycles marked with "X" (during takeover), writing is possible, reading not. RMW opcodes are special because their last *two* cycles are write-cycles. This way, you can still access the cycle yo need for opening the border. STA has just the final cycle as write cycle, that is not enough.
Ah! Thanks! Actually i sort of imagined that after about two days of stepping cycle by cycle around the last-char-gap. It just *seemed* as if the nop/stx combination would either take a cycle longer or, if corrected suddenly would take a cycle less.
So i guess it is not possible to have a full width x-expanded sprite scroller in the lower border with raster bars behind it that won´t show a 2-cycle wide update-gap? I believe, i have seen one demo so far that has a full border sprite scroller with rasterbars behind them, but i remember that it had the update-gap, too. By update gap i mean that you don´t have the time or space to hide the updating of the colors offscreen (left or right) because that space is used by the dec $d016 / sty $d016 combination.
Sad!
So i guess it is not possible to have a full width x-expanded sprite scroller in the lower border with raster bars behind it that won´t show a 2-cycle wide update-gap? I believe, i have seen one demo so far that has a full border sprite scroller with rasterbars behind them, but i remember that it had the update-gap, too. By update gap i mean that you don´t have the time or space to hide the updating of the colors offscreen (left or right) because that space is used by the dec $d016 / sty $d016 combination.
Sad!
badlinez! most stupid thing you can stumble into! thats why lots of code has like
anyway ;)
stupid shit!
try to put sth useful into those 6 cycles ;) thats a task no1 needs!
Code:
nop
nop
nop
nop
nop
nop
anyway ;)
stupid shit!
try to put sth useful into those 6 cycles ;) thats a task no1 needs!
ofcourse the nops were just used for explanatory purposes!
no time to waste! :-)
no time to waste! :-)