How do you keep in sync?

[+SpiceWare]

Note: If you're testing with Stella you'll have to "plug in paddles" as it defaults to Joysticks.

 

Press TAB on your keyboard to access the in-game menu

 

Click the Game Properties button

 

Click the Controller tab

 

Change controllers to Paddles.

 

Stella remembers the settings for each ROM (it uses the MD5 hash, which you can see in the 2nd screenshot, as the lookup value for the settings), so if you run the exact same ROM again it'll already be set for paddles. If you make changes and recompile the MD5 value will change, so you'll have to "plug in paddles" again.

[Wickeycolumbus]

There's a cycle count chart? May I have a link? I had no idea that such a thing existed.

When writing a kernel it's typical (for me anyway) to put a comment on each line with the cycle count of the instruction, so you can keep track of where you are in the line. It may also be useful to write the total cycle count for the line every few lines of code, especially where you store to TIA registers. This link shows the cycle counts for each instruciton:

 

http://www.masswerk.at/6502/6502_instruction_set.html

 

It takes some time to used to telling how many cycles a particular instruction takes with all the different addressing modes and exceptions (like crossing a page boundary), especially for a beginner. But if you stick with it, you may not even have to look at the chart anymore.

 

Something important to consider is that when you hit WSYNC in your kernel (ie STA WSYNC), the 3 cycles from the STA (zeropage) count for the previous line, and the processor is halted until the beginning of the next line, cycle 0. As you probably know, you have 76 cycles per line to draw the screen.

 

I've added cycle counts to the first few lines of your kernel for your reference.

 

                ; ...

ScanLoop
		STA WSYNC               ;3
		LDA PlayerBuffer        ;3
		STA GRP0                ;3
		LDA EnemyBuffer         ;3
		STA GRP1                ;3
CheckActivatePlayer
		CPY BottomDelay         ;2
		BNE SkipActivatePlayer  ;2  **
		LDA #12                 ;2
		STA PlayerLine          ;3

SkipActivatePlayer
		LDA #0                  ;2

                ; ...

BNE and all branching instructions are one example where you will need to add a cycle if a page boundary is crossed. A page is just a name for a 256 byte chunk of address space. So for the 2600, the upper byte of the address is the page number. Below is an example where the bne would actually take 3 cycles. I've put addresses in the left column.

 

13fc         ldy #5
13fe    loop:
13fe         sta WSYNC
1400         dey
1401         bne loop

Since the label loop is in page 13 of memory, and the bne instruction is in page 14, a page boundary was crossed. Thus the processor must take an extra cycle to properly alter the program counter register. If the same code were executed in a slightly different address range as below, bne will only take 2 cycles.

 

1400         ldy #5
1402    loop:
1402         sta WSYNC
1404         dey
1405         bne loop

As you can see, the loop label and BNE instruction are both in page 14. To avoid page boundary crosses in a kernel, one might put the kernel in it's own page of memory, and jump or jsr to it in the program. You can do this various ways, with an org $xxxx statement for example.

 

Something unrelated you may or may not know about branch instructions is that you can only branch to a label that is +/- 128 bytes away from the instruction.

 

I haven't given your code a serious look, so I can't tell you for sure what's the matter with it. But anyway, hope this helps you understand cycle counts a bit more.