pouët.net

Go to bottom

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?

added on the 2012-07-20 12:14:58 by wertstahl wertstahl
I guess it has to do with this:

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.
added on the 2012-07-20 12:29:32 by hollowman hollowman
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!
added on the 2012-07-20 12:38:55 by wertstahl wertstahl
badlinez! most stupid thing you can stumble into! thats why lots of code has like
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! :-)
added on the 2012-07-22 02:09:56 by wertstahl wertstahl

login

Go to top