| |
Six
Registered: Apr 2002
Posts: 287 |
Open Sideborder on badline with sprites 4-7
$d015 = #$f0
On the row just before the char row, I open the sideborder.
Next line is a badline with 4 sprites on it. I open the sideborder by dec $d016/inc $d016.
IMMEDIATELY after the dec/inc, I put another dec/inc. Problem is, it seems to fire too late. changing $d016 to $d021/$d020, I can see the second inc finalizes about 3 cycles into the border. I thought maybe it was because INC/DEC is RMW, so I switched to STA/STY, but that seems to fire one or two cycles too late.
Can anyone shed some light? It seems like I should have time to open the border here, I know it's been done. |
|
| |
tlr
Registered: Sep 2003
Posts: 1702 |
sta <abs>,x/sty perhaps? |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Guess only 4-cycle-store commands will work.
I'll try to shed light by writing down the cycles of each relevant rasterline
rasline = 7 (the one before the badline)
to open sb, we need $d016-write exactly @cycle #56 of this line. This line is not a badline, so we have the time to do
DEC $D016 = 6 cycles (R1+R2+R3+R4+W1+W2)
The correct value is available only on last write cycle, thus
rasline-cycle# 51 52 53 54 55 56 57 58 59 60 61 62
opcode-cycle# R1 R2 R3 R4 W1 W2 - - - - - X
Now the INC $D016 will occupy rasline-cycles 57-62; mind that this only works as also INC $D016 is a RMW-command thus having a write cycle exactly @rasline-cycle #62, which is a "X"-cycles that only allows for write-cycles!
Now the badline begins as follows
rasline-cycle# 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14
"cpu-view" X X 4 S 5 S 6 S 7 S - X X X =
rasline-cycle# 15 16 ... 52 53 54 55 56 57 58 59 60 61 62
"cpu-view" = = ... = = - - - - - - - - X
The next DEC $D016 again consists of R+R+R+R+W+W cycles. The first 'R' will processed @cycle #10 of the badline, the next 3 'R' cycles @rasline-cycles #54-56, the 'W'-cycles at 57 and 58 resp. This shows that the second 'W'-cycle does not meet cycle #56 (as needed for opening the sideborder) bit comes two cycles too late. Using a 4-cycle R+R+R+W-command gladly comes to the rescue here ;)
Maybe this helps a little. |
| |
Perplex
Registered: Feb 2009
Posts: 254 |
The tip from tlr (sta abs,x) is indeed the way to go, since you have only 1 spare cycle between two writes:
ldx #$00
ldy #$C0
lda #$C8
...
sty $D016 : sta $D016
<waste 44 cycles>
sty $D016 : sta $D016,x ; Bad line right after this
sty $D016 : sta $D016
<waste 44 cycles>
sty $D016 : sta $D016
... |
| |
Six
Registered: Apr 2002
Posts: 287 |
I'll try this. Thank you guys so much for the input, I understand something now about how the VIC and CPU interact that was escaping me before. |
| |
Six
Registered: Apr 2002
Posts: 287 |
Followup, MASSIVE thank you to all of you who chimed in on this. I've got it working finally - going to be an interesting task making it work on both PAL and NTSC. Thanks to Copyfault, I now understand fully why it works that way, and tlr and Perplex for a working example. I fought with the timing on this for 3 days, never understanding just WHY it wouldn't work until today. |
| |
Flavioweb
Registered: Nov 2011
Posts: 442 |
To make it work on all archs, you just need a code to detect on what arch is executed, then change some bytes of opcodes to use the right amount of cycles in the right place.
And if you use a "reverse counter" to stabilize irq, you need to adjust the countdown as well...
Another interting thing should be keep border open with your sprites moving from "before" to "after" the open border area...
=P |
| |
theWizard
Account closed
Registered: Jul 2007
Posts: 109 |
if you put a sprite on a raster line at the correct timing it will open the border to the size of the sprite no need to use a bad line , that will solve your timing issue.. ( i done this years ago ) you can also do it by using d011 bit 3 but then you will have to time for sprites as they will cause undesired effects across the y of the raster.
also if you do it from 0 to f2 there will be no border at all and you could even pixel the sprites and have full screen with no border , you will have to make a simple plexor though.
it works on a real 64 dunno about vice or ccs. |
| |
Scan
Registered: Dec 2015
Posts: 110 |
Quote: To make it work on all archs, you just need a code to detect on what arch is executed, then change some bytes of opcodes to use the right amount of cycles in the right place.
And if you use a "reverse counter" to stabilize irq, you need to adjust the countdown as well...
Another interting thing should be keep border open with your sprites moving from "before" to "after" the open border area...
=P
Maybe in future projects this might be helpful: Victimer |
| |
Scan
Registered: Dec 2015
Posts: 110 |
Quoted wrong post, beer goggles :P |
