40 replies to this topic

[Happy_Dude]

http://www.6502.org/...6502opcodes.htm

ROL (ROtate Left) 



Affects Flags: S Z C 



MODE           SYNTAX       HEX LEN TIM

Accumulator   ROL A         $2A  1   2

Zero Page     ROL $44       $26  2   5

Zero Page,X   ROL $44,X     $36  2   6

Absolute      ROL $4400     $2E  3   6

Absolute,X    ROL $4400,X   $3E  3   7

[dew2050]

I already have this information. I just wanted to make sure "ROL TEMP_VAR" uses Zero Page as the addressing mode.

[Happy_Dude]

Settle down dew
It depends how you initialized it.
TEMP_VAR = $80 (Zero page)
or
TEMP_VAR = $8000 (Absolute)

[Thomas Jentzsch]

dew2050 wrote:

 CLC

 ROL PATTERN_RIGHT

 ROL PATTERN_LEFT

 BCC SCROLLCOMPLETE



 INC PATTERN_RIGHT 



SCROLLCOMPLETE

Nearly perfect!

If you replace the first ROL with ASL then you can remove the CLC.

Quote

I have a newbie assembler question: How many machine cycles does the ROL commands above take? Is it 5 for zero page?

Yup, excatly.

[dew2050]

Happy_Dude said:

Settle down dew
It depends how you initialized it.
TEMP_VAR = $80 (Zero page)
or  
TEMP_VAR = $8000 (Absolute)

Now that's more helpful. Thanks.

Thomas Jentzsch said:

If you replace the first ROL with ASL then you can remove the CLC.

So ASL sets the carry even if the dropped bit is 0? These subtle nuances are so interesting (programming-wise). Thanks Thomas. It's a lot more clear now.

[Pitfall Harry]

dew2050 said:

So ASL sets the carry even if the dropped bit is 0? These subtle nuances are so interesting (programming-wise). Thanks Thomas. It's a lot more clear now.

ASL sets the carry flag only if the high bit (bit 7) was a 1 prior to the shift.
If bit 7 was a 0 prior to the ASL, then the operation clears the carry flag.


           +-+-+-+-+-+-+-+-+
      C <- |7|6|5|4|3|2|1|0| <- 0    ASL
           +-+-+-+-+-+-+-+-+


Ben

[Big Player]

Thomas Jentzsch said:

Nature Boy said:

This might be a stupid question, but does altering the number of scanlines affect the number of FPS displayed?  Seems to me that if you went with, say, 280 scanlines (keeping 192 for the picture), that the FPS would drop below 60.

Yup, exactly!

You can calculate that quite easily:
Artillery Duel: 60/241*262 = ~65Hz
Demon Falcon: 60/280*262 = ~56Hz
PAL games: 60/312*262 = ~50Hz

What the advantage of displaying less frames per second?  Does this free up more CPU time for other parts of the program?  

Thanks.

[Big Player]

Big Player said:

Thomas Jentzsch said:

Nature Boy said:

This might be a stupid question, but does altering the number of scanlines affect the number of FPS displayed?  Seems to me that if you went with, say, 280 scanlines (keeping 192 for the picture), that the FPS would drop below 60.

Yup, exactly!

You can calculate that quite easily:
Artillery Duel: 60/241*262 = ~65Hz
Demon Falcon: 60/280*262 = ~56Hz
PAL games: 60/312*262 = ~50Hz

What the advantage of displaying less frames per second?  Does this free up more CPU time for other parts of the program?  

Thanks.

:!: May have answered my own question.  Does this give the CPU more time to create a more advanced display?

[Thomas Jentzsch]

Big Player said:

Does this give the CPU more time to create a more advanced display?

Not really, since the time per scanline is still 76 cycles. But it gives you the chance of a taller display and more offscreen calculation time. The latter is important when your game is getting more and more complicated.

Remember all calculations (e.g. moving objects, reading joysticks, checking collisons, awarding points, sound... and last not least: preparing data for the display kernel) have to be done offscreen, since during the display kernel, the CPU is normally 100% busy with drawing something.

[Nature Boy]

Thomas Jentzsch said:

Remember all calculations (e.g. moving objects, reading joysticks, checking collisons, awarding points, sound... and last not least: preparing data for the display kernel) have to be done offscreen, since during the display kernel, the CPU is normally 100% busy with drawing something.

This might seem trivial but I've been wondering about this for *ages*.  As a newbie it's still hard to look at a disassembled game and figure this out on my own.  And when coding my own little 'hello world' type stuff I couldn't stop thinking "jeez, it's taking me a lot of time here just to draw my playfield and player graphics - how am I gonna do anything else?"

You 'da man Thomas

[Rob Mitchell]

Quick note:  I am here and keeping up!

Suggestion:  I printed out the PF0, PF1, PF2 illustration and tucked it inside my Stella Programmer's Guide before page 39 on which these registers are referenced.

Rob Mitchell, Atlanta, GA

[MestreLion]

Andrew Davie said:

3.  Write some solid shape(s) to PF0, PF1, PF2 (ie:  lda #%01011110, sta PF0, sta PF1, sta PF2) and then play with changing the playfield colour several times during a scanline.  How many colour changes (maximum) do you think you can get on any line?  Why is there a limit?

StartOfFrame



   ; Start of new frame - VBLANK is still ON



                lda #2

                sta VSYNC



                sta WSYNC

                sta WSYNC

                sta WSYNC               ; 3 scanlines of VSYNC signal



       ;------------------------------------------------

       ; 37 scanlines of vertical blank...



                ldx #0     ; Tuning off VSYNC

                stx VSYNC



VerticalBlank   sta WSYNC

                inx                ; 2

                cpx #37            ; 2

                bne VerticalBlank  ; 2



       ;------------------------------------------------

       ; Do 192 scanlines - Begin of the 1st line



                ldx #0     ; 2 this counts our scanline number

                stx VBLANK ; 3 and this turns VBLANK off





Picture         sta WSYNC



                SLEEP 16   ; H blank - any change here would not be seen



                lda #$0F   ; 2

                sta COLUPF ; 3  = 21



                adc #$10   ; 2

                sta COLUPF ; 3  = 26



                adc #$10   ; 2

                sta COLUPF ; 3  = 31



                adc #$10   ; 2

                sta COLUPF ; 3  = 36



                adc #$10   ; 2

                sta COLUPF ; 3  = 41



                adc #$10   ; 2

                sta COLUPF ; 3  = 46



                adc #$10   ; 2

                sta COLUPF ; 3  = 51



                adc #$10   ; 2

                sta COLUPF ; 3  = 56



                adc #$10   ; 2

                sta COLUPF ; 3  = 61



                adc #$10   ; 2

                sta COLUPF ; 3  = 66



                inx        ; 2

                cpx #192   ; 2

                bne Picture; 3

               ;sta WSYNC ; 3  = 76





       ;------------------------------------------------

       ; 30 scanlines of overscan...



                sta WSYNC ; 3  = 75



                lda #%01000010

                sta VBLANK          ; end of screen - enter blanking



                ldx #0

                stx COLUPF





Overscan        sta WSYNC

                inx

                cpx #29

                bne Overscan





                jmp StartOfFrame

Thats 9 different playfield colours per scanline. If I add 1 more adc/sta pair, the screens gets really screwed up. I know a loop would be a LOT more elegant, but i would waste precious cycles with it, and would get no extra colors.

As for the actual theorical limit... humm, lets see:

- we have 76 cpu cycles

- theres no reason to change color while in horizontal blank, because new colour would not be visible. So, all we can do in the first 22 cycles is to set a colour for free and wait till it comes visible.

- For the remaining 76 - 22 = 58 cycles, 10 are used for housekeeping and loop maintance (inx, cpx, bne and sta wsync). Yes, i know that experienced programmers use less then 10 cycles, but as im not a Jedi Master (yet), I'll use 10 for my math. So we actually have 58 - 10 = 48 cycles to change colour like crazy.

- As far as I know, you cant change playfield colour in less then 5 cycles. 2 to set the desired colour (either by inx, iny, adc, whatever) + 3 to store that colour in COLUBK register

- 48 remaining cycles / 5 cycles per colour change = 9.6  Rouding down, thats 9 color changes

So, we have 1 initial colour + 9 changes = 10 different colors per scanline at most. Correct?

A Jedi Master that could reduce the loop maintenance to 8 cycles would achieve 11 colors, but thats as good as it gets.

Isnt it?

PS: Why the hell my 1st scanline is screwed up after the first color change?

Attached Thumbnails

• 

[Jedd]

Woah, nobody's posted here in a long time.

Anyway, I have an idea for a program.  How about a simple utility that allows you to draw 20 pixels of a playfield (and lets you see the other half mirrored or normal) and then gives you the values of PF0 PF1 and PF2?  It would probably be pretty simple to make, and I can see it being a very useful tool for newbies (like me!).  Figuring out how to make the playfield look the way you want is a pain in the butt.

[Cybergoth]

Hi there!

There you go: http://alienbill.com...ayfieldpal.html

Greetings,
Manuel

[Jedd]

YAY!  That's awesome man.  Thanks for the link and the quick reply!  My life is now complete.  

[kamakazi]

Man...now we are getting into some wierd stuff.  I was editing my code to do the background solid colors and the bars in rainbow (dubbed kernel reversed).  After compiling and running the code...i only got the rainbow on the left side of the screen and I don't know what I did...

		   processor 6502

		   include "vcs.h"

		   include "macro.h"

;---------------------------------------------------------------

PATTERN		= $80
TIMETOCHANGE	= 20

;----------------------------------------------------------------


		   SEG

		   ORG $F000



Reset

;Clear RAM and all TIA registers

	ldx #0
	lda #0
Clear	sta 0,x
	inx
	bne Clear

;----------------------------------------------------------------

; Once-only initialization

	lda #0
	sta PATTERN

	lda #$45
	sta COLUPF

	ldy #0

;----------------------------------------------------------------



StartOfFrame



  ; Start of vertical blank processing



		   lda #0

		   sta VBLANK



		   lda #2

		   sta VSYNC

		   

			   sta WSYNC

			   sta WSYNC

			   sta WSYNC	; 3 scanlines of VSYNC signal



		   lda #0

		   sta VSYNC		   



			  ; 37 scanlines of vertical blank...

	ldx #0

VerticalBlank	sta WSYNC

	inx

	cpx #37
	
	bne VerticalBlank

;--------------------------------------------------------------------

;Handle a change in the pattern once every 20 frames
;and write the pattern to the PF1 register

	iny

	cpy #TIMETOCHANGE
	
	bne notyet

	ldy #0

	inc PATTERN
	
notyet  
	
	lda PATTERN

	sta PF0
	sta PF1

;--------------------------------------------------------------------



;--------------------------------------------------------------------
	
		   ; 192 scanlines of picture...



			   ldx #$45
	stx COLUBK

	ldx #0


Picture stx COLUPF

	SLEEP 40

	lda #$45
	
	sta COLUPF
	
	sta WSYNC

	inx

	cpx #242

	bne Picture


;-------------------------------------------------------------------

		   lda #%01000010

		   sta VBLANK					 ; end of screen - enter blanking



			  ; 30 scanlines of overscan...

	ldx #0

Overscan	sta WSYNC

	inx

	cpx #30

	bne Overscan



		   jmp StartOfFrame





		   ORG $FFFA



		   .word Reset		  ; NMI

		   .word Reset		  ; RESET

		   .word Reset		  ; IRQ



	END

Help me understand what I did?

Attached Thumbnails

•