How do you keep in sync?

[Shufflehound]

I'm working on a Roobarb and Custard game, and I'm editing scripts from other tutorials I've seen on 2600 programming, but whenever I do something new, especially if it involves WSYNC or something, it starts flickering!

 

No matter how many tutorials I look up, whenever I do some code I always end up with flickering and horizontal hold/sync issues.

 

I'm not really asking what's wrong with the code here, it's more like how can I find what's wrong with the code as well as in future projects?

 

 

 

Thanks in advance!

bum.asm

bum.bin

Edited December 29, 2013 by Shufflehound

[roland p]

In one part you decrease Y and check if it is zero:

 

FinishPlayer
DEY
BNE ScanLoop

Edit: half of my message was deleted somehow:

 

Later in the code you do this again:

FinishEnemy
DEY
BNE ScanLoop

But Y was already 0 at this part. decreasing it makes it 255. So the loop will be executed 255 (256?) more times. This creates extra lines and makes the screen roll. I guess the loop is executed forever. Edited December 29, 2013 by roland p

[Shufflehound]

Yes, so once it has, it will go to the ScanLoop. Is there something wrong with that?

[roland p]

I'm not really asking what's wrong with the code here, it's more like how can I find what's wrong with the code as well as in future projects?

I used the debugger in stella and hit the '~' key for the debugger. And hit Scan +1 a few times. I saw you checked Y every time, so I hit it a few times more until Y was 0 and then stepped through the code with 'step' to see what happened next. Then I saw you decreased Y another time, making it 255, followed by a check. I realised the code never quit. Then I disabled the second loop (the part after 'CheckActivateEnemy', until the BNE ScanLoop), recompiled the code and got a stable picture.

[Shufflehound]

Thanks. But, now what's being drawn of the enemy is simply a pink line. Or have I gone wrong somewhere?

Also, could you explain why the code was doing that?

[+Gemintronic]

Hate to butt in since I know not assembly. Is this one of those instances where a cycle count chart is handy (not sure about the terminology)? I thought assembly gurus use such things to plan out kernels.

[Shufflehound]

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

[+Gemintronic]

I was trying to find what I was talking about. Basically, someone posted a nice graph/sheet that helped you plan out your kernel so you never go over cycle. Sorry for being less than totally helpful

[Shufflehound]

Okay. Well, I'll go and search also (and post an attachment if I find it), but if anyone else finds it post it up! Thanks.

[Shufflehound]

Thanks. But, now what's being drawn of the enemy is simply a pink line. Or have I gone wrong somewhere?

Also, could you explain why the code was doing that?

In the mean time, could someone answer my previous question? Thanks in advance.

[roland p]

I think you see a pink line, because that code is executed only one time. Y is 0 and decreased so it is 255, it jumps to ScanLoop. The next time, 'FinishPlayer' is reached and it loops again for 255 times and the enemy code runs again for one time.

[Shufflehound]

The enemy's got it's own line buffer variable. So, are you saying that the section that draws the enemy is being skipped.

[roland p]

'EnemyBuffer' is loaded with a value only one time.

 

 

Maybe it's easier to draw sprites using indirect addressing?

 

I've changed the kernel to:

ScanLoop
		STA WSYNC
		LDA (player_ptr),Y
		STA GRP0
		LDA (enemy_ptr),Y
		STA GRP1
		
		DEY
		BNE ScanLoop

The player_ptr is setup with:

	LDA TopDelay
	STA player_ptr
	LDA #>Roobarb
	STA player_ptr + 1

I used TopDelay because that value changes when you move the joystick. I also changed the sprite data a bit.

bum_modified.asm

bum2.bin

Edited December 29, 2013 by roland p

[Shufflehound]

The tutorials that I've looked up on sprites haven't explained indirect addressing. Could you expand on that?

[roland p]

I have to go now. Maybe someone else can explain, as it is quite common. In short, it looks at the data at address player_ptr + Y.

[Shufflehound]

Anyone else?

[Shufflehound]

What does the 'ds' command mean? Has that got something to do with the Data Segment Register?

[ScumSoft]

Your code is a bit messy and the kernel isn't implemented fully, I was doing a merge of your code into a template I wrote up years back that helps keeps things neat and organized.

Give me a little more time to make sure everything you need is well commented and written up and you should be able to use it for any future projects.

Edited December 30, 2013 by ScumSoft

[Shufflehound]

Thanks that's very much appreciated. But, might I ask what IS wrong with my current kernel?

I'd like to know how it's not implemented fully as well as how it's messy as it might help.

[RevEng]

Anyone else?

Run through this 6502 tutorial and it should help you understand 6502 addressing modes and other stuff you'll need to solidly know before tackling 2600 kernels.

[ScumSoft]

Thanks that's very much appreciated. But, might I ask what IS wrong with my current kernel?

I'd like to know how it's not implemented fully as well as how it's messy as it might help.

The 2600 is great in that there is no one shoe fits all (yet) boiler plate code, but there is a generally accepted method to how most kernels are laid out.

Your draw kernel is segmenting itself twice when it should be one contiguous flow, the way your HMOVE is handled can be improved greatly, joystick polling also. Your variables for position checking are not required ect..

 

[edit]Oh, and when you can see how other people work the kernels you can get an idea how it compares to your methods. I am not implying mine are better, just a different way of approaching the build and might be of some use.

Edited December 30, 2013 by ScumSoft

[roland p]

What does the 'ds' command mean? Has that got something to do with the Data Segment Register?

 

ds fills the memory with numbers.

The command ds 150,$0 fills 150 bytes with the number 0. I use this to pad the sprite data above and below with 0's otherwise you would see garbage above and below the sprites.

 

But my example is just one way (with its own set of compromises ) of accomplishing it. You could also try to imporove your current code. At first you should try to make it one loop with one branch to the 'ScanLoop' label.

Edited December 31, 2013 by roland p

[Shufflehound]

Is this at the moment compatible with paddle controllers, that is when I change the logic code to reading the paddles? ('Cause paddles are certainly my controller of choice. Analogue bliss!)

[+SpiceWare]

I posted a Paddle Demo on my site a while back.

[Shufflehound]

Thanks, SpiceWare.