Starting 2600 programming

[Orion_]

Hello,

 

I'm new to 2600 programming, and it seems that timing is pretty critical there.

I searched a lot in documentation, studying sources code example and debugged some games to see timing, and it seems that not every rom does the same things. (TIM64T value not the same, or strange vsync/vblank enable)

In my template I get some blank lines at the beginning of the screen(in stella) whereas medieval mayhem PAL version starts at the top of the screen.

So, are the TV timing as critical as I think, or does a wrong timing isn't very dangerous for the TV Set ?

I will use a PAL system so I'm trying to get a PAL template.

I would like to know if it's seems correct and If I don't get the timing wrong.

 

Thank you !

 

	processor 6502

include	"vcs.h"
include	"macro.h"

ORG	$F000

Start:
CLEAN_START

Loop:

;--------
; VSync

lda	#2	; VSync On Value
sta	WSYNC	; Finish Current Line
sta	VSYNC	; Turn VSync On
lsr		; VSync Off Value
sta	WSYNC	; Wait 3 lines
sta	WSYNC
sta	WSYNC
sta	VSYNC	; Turn VSync Off

;---------
; VBlank
; NTSC: (3/37/192/30)
; PAL:  (3/45/228/36) <-

SCANLINE_TIME	=	76
VBLANK_LINES	=	45
SCREEN_LINES	=	228
OVERSCAN_LINES	=	36

lda	#2	; VBlank On Value
sta	VBLANK
lda	#(VBLANK_LINES*SCANLINE_TIME)/64
sta	TIM64T
vbloop:	lda	INTIM
bne	vbloop
sta	WSYNC
sta	VBLANK

;---------
; Screen

ldx	#SCREEN_LINES
scloop:	stx	COLUBK
dex
sta	WSYNC
bne	scloop

;-----------
; Overscan

lda	#2	; VBlank On Value
sta	VBLANK
lda	#(OVERSCAN_LINES*SCANLINE_TIME)/64
sta	TIM64T
ovloop:	lda	INTIM
bne	ovloop

;-------------
; Next Frame

jmp	Loop

;-------------
; Interrupts

ORG	$FFFA
.word	Start	; NMI
.word	Start	; RESET
.word	Start	; IRQ
END

Edited April 23, 2010 by Orion_

[Omegamatrix]

Looks pretty good. Medieval Mayhem starts drawing the playscreen on scanline 34, where yours starts drawing on line 45. That's why you see the black gap before your screen starts.

 

 

Use Alt L in Stella to check your scanline count. Right now it's 311. Adjust your timing values until it's 312.

[Orion_]

Thanks for the Alt+L tip !

 

I added a "sta WSYNC" at the end just before the loop.

What I don't understand is, when counting the number of scanline in my code I get 312.

Maybe I'm missing something.

I also noticed, the VBLANK is not turned off after the first frame, so at the beginning of the second frame, both vsync and vblank are turned on, is that ok ?

I took the timing of the stella programming manual for PAL, I think that starting to draw on line 45 is for centering the image on screen.

[Omegamatrix]

Yeah, Vblank and Vsync off at the same time is fine.

 

 

I think more modern TV's show more a picture. Could be wrong about that, but I think that's why Stella also has a bigger default screen. So you should be able to start your playscreen a few lines earlier, and have it end a few lines later if you wish. How far off you can go I'm not sure.

 

 

Keep the total scanlines at 312. Odd number of scanlines for PAL will give you a black and white screen.

[GroovyBee]

Even though you are developing for PAL I'd keep the number of lines used by the game's playfield, status bar etc. to between 192 and 216 otherwise you might have a problem adapting it for an NTSC display. That's what I do for my 7800 development and its worked out OK so far.

[SeaGtGruff]

If you make the following two changes in your code, it comes out to 312 lines exactly...

 

; Change # 1:

vbloop:	bit	TIMINT	; was	lda	INTIM
bpl	vbloop	; was	bne	vbloop

; Change # 2:

ovloop:	bit	TIMINT	; was	lda	INTIM
bpl	ovloop	; was	bne	ovloop

TIMINT is the RIOT register that holds the timer interrupt flag, which is bit 7. (Bit 6 is another interrupt flag, but I don't think it has any relevance to 2600 programming.) When the timer counts down past 0 and hits 255, bit 7 of TIMINT gets set. So if you use "bit TIMINT" and the result is positive (bit 7 = 0), it means the timer hasn't finished counting down yet.

 

When you check to see whether INTIM has reached 0 yet, you aren't counting down for the full time period, because INTIM will stay at 0 for the interval length-- in this case, 64 cycles (since you used TIM64T to set the timer). So if you fall out of the loop as soon as you see that INTIM is 0, you're falling out as much as 64 cycles too soon. That's okay if you've compensated for it by adding 1 to your value before you store it in TIM64T (i.e., "lda #((VBLANK_LINES*SCANLINE_TIME)/64+1)"), so that would be another way to fix it.

 

However, checking for INTIM has the potential problem that the code you're executing before you start checking INTIM might run over if it takes too much time, so you might miss the 0 value and end up having to wait for INTIM to hit 0 again-- and the next time around, it will be counting down once per cycle. Likewise, if you check for INTIM being positive or negative, you still run the risk of missing it when it happens.

 

On the other hand, if you check the status of bit 7 in TIMINT, you'll know right away whether or not INTIM has wrapped around from 0 to 255, because once bit 7 gets set, it will stay set until you check it. Thus, even if your code takes too long, you'll know that INTIM has already wrapped around the very first time that you check TIMINT.

 

Michael

[Orion_]

SeaGtGruff > Thanks for the hint and the detailed informations !

 

GroovyBee > But do I need to stick with precise vblank timing or if I extend the vblank period it's ok ?

Edited April 24, 2010 by Orion_

[GroovyBee]

But do I need to stick with precise vblank timing or if I extend the vblank period it's ok ?

 

Yep! You need to extend the vblank time so that the game runs at 50Hz for PAL as well as using the more limited PAL palette in the game. However, you do have more computation time in PAL because it runs at 50Hz. This can be a burden if/when you convert it to an NTSC game because your logic/AI might run out of available CPU cycles.