[CSDb] - User Forums - DYSP timing with $d011 is off

Welcome to our latest new user maak ! (Registered 2024-04-18)

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > DYSP timing with $d011 is off

2016-04-25 21:12

Compyx

Registered: Jan 2005
Posts: 631

DYSP timing with $d011 is off

Today I wrote a DYSP using a pre-calculated table, which, for each combination of sprites on a raster line, contains the number of cycles those sprites use when opening the border.

Problem is, these values differ from the output of Groepaz' victimer tool. I suspect this has to do with my routine writing to $d011 to cancel out bad lines, but I'm not sure.

This is the basic loop to open the border:

dysp
        ldy #8
        ldx #0
-       lda d021_table,x
        dec $d016
        sta $d021
        sty $d016
        lda d011_table,x
        sta $d011

        lda timing,x
        sta _delay + 1
_delay  bpl * + 2
        cpx #$e0
        cpx #$e0
        cpx #$e0
        cpx #$e0
        cpx #$e0
        cpx #$e0
        cpx #$e0
        cpx #$e0
        bit $ea
        inx
        cpx #DYSP_HEIGHT
        bne -
        rts

The 'timing' table contains, for each raster line, the number of cycles I need to skip for the sprites at that raster line. That table is calculated using some ORA magic to determine the number of sprites active on a given line and looking up the proper cycle skip in a 'cycles' table.

Currently, my cycle table looks like this:

cycles
        ; $00-$03 
        .byte 0  ; no sprites
        .byte 3  ; sprite 0
        .byte 5  ; sprite 1
        .byte 5  ; sprite 0 + 1

        ; much more data

        ; $fc-$ff
        .byte $0f  ; sprite 2-7
        .byte $11  ; sprite 0, 2-7
        .byte $11  ; sprite 1-7
        .byte $11  ; sprite 0-7

While grepping victimer's output for each value in $00-$ff, I get this:

00	VIC:  0
01	VIC:  2 (+ 1= 3)
02	VIC:  2 (+ 1= 3)
03	VIC:  4 (+ 1= 5)

...

fc	VIC: 12 (+ 1=13)
fd	VIC: 14 (+ 2=16)
fe	VIC: 14 (+ 1=15)
ff	VIC: 16 (+ 1=17)

So obviously my table is different from victimer's output (my table indicates more cycles stolen for many sprite combinations).

Unfortunately, I can't make heads or tails of the VIC article when it comes to sprites stealing cycles. So any pointers to where I should look would be much appreciated.

2016-04-25 21:29

chatGPZ

Registered: Dec 2001
Posts: 11090

you'll have to be careful with the cycles marked W in the graph printed by victimer... those can only be used by the cpu to finish a write, after the write is done the cpu is stalled.

the d011 writes shouldnt matter (unless you force a badline when a regular line has already started ... but you probably dont do this in such a routine :))

2016-04-25 21:44

Compyx

Registered: Jan 2005
Posts: 631

Ok, I'll look into that. thanks.
Problem is that my version of victimer doesn't display any 'w' or 'W' in the output (except in the legenda). Compiled it myself using the version here on CSDb.

edit: spoke too soon, -b shows those 'w' and 'W' cycles.

2016-04-25 23:46

Krill

Registered: Apr 2002
Posts: 2821

Some details that the VIC article doesn't seem to get across very nicely are crucial, IMHO.

One thing is the "BA goes low" period that Groepaz mentioned, which means that you can have more or less spare cycles depending on what the CPU does (read or write) at the moment VIC prepares to take over the bus for sprite DMA. The more the CPU is busy writing, the better. Best is to have two successive write cycles using read-modify-write instructions (inc, dec, shift or rotate) at this point to have maximum spare CPU cycles. (This is why you cannot open the side border with all 8 sprites enabled - that is, sprite 0, actually - using sta/x/y $d016, but must use inc/dec/etc.)

Another important detail is that VIC hogs both the falling and the rising clock edges when it does DMA, effectively accessing the bus (and connected memory) at 2 MHz, while VIC and CPU usually take the odd or even half-cycle each. This means that VIC generally takes 2 cycles per sprite in a raster line (to read the sprite pointer and then the 3 pattern bytes in 4 half-cycles) - but a sprite "gap" (e.g., having sprites 0 and 2..7 enabled, but not sprite 1) would NOT give those 2 cycles back to the CPU, as this is less than the 3-cycle settle period that is required for the CPU to cede bus masterhood to VIC.

A minor detail to take into account is that sprite DMA starts in the right border of the preceding raster line. This is important when the number of active sprites changes from one line to the next, and the impact depends on how your code defines the beginning/end of a raster line versus sprite DMA.

IMHO, these details are what is generally missed when trying to understand how many cycles are left for the CPU when having arbitrary sprites enabled.

2016-04-26 09:03

Compyx

Registered: Jan 2005
Posts: 631

Thanks a lot for that detailed explanation! I always wondered why I had to do a DEC $d016/INC $d016, wasting precious cycles. I found out about it the hard way, but could never quite figure out why.

It's nice to finally get to understand how the things worked I wrote over 25 years ago ;)

2016-04-26 09:47

chatGPZ

Registered: Dec 2001
Posts: 11090

that stuff was pretty much the reason for me to write that victimer program :)

2016-04-26 11:08

Compyx

Registered: Jan 2005
Posts: 631

I can imagine that! That's why I wrote a similar DYSP routine like this one about 25 years ago, to have some reference on how sprites eat cycles. Lost it long ago of course.

I love the C64, but once you get into VIC-trickery, it's an amazingly complex machine :)

Refresh

Subscribe to this thread: