Jump to content

Photo

Session 14: Playfield Wierdness


40 replies to this topic

#26 Happy_Dude OFFLINE  

Happy_Dude

    River Patroller

  • 4,212 posts
  • Forum Slacker
  • Location:Sydney, Australia

Posted Sat Jun 7, 2003 10:24 AM

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

:D

#27 dew2050 OFFLINE  

dew2050

    Space Invader

  • 32 posts

Posted Sat Jun 7, 2003 10:37 AM

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

#28 Happy_Dude OFFLINE  

Happy_Dude

    River Patroller

  • 4,212 posts
  • Forum Slacker
  • Location:Sydney, Australia

Posted Sat Jun 7, 2003 10:54 AM

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

#29 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash

  • 18,810 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany

Posted Sat Jun 7, 2003 11:26 AM

dew2050 wrote:
CLC

 ROL PATTERN_RIGHT

 ROL PATTERN_LEFT

 BCC SCROLLCOMPLETE



 INC PATTERN_RIGHT 



SCROLLCOMPLETE
Nearly perfect! :thumbsup:

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

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

Yup, excatly.

#30 dew2050 OFFLINE  

dew2050

    Space Invader

  • 32 posts

Posted Sat Jun 7, 2003 12:44 PM

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


Now that's more helpful. Thanks.

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.

#31 Pitfall Harry OFFLINE  

Pitfall Harry

    Stargunner

  • 1,993 posts
  • Location:Glendora, CA

Posted Sat Jun 7, 2003 1:16 PM

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

#32 Big Player OFFLINE  

Big Player

    River Patroller

  • 3,661 posts
  • Overrated 70's dinosaur
  • Location:Cincinnati, Ohio

Posted Tue Jun 10, 2003 8:24 PM

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.

#33 Big Player OFFLINE  

Big Player

    River Patroller

  • 3,661 posts
  • Overrated 70's dinosaur
  • Location:Cincinnati, Ohio

Posted Tue Jun 10, 2003 9:04 PM

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?

#34 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash

  • 18,810 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany

Posted Wed Jun 11, 2003 1:23 AM

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.

#35 Nature Boy OFFLINE  

Nature Boy

    Chopper Commander

  • 125 posts
  • Location:Kitchener, Ontario, Canada

Posted Wed Jun 11, 2003 6:34 AM

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 :)

#36 Rob Mitchell OFFLINE  

Rob Mitchell

    River Patroller

  • 2,726 posts
  • Location:Your Village

Posted Sat Jun 14, 2003 10:32 PM

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

#37 MestreLion OFFLINE  

MestreLion

    Combat Commando

  • 3 posts
  • Location:Rio de Janeiro, Brazil

Posted Mon Sep 15, 2003 1:45 AM

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

  • horizontal_rainbow.jpg


#38 Jedd OFFLINE  

Jedd

    Star Raider

  • 68 posts
  • Location:Cali

Posted Thu Apr 8, 2004 3:27 AM

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.

#39 Cybergoth OFFLINE  

Cybergoth

    Quadrunner

  • 8,606 posts
  • This is Sparta!
  • Location:Bavaria

Posted Thu Apr 8, 2004 3:32 AM

Hi there!

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

Greetings,
Manuel

#40 Jedd OFFLINE  

Jedd

    Star Raider

  • 68 posts
  • Location:Cali

Posted Thu Apr 8, 2004 3:34 AM

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

#41 kamakazi OFFLINE  

kamakazi

    Dragonstomper

  • 530 posts
  • Location:Moberly, Missouri

Posted Wed Mar 26, 2008 5:28 AM

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...

[codebox]



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



[/codebox]

Help me understand what I did?

Attached Thumbnails

  • kernel.bin.png





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users