Not "for some reason"...wasting 33 cycles pushed the enable/disable code to the non-visible portion of the next scanline (which will become a problem if sprites need to be drawn on the same scanline). As mentioned before, you can prepare some of the conditions beforehand. Stuff like reading the console switches within the kernel to use different colors takes up valuable time you need to actually draw the screen. If conditions absolutely need to be checked per scanline (such as a missile enable), that too can be checked using free cycles from a previous scanline, and then called later from temp ram. Just like what was done with COLUP0.
. sta WSYNC stx GRP0 ;3 sta GRP1 ;6 lda $88 ;9 sta COLUP0 ;12 lda $A9 ;15 cpy $A8 ;18 beq DrawM1 ;20 lda #0 ;22 DrawM1: ;21 sta ENAM1 ;24-25
The visible portion of the screen begins at cycle 22...so that code will produce a crooked missile if it is on the far left.
. lda $A9 ; cpy $A8 ; beq DrawM1 ; lda #0 ; DrawM1: sta Temp ; sta WSYNC stx GRP0 ;3 sta GRP1 ;6 lda $88 ;9 sta COLUP0 ;12 lda Temp ;15 sta ENAM1 ;18
Cycle 18 is just fine. You'll still need to fill in the missing cycle times for the code leading up to the WSYNC to make sure you don't go over 73 (or 76 if you use cycle-exact branching to skip using WSYNC). Since you are using A for GRP1, that code will need to go between storing Temp and WSYNC.
But there usually is not time to be throwing all your stuff in temp ram for later. That is where the vertical delay registers become useful. By enabling them, sprites stored to one register will not be updated onscreen until sprites from the other register is written to. So then it won't matter what cycle you write the delayed sprites, the change won't be onscreen immediately.
Edited by Nukey Shay, Sun Feb 26, 2017 7:45 AM.