Cycle Counting Questions

[Just Jeff]

Hello!

 

I'm making my first attempt at cycle counting in the kernal and it became apparent to me that I've never paid much attention to the zero page. How do I know if I'm using it? My first guess for some reason would be that RAM and registers are the zero page- is any of the ROM zero page? Second.. does anyone know where I can find an easy to use chart of cycle times? I found something, but its pretty awkward. Here's what I came up with on my code, but it looks like I have plenty of time left to do more stuff. Do I? It looks like I've used 34 and still have 34 until the start of the visible part, leaving me with at least 34 more cycles before I even need to start paying attention to where the beam is:

 

ArenaLoop1:
sta WSYNC ;3 3 Storing 0, any value works
lda TopBand0,x ;4 7
sta PF0 ;3 10
lda TopBand1,x ;4 14
sta PF1 ;3 17
lda TopBand2,x ;4 21
sta PF2 ;3 24
dex ;2 26
dey ;2 28 Decrement the playfield line we're on.
tya ;2 30
cmp #160 ;2 32
bne ArenaLoop1 ;2 34 and if there are still lines to draw, repeat

 

Thanks!

[tschak909]

Basically, both the TIA and RAM on the RIOT are in zero page. Stack is always page 1, the IO is on page 2, and then ROM mirrors after that.

 

-Thom

[+SpiceWare]

I reference this for cycles.

Cycles per line start after the WSYNC.

ArenaLoop1:             ;- 32 - time from bne ArenaLoop1      
        sta WSYNC       ;3 35 Storing 0, any value works
        ;--------------------- start of new scanline
        lda TopBand0,x  ;4  4
        sta PF0         ;3  7
        lda TopBand1,x  ;4 11
        sta PF1         ;3 14
        lda TopBand2,x  ;4 18
        sta PF2         ;3 21
        dex             ;2 23
        dey             ;2 25 Decrement the playfield line we are on.
        tya             ;2 27
        cmp #160        ;2 29
        bne ArenaLoop1  ;2 31 (3 32) and if there are still lines to draw, repeat

the bne instruction will use 3 cycles if the branch is taken. I denote that using (3 xx).

[dmk]

And don't forget, 1 cpu cycle = 3 pixels, you only have 76 cycles per line total and 22 before the start of active portion, so you don't have that much time to spare.

[Just Jeff]

And don't forget, 1 cpu cycle = 3 pixels, you only have 76 cycles per line total and 22 before the start of active portion, so you don't have that much time to spare.

 

Right.. I thought it looked too good to be true.

[tschak909]

Start your first kernel with the goal of accomplishing what you need to do, within two lines. Once you get comfortable with doing that, then you can start trying to squeeze things into one line.

 

The trick is understanding what display elements you need on a given line, you have:

 

Two Players, P0, P1

Two Missiles, M0, M1

A ball, BL

and three playfield registers, PF0, PF1, PF2.

 

Which of those do you need on a given line?

 

For myself, and Dodgeball, I am going to use everything. So I knew that in order to have a nice amount of breathing room, I needed to do this with a two line kernel.

 

And even with a two line kernel, things can get too tight, so I made a critical optimization: PF0 never changes, which made me gain more than a few cycles.

 

Once you know this, then you can start deciding when and how to twiddle the various registers.

 

There are more advanced topics, such as the application of flicker, but those can come once you get a firm grasp of what you can do on a scan line.

 

-Thom

Edited June 19, 2016 by tschak909

[Just Jeff]

The trick is understanding what display elements you need on a given line, you have:

 

Two Players, P0, P1

Two Missiles, M0, M1

A ball, BL

and three playfield registers, PF0, PF1, PF2.

 

Thanks,

 

What I'm attempting here also, I think is called 'banding"? This is just the top part of the screen, and I wanted it to look as pretty as possible. Nothing will be moving around so I think it will be ok if some graphics come in a little late depending on screen position. I want to squeeze in color changes for the background and possibly other objects too. Sounds unreasonable now that I spell it out. So yeah it will probably turn back to two lines and if I want some higher definition for some things, I could just put those objects on both lines I guess.

 

Application of flicker.. hmm... I don't know how to do that.

[tschak909]

Well, if you notice, in certain games, like Pac-Man, the player objects flicker. This is because they are not shown every frame. In the simplest case, Pac-Man takes one of the player objects, and divides it into four frames, showing each of the ghosts over four frames. This is _very_ noticeable, but it allowed for one player to represent multiple ghosts in different positions. Many other games employ a much more intelligent (and correspondingly complex) method of managing flicker, e.g. if all the players are at different vertical positions, then there is no flicker, if two players happen to cross in the same area, then show P0 one frame, P1 the next, etc... This is ultimately accomplished by breaking the display up into "bands" the vertical size of a player, and managing their display against that in the kernel.

 

-Thom

[Just Jeff]

I reference this for cycles.

 

Ha!... That's the one I've been using. I thought I saw a handy one-page chart of the the op codes somewhere. Anyway, this one does work pretty well.

 

Thanks!

[TheHoboInYourRoom]

Ha!... That's the one I've been using. I thought I saw a handy one-page chart of the the op codes somewhere. Anyway, this one does work pretty well.

 

Thanks!

This page has a chart that even includes the illegal opcodes.

[+Andrew Davie]

the bne instruction will use 3 cycles if the branch is taken. I denote that using (3 xx).

 

And +1 if the branch crosses a page boundary!

[+SpiceWare]

And +1 if the branch crosses a page boundary!

Very true. Perhaps I should add a cycle counting entry to my Collect series - while I mention it in the source, I didn't post anything about it. I can bring up supercat's same page branch check macros of SBCC, SBCS, SBEQ, SBMI, etc.

[Kylearan]

I can bring up supercat's same page branch check macros of SBCC, SBCS, SBEQ, SBMI, etc.

Oooh, those macros sound nice! Do you have a link? I (quickly) tried to do them myself some time ago and failed...

[+SpiceWare]

Oooh, those macros sound nice! Do you have a link? I (quickly) tried to do them myself some time ago and failed...

 

They've been there from the beginning of my Collect series, it's an in-depth course on writing a 2K 2600 game. You'll find them in macro.h.

 

The Kernel that BNE Jeff posted would be done like this:

ArenaLoop1:             ;- 32 - time from bne ArenaLoop1      
        sta WSYNC       ;3 35 Storing 0, any value works
        ;--------------------- start of new scanline
        lda TopBand0,x  ;4  4
        sta PF0         ;3  7
        lda TopBand1,x  ;4 11
        sta PF1         ;3 14
        lda TopBand2,x  ;4 18
        sta PF2         ;3 21
        dex             ;2 23
        dey             ;2 25
        tya             ;2 27
        cmp #160        ;2 29
        sbne ArenaLoop1 ;2 31 (3 32) the SBNE macro insures the branch is to the same page.  

---

If you need the branch to take 4 cycles use this instead:

        dbne ArenaLoop1 ;2 31 (4 33) the DBNE macro insures the branch is to a different page.  

[Kylearan]

Awesome, thanks!