| |
daison
Registered: May 2005
Posts: 90 |
stable rasters vs badlines
Hi there,
I recently picked up coding on the c64 (using kickassembler and emu's)
Now I want to write a routine that moves $d020/$d021 rasterbars up and down the screen.
I tried starting on some rasterinterrupt and then polling $d012 to color each line, this is unstable as expected.
Than I tried implementing the example on codebase64 from fungus using the double interrupt method to get stable raster timing, however this doesn't work on badlines.
I tried checking for badlines and then jumping over the initial nop's but it seems there are more lines producing timing errors then just the badlines (loads of cycles just get stolen from me!).
Since i'm loosing sleep over it, I have to turn to the code-gods on this forum for help...
a snippet of what the first interrupt looks like:
//check for badlines
clc
lda $d011
sbc raster1_top
and #7
beq badline
//nop till end of line (2 cycles each)
inc $d021 //proof that this the line is not a badline
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
badline:
irq2: //2nd interrupt for stable raster
...
=========================================
The results (tested lines: $40-$48):
well, everything is now unstable, except
If i use bne badline (instead of beq), which is quite unlogical to me, only line $43 is giving me headaches.
So, I'm probably missing something here, could anyone explain something about this stuff? tnx!
|
|
| |
Danzig
Registered: Jun 2002
Posts: 429 |
first think about if it is really necessary to compensate flicker on a badline :P
i suppose you think you need to compensate on EACH line but you just need to compensate ONCE. your then following rastercode is just a timing issue: 63 cycles vs. 21 cycles (badline).
so you easily can come up with a little loop doing just what you want. read the colorvalues from a table (keep in mind not to surpass $100-boundaries! that fuxxors timing) and there you go.
then you can just poke around in that table for maximum rasterfun.
|
| |
Mace
Registered: May 2002
Posts: 1799 |
Quote:clc
lda $d011
sbc raster1_top
With ADC you have to clear the carry, but beware that to get the correct answer with SBC, you need to SET the carry!
I'm not saying that this will solve your problem, though ;) |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
raster flicker occurs because the 6510 will only jump to an IRQ after finishing the current instruction. now the interrupt request may arrive in any cycle of an instruction, thus there will be a random number of 0-7 cycles delay before your irq code starts up, this is the flicker you see on the screen. (1 cycle causes 8 pixels latency on screen). this 0-7 cycles delay will be constant for the whole time your irq routine runs. there are no other factors changing the timing randomly other than this. (unless you move sprites over the irq or scroll the badlines, etc, but not even those will make your timing jump around randomly, it will simply be different) |
| |
daison
Registered: May 2005
Posts: 90 |
wow, you guys reply quick!
@danzig: So, basically I should setup the stable raster on a stable line and then and do all the top-position $d012 logic in irq1 for the next irq and then handle each line irq after irq... (kind of hard to explain in normal words... ;)
@mace: I'll look into that again, i've been debugging that little routine quite some times already...
@oswald: that's what i came to understand by reading some articles on this, but I just couldn't match it with what was going on the screen. (which is probably due to my little experience in all this).
It's quite motivating to have such quick and informing replies! Thanks guys!
|
| |
The Phantom
Registered: Jan 2004
Posts: 360 |
There are also several c64 magazine available, specifically for coders..
Coders World (had to)
C=Hacking
While coders world is a pretty lame mag (should make up for that plug), it's helped a lot of people become lazy. If you read Issue #2, you'll probably find the information your looking for, without knowing what's going on.
I would probably go with C=hacking, as they really get into the routine, explain what's going on, what's going to happen and why it happens. |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
daison,
looks like you're not getting it, or mixing up terms. you only stablize once after that inside the irq everything will be stable. and you only need one irq (2 if you're using fungus' stable method) to make rasterlines. there's not enough time to "handle each line irq after irq".
for rasterbars you need really only one irq and inside it you time the change of colors in a loop. and thats all. you dont need a stable raster. the flicker doesnt matters here as the invisible area of a rasterline is huge (at the sides), you can hide the flickering there by horizontally timing your routine.
you're not getting the stable raster code either (looking at your first post), the nops are there so the 2nd irq will fire when the first one is executing nops, thuse the flickering will be only 0-1 cycle, and the 2nd irq will straighten that out. |
| |
Testa
Account closed
Registered: Oct 2004
Posts: 197 |
how much cycles do we have at this invisible area of a rasterline?... i thought something about 11 cycles..
6 cycles in the left border?, 40 cycles at the screen area? en 6 cycles at the right border?.... and 11 cycles at the invisible area? all together i count 63 cycles,,
correct me if i am wrong...i don't know...
isn't there a scheme for this somewhere on the internet?
i sure could use such a schema when i picked up coding...
|
| |
assiduous
Account closed
Registered: Jun 2007
Posts: 343 |
http://www.zimmers.net/cbmpics/cbm/c64/vic-ii.txt
( 3.6.3. Timing of a raster line ) |
| |
Testa
Account closed
Registered: Oct 2004
Posts: 197 |
yep this is what i mean, thanks a lot.....
|
