Re: [stella] Demo #1 of my 4 colour playfield game "PUSH"

Subject: Re: [stella] Demo #1 of my 4 colour playfield game "PUSH"
From: emooney@xxxxxxxxxxxxxxxx (Erik Mooney)
Date: Sun, 10 May 1998 17:29:00 GMT
Aaugh, oops... sorry, hit the send key a little too early on that previous
message there :)

>I'm concerned at my draw code - am I generating an acceptable frame?
>Does the TV synch OK?

No.

>I'd really like some feedback.  If you think its interesting, say so.  If
>you think it sucks, tell me why.  Positive response will encourage me to
>continue sharing source - otherwise I'll go native.

It might be interesting, but all it does is roll the picture on my TV.

>OBJPATTERN	EQU OBJPOS			+ OBJSIZE
>OBJPATTERNB	EQU OBJPATTERN		+ OBJSIZE
>	; WHOO BOY THERE'S GONNA BE SOME PROBLEMS WITH BIT SHIFTING
>	; TO MOVE THE OBJECT PATTERNS.  PROBABLY BETTER TO THINK ABOUT
>	; ROM TABLES FOR THIS STUFF

Do you always program in all caps? Hard on the eyes :)

>	; TYPICAL FRAME CONSISTS OF 3 VERTICAL SYNC (VSYNC) LINES,
>	; 37 VERTICAL BLANK (VBLANK) LINES,
>	; 192 TV PICTURE LINES
>	; 30 OVERSCAN LINES

Correct.

>	; WE HAVE JUST 37 LINES (@2812 CYCLES) OF VBLANK, SO WE HAVE TO MAKE
>	; SURE THE SCREEN DRAW DOESN'T GET STOMPED ON.  THE TIMER WILL TELL
>	; US IF WE'VE SCREWED UP.  TIMER DONE JUST BEFORE THE LAST WSYNC TO
>	; GIVE MAXIMUM POSSIBLE CYCLE COUNT AVAILABILITY/ACCURACY
>
>		LDA #43					; WELLL... 43.89..
>		STA TIM64T				; WE HAVE 37 LINES (= 2812 CYCLES)
>								; UH... LESS THE 3 FOR THE LINE BELOW

The cycle/line counts here need not be exact... an extra line one way or
the other won't stop the TV from syncing.
							
>	; THE KERNEL
>	; WE HAVE TO DRAW THE SCREEN TOO?  SHEESH, WHAT IS THIS... A 2600?
>	; YEAH, THATS RIGHT... LINE BY LINE WE HAVE TO HOLD HANDS WITH THE
>	; TIA, PASSING IT DATA SO THAT IT DRAWS THE SCREEN FOR US.  NICE.
>	; NOT!  GOOD FOR NOSTALGIA, THOUGH.  WHY, BACK IN MY DAY...

Enough editorializing... will you write the damn code already? :)

>DRAWSCREEN
>
>	; WAIT FOR VERTICAL BLANK PERIOD TO END
>	; TIMER COUNTS DOWN 1 EVERY 64 CYCLES, SO JUST WAIT FOR IT
>	; IF ITS OVER-TIME ALREADY, WE COULD BE IN TROUBLE, AS THE TIMER
>	; COUNTS UP WHEN IT REACHES 0. DON'T GO OVER-TIME!!
>
>ENDVB	LDA INTIM
>		BNE ENDVB

If you change that BNE to a BMI, and store a 42 to the timer in the first
place instead of a 43, you're in a little better shape if you do overflow.
The timer actually counts down to zero from whatever you write to it, then
continues past zero, so a BMI will pick it up even if you've gone a few
extra cycles.

>        LDX #32
>PREDRAW	STA WSYNC
>        DEX
>        BNE PREDRAW				; WELLL.... YEAH
>								; PUTS BLANK AREA AT TOP OF SCREEN
>								; NO DOCUMENTATION ON THIS ONE - ARBRITRARY?

Huh?  You just drew 32 blank lines at the top of the visible screen.  Was
that what you wanted?

>	;----
>	; CYCLE THRU DRAWING LINE BY LINE...
>	; TIME IS PRECIOUS HERE... THERE ARE JUST 228/3 CYCLES PER LINE
>	; AND THAT'S NOT COUNTING THE WSYNCH, SHOULD YOU BE WRITING THAT
>	; THERE ARE 68 CYCLES IN THE HBLANK PERIOD, WHICH STARTS AT THE 
>	; CONCEPTUAL BEGINNING OF A LINE ON THIS MACHINE

No.  There are 68 *pixels* in the Hblank period, which is 22.667 cycles.

>	; WE NEED TO HAVE EACH PF BYTE WRITTEN BEFORE THE SCAN REQUIRES IT
>
>		LDA PLAYFIELD,X
>        STA PF0
>        LDA PLAYFIELD+1,X
>        STA PF1
>        LDA PLAYFIELD+2,X
>		STA PF2
>
>        NOP
>        NOP
>        NOP
>        NOP
>        NOP
>
>        ; RIGHT PF
>		
>		LDA PLAYFIELD+3,X
>        STA PF0
>	    LDA PLAYFIELD+4,X
>        STA PF1
>        LDA PLAYFIELD+5,X
>        STA PF2
> 
>        NOP
>        NOP
>        NOP
>        NOP
>        NOP
>        NOP

By my count, this is 64 cycles since the beginning of the line.  For any
sort of 2600 programming like this, it really helps to include the cycle
counts on each line of code.

> 
>	; LINE 2
>
>		NOP
>		NOP
>		NOP
>
>		; LEFT PF
>
>		LDA PLAYFIELD,X
>        STA PF0
>        LDA PLAYFIELD+1,X
>        STA PF1
>        LDA PLAYFIELD+2,X
>		STA PF2
>
>        NOP
>        NOP
>        NOP
>        NOP
>        NOP
>
>        ; RIGHT PF
>		
>		LDA PLAYFIELD+3,X
>        STA PF0
>	    LDA PLAYFIELD+4,X
>        STA PF1
>        LDA PLAYFIELD+5,X
>        STA PF2
>
>		INY
> 
>        DEC     Temp0
>        BNE     NxtLine

Aha.  Here's the problem.  That block (since the "We need to have each PF"
comment line) drew two scanlines four times (temp0 = 4).  But you only
incremented Y once for each pair of scanlines.  This will be important...
follow along.

>		CLC
>		TXA
>		ADC #6
>		TAX
>
>		CMP #96
>		BCC NEXLIN0 

Here, we've done (96/6) blocks of 8 scanlines each.  Total = 128 scanlines.
Plus 32 that we did at the top of the screen.  Y = 64, because it was only
incremented four times per block.

>	; MAKE SURE WE HAVE A 192 LINE DISPLAY
>	; PAL MUST HAVE AN EVEN # OR THE COLOURS SCREW UP?!
>
>
>FIN		LDA #0
>		STA WSYNC
>		INY
>		CPY #192
>		BCC FIN

Ah.  Y equalled 64 when we began this loop.  So this loop drew another 128
blank scanlines.  You've done 128+128+32 scanlines so far, which equals 288
scanlines.  Way too many. :)  If you put two INYs in the inner loop instead
of one, and remove the 32 blank lines at the top of the screen, it should
total 192 scanlines.

>OVERSCAN
>
>	; AFTER THE SCREEN IS DRAWN, WE HAVE 30 LINES OF OVERSCAN
>	; THIS TIME SHOULD BE USED FOR GAME LOGIC
>
>		LDX #30
>OVERLIN	STA WSYNC
>		DEX
>		BNE OVERLIN
>
>		RTS

This is correct for overscan.

--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/stella.html

Current Thread