Drawing the limits of a playfield

[Andropovbr]

Hi people, I'm diving into the obscure, though wonderful, world of the 2600 programming. I started to read the tutorial for newbies, Stella's Programmer Guide and a bit of 6502 docs. I'm not proeficient in those materials yet, but I think it would be good learn while developing a project in order to practice what I have learned. My project is to do a traditional Pong game with missiles. I'm sure it will not be an joyful game, it's more like a demo to learn the basics.

 

So my first step is to draw a black playfield with borders. I could accomplish that, but I'd like to know from the experienced developers if you have some advice in order to make the kernel code "clever". At first sight it seems to me the code is a little bit lame:

 

; >>>> Start of the kernel. 192 scanlines (frame displayed on the TV)
 
; Set all PFs registers below as %11111111 so we'll have the top line of the field
lda #%11111111
sta PF0
sta PF1
sta PF2
 
ldy #192
KernelLoop
 
cpy #187
bne Cpy5 ; If it's not the 5th scanline, step to the next comparison. Otherwise
; change the playfield to draw only the left wall below
 
lda #%00010000
sta PF0
 
lda #0
sta PF1
sta PF2
 
Cpy5
cpy #5
bne ContinueKernelLoop ; If it's not the 187th scanline, step to the next scanline.
  ; Otherwise change the playfield to draw the botton line
 
lda #%11111111
sta PF0
sta PF1
sta PF2
 
ContinueKernelLoop
sta WSYNC
dey
bne KernelLoop ; Turn back to KernelLoop until the last scanline
 
; >>>> End of the kernel <<<<
 

I'm attaching a picture of the playfield and the full source code. It seems ok, but I'm open to any advice from you. Now I'm intending to work on the players' sprites.

 

Thank you, and sorry about my English!

shotpong.asm

[Omegamatrix]

Hello!

 

 

Your code looks fine. You could improve it by using some constants, such as defining the colors, and for the values loaded into the TIM64T. It will make it easier later to convert between NTSC/PAL/PAL-60.

 

 

 

[Nukey Shay]

Why use side borders at all for Pong? Keep in mind you are going to ultimately need at least 3 decisions within the kernel's 182-scanline playing area (for each player and the ball), and two more if you are intending to use the paddle controllers (you need to take a reasonable amount of samples for smooth movement...like once every two scanlines). A comparison outside the kernel can determine if the ball is out.

 

But even if that display example is what you require, the decisions to draw the sides and lower border do not need to be within the kernel loop itself. Just turn on all PF and burn 5 scanlines at the top to draw the upper border, waste the remaining cycles in the final scanline to update PF, do the play area loop of 182 scanlines, and burn another 5 scanlines at the bottom after turning on all PF for that border.