| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Timing rasters with sprites over
I am gone stuck in trying to get some rasters be stable under some sprites.
There are 8 sprites, not moving.
Here's what I have:
color .byte 0,6,14,1,14,6,0,14
timer .byte 4,3,5,5,10,4,5,1
ldy #4
_swap dey
bne _swap
ldx #0
_doit lda color,x
sta d020
sta d021
ldy timer,x
_wrap dey
bne _wrap
inx
cpx #8
bne _doit
I've never learned about the badlines, is it
something with that, if i wanna time these rasters ?
Thanks
|
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11354 |
first of all unroll the whole thing, do not use a loop for timing (use nops or whatever instead) and start with doing some rasters without sprites that way. (do more than 8 lines so you use badlines too) then put one sprite on top, correct the timing (and see how it changes) and repeat with more sprites. eventually you will learn that you want to use fld or some other trick to get rid of the badlines :) |
| |
MRT
Account closed
Registered: Sep 2005
Posts: 149 |
You should avoid badlines with 8 sprites at the same time.
A normal badline takes up 40 cc, leaving you with 23 cc on a PAL system.
Now when you use sprites, a sprite takes off 4 cc per sprite. Except for sprite 0, because the VIC can fetch the first cc of that sprite within VIC resources.
So, calculate: (4 * 8) - 1 = 31 cc
So, for sprites on a badline:
31 cc + 40 cc = 71 cc
This concludes that you don't have any time left on a badline with 8 sprites.
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
@MRT: Are u stoned? =D
Anyways, here are the correct numbers:
Sprites take (simplified) 1 to 3 + 2*n cycles.
So, on a badline + 8 sprites you waste 40+3+2*8 cycles = 59 cycles. Using RMW instructions you can get back two of those 3 cycles. So, at least 57 cycles is taken by the VIC, leaving at most 6 cycles over of doing some nice raster bars. Problem is that this 6 cycle hole is located kinda bad for you.
Also, MRT. Listen to your reasoning. You actually prove for yourself that you can't have all 8 sprites active on a badline. Ever seen 8 sprites in normal simple basic programs? I have for sure. :D
|
| |
MRT
Account closed
Registered: Sep 2005
Posts: 149 |
Hmm, yes... It must be the smoke I just had... :-)
But then, isn't the following snipplet correct?
6567R56A, Bad Line, sprites 5-7 active in this line, sprite 0 in the next
line (abbreviated):
Cycl-# 6 1 1 1 1 1 1 1 1 1 1 |5 5 5 5 5 5 5 6 6 6 6 6
4 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 |3 4 5 6 7 8 9 0 1 2 3 4 1
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _| _ _ _ _ _ _ _ _ _ _ _ _ _
ø0 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ _ _ _ _ _ _
__ |
IRQ ______________________________________|__________________________
____ __ | __ __________
BA __________________ ________________|____ __________
_ _ _ _ _ _ _ _ _ | _ _ _ _ _ _ _ _ _
AEC _ _ _ _ _ _____________ _ _ _ __________|_____ _ _ _ _____ _ _ _ _
|
VIC i 3 i 4 i 5sss6sss7sssr r r r rcgcgcgcgc|gcgcg i i i 0sss1 i 2 i 3
6510 x x X X X x X X X | x X X X x x x x x
|
Graph. |===========0102030|7383940===========
|
X coo. \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\|\\\\\\\\\\\\\\\\\\\\\\\\\\
1111111111111111111111111110000000000000|11111111111111111111111111
999aaaabbbbccccddddeeeeffff0000111122223|3444455556666777788889999a
48c048c048c048c048c048c048c048c048c048c0|c048c048c048c048c048c048c0
snipplet from "The MOS 6567/6569 video controller (VIC-II) and its application in the Commodore 64" by Christian Bauer
http://www.minet.uni-jena.de/~andreasg/c64/vic_artikel/vic_arti..
It looks like this article assumes 4 cc for every sprite...
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
@MRT: Yes. But read carefully. The bus is clocked in 2 (TWO) MHz. Half of the cycles for the VIC and half of the cycles for the CPU. So, when the VIC "steals" cycles from the CPU, it steals the 1 MHz cycles from CPU. Hence, yes a sprite takes 4 2 Mhz cycles. But the CPU would in any case only have had 2 of those, so from the CPU's point of view it looses 2 1Mhz cycles.
Also please notice in the above picture that the 6502's cycles are represented at the top, every second 2Mhz cycle. |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Ok, with the help of a nice guy, I got stable rasters under sprites.
But there is a problem.
I get some garbage gfx, it looks like D020 color appearing in D021 area, or $3fff issues.
I cleared $3fff, but it had no effect..
The color of this garbage gfx is set nowhere by me.
? |
| |
HCL
Registered: Feb 2003
Posts: 727 |
If you didn't put the garbage gfx, it wouldn't be there >:). Sounds like perhaps you're doing..
lda color
sta $d020
sta $d021
..a bit too late in your "loop". It's not possible to get a 100% bugfree raster with random sprites on top. You will always see some bugs in the outermost borders. However, the d021-area does not need to get buggy. Just check the demos from 1988-89.. full of stuff like that :).
|
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
The buggy gfx changes when i change the timing.
It has color lightgreen, and my rasters are blue (0,6,14,1,14,6,0). The sprites are red/white.
It looks a lot like that D020/3fff trick you can do in the border to make 9 sprites.
|
| |
MRT
Account closed
Registered: Sep 2005
Posts: 149 |
Are you blocking badlines by altering $d011?
Because it sounds to me like you're filling the first 3 bits of $d011 with the first 3 bits of $d012. And thereby triggering a badline, showing the FLI bug on your screen...
|
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
I do:
lda $d012
and #%00000111
ora #%00011000
sta $d011
lda rastercolors,x
sta $d020
sta $d021
nop
...
|
| |
MRT
Account closed
Registered: Sep 2005
Posts: 149 |
Well, there's your problem.
You're generating a bad-line when you set your raster colors.
Try this:
(this code takes 2 cc more!)
lda $d012
sbc #$03 ;no need for sec
and #%00000111
ora #%00011000
sta $d011
If you can't handle the 2 extra clockcycles then try the following timing trick:
(using example values below)
on rasterline 40, do:
lda $d012
then go to next rasterline in the following two lines of code
and #%00000111
ora #%00011000
on rasterline 41, do:
sta $d012
|
| |
MRT
Account closed
Registered: Sep 2005
Posts: 149 |
Or even easier...
Try this:
lda $d012
and #%00000111
eor #%00011100
sta $d011
This takes exactly the same amount of cycles as your own routine, but makes sure that the first 3 bits of $d012 and $d011 aren't the same! (and therefore don't create a badline) |
| |
Hein
Registered: Apr 2004
Posts: 942 |
or try a $d011 table, filled with goody goodlines.
lda nobad,x
sta $d011
lda color,x
sta $d020
sta $d021
|
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
or drink a cofee with intensity. |
