# Session 14: Playfield Wierdness

47 replies to this topic

### #1 Andrew DavieOFFLINE

Andrew Davie

Stargunner

• 1,829 posts
• Dr.Boo
• Location:Tasmania

Posted Sun Jun 1, 2003 5:28 AM

The diagram below shows the bizarre way that bits in the TIA playfield registers (PF0, PF2) map to the onscreen pixels in reverse order. We have already seen how PF1 works - it is shown in this diagram, too.

This strange backwardness (not to mention inconsistency!) is probably a result of the fact that it was simpler (cheaper) to design the hardware to operate in this fashion. Among other things, this layout of pixels in our TIA registers makes scrolling horizontally a major pain in the neck!

The bits marked with a cross are not used by the '2600 (including the low bit in the colour registers), and you may write any value to these - it is ignored.

The diagram shows a shadowy "right-side" - where the 20 pixels of the left side are duplicated. Be aware that this right-side may also be mirrored, further complicating things.

### #2 Happy_DudeOFFLINE

Happy_Dude

River Patroller

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

Posted Sun Jun 1, 2003 6:14 AM

Any exercises ?

### #3 Andrew DavieOFFLINE

Andrew Davie

Stargunner

• Topic Starter
• 1,829 posts
• Dr.Boo
• Location:Tasmania

Posted Sun Jun 1, 2003 6:34 AM

Any exercises ?

I'll be delivering this session in stages. I'll give some exercises once I've gotten through the explanations.

If you want to play with some things then....

1. Confirm that PF0 and PF2 have reverse pixel to bit position ordering (Hint: using binary for your values will assist you to see exactly what pixel corresponds to what bit (ie: lda #%01000000, sta PF0)

2. What happens if you write PF0, PF1 or PF2 in the middle of a scanline? What would you expect to happen? Can you see any use for this? (Hint: how do you think an asymmetric playfield - a different pattern on the left and right of the screen - is created?)

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?

4. How would a game do horizontal scrolling? This is a difficult question - but I'm trying to get you to think about the implications of the odd playfield->pixel correspondence, and the implications for game writing.

5. How would you make a "wall" which was 8 scanlines high, full screen width, followed by left and right walls just 1 pixel wide each, at extreme left/right edges of the screen, 176 scanlines high, followed by another horizontal "wall", full screen width and 8 scanlines high?

Note: this would form a "box" border around the entire playfield.

There we go, that should keep you busy!

I'll answer last sessions sessions with example code, shortly.

### #4 Happy_DudeOFFLINE

Happy_Dude

River Patroller

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

Posted Sun Jun 1, 2003 7:26 AM

1: write same value to both PF0 and PF1
```
lda #%00100000

sta PF1

sta PF0

```

```
sleep 40

lda #%00010000

sta PF2

```

### #5 Andrew DavieOFFLINE

Andrew Davie

Stargunner

• Topic Starter
• 1,829 posts
• Dr.Boo
• Location:Tasmania

Posted Sun Jun 1, 2003 7:40 AM

1: write same value to both PF0 and PF1

```
lda #%00100000

sta PF1

sta PF0

```

```
sleep 40

lda #%00010000

sta PF2

```

Happy, if you do these exercises and post your results... please explain in detail what you think you are doing/seeing. It will help others (rather than just pictures and code snippets), and also let me see if you're on the right track. The above samples... don't let me determine that.

In short, a bit more blurb, thanks.

Cheers
A

### #6 Happy_DudeOFFLINE

Happy_Dude

River Patroller

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

Posted Sun Jun 1, 2003 8:25 AM

Alrighty then
I fixed the code to be more obvious
1:
```
lda #%10000000

sta PF1

sta PF0

```
This is showing the relation between PF1 and PF0. both in their 1st position. (now)
They appear as 1 line (because PF0's 1st position is really it's last )

2:
```
sleep 40

lda #%00010000

sta PF2

```
I really didn't think this one through. If you change halfway through the
scan, you'll have to change back at the begining or end of the scan
```
lda #%000100000

sta PF1

sta PF0

sleep 12

lda #%00011100

sta PF0

sta PF1

```
This code changes the playfield mid scan and does what I thought the first
bit of code was doing. Because its iterated 192 times it needs to load each
side of the playfield on every pass...

well hows that for a second attempt ?

### #7 Happy_DudeOFFLINE

Happy_Dude

River Patroller

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

Posted Thu Jun 5, 2003 10:05 AM

Oh yeah I got a "playfield" working
It's ugly but it works

```
;------------------------------------------------

;Top line

lda #15                 ; A nice whitish colour

sta COLUPF

lda #%11111111    ; Fill the whole playfield

sta PF0                  ; left

sta PF1                  ; mid

sta PF2                  ; right

sta WSYNC

sta WSYNC

sta WSYNC

sta WSYNC

sta WSYNC

sta WSYNC

sta WSYNC

sta WSYNC            ; make it 8 scanlines please

lda #%00000000    ; Reset Playfield

sta PF1

sta PF2

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

;Side lines

Picture      lda #15                 ; load up the white

sta COLUPF

lda #%00010000    ; PF0's left

sta PF0

sleep 2                   ; wait for it to draw

lda #\$0

sta COLUPF               ; then kill it

sleep 25                  ; for 25 cycles

lda #15                     ; mmmm White

sta COLUPF               ; Colour Ready to draw some more.

lda #%10000000      ; PF2's right

sta PF2                    ; Now draw the right side and

sta WSYNC              ; Snooze for the rest of the scanline

inx

cpx #176

bne Picture

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

;bottom line - same as top (GOTO TOP to read comments :P )

lda #15

sta COLUPF

lda #%11111111

sta PF0

sta PF1

sta PF2

sta WSYNC

sta WSYNC

sta WSYNC

sta WSYNC

sta WSYNC

sta WSYNC

sta WSYNC

sta WSYNC

lda #%00000000

sta PF1

sta PF2```
As for horizontal scrolling - I wish I knew

### #8 Galaga_FreakOFFLINE

Galaga_Freak

Chopper Commander

• 179 posts
• Location:St. Louis

Posted Thu Jun 5, 2003 7:03 PM

Finally got this to work on a real tv with no flipping

```;Scrolling color border thingy

processor 6502

include "vcs.h"

include "macro.h"

COUNTER1	= \$80

COLOROFFSET     = \$81

TIMETOCHANGE    = 2                   ; speed of "animation"

SEG

ORG \$F000

Reset
; Clear RAM and all TIA registers

ldx #0

lda #0

Clear           sta 0,x

inx

bne Clear

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

; Once-only initialisation...

lda #0

;lda #\$45

sta COLUPF             ; set the playfield colour

StartOfFrame

; Start of vertical blank processing

lda #0

sta VBLANK

lda #2

sta VSYNC

; 3 scanlines of VSYNCH signal...

sta WSYNC

sta WSYNC

sta WSYNC

lda #0

sta VSYNC

; 37 scanlines of vertical blank...

ldx #0

VerticalBlank   sta WSYNC

inx

cpx #36; Now waiting 36 lines

bne VerticalBlank

;do some color offset calcs

ldx #\$02

stx COLUBK;redundant as we never change COLUBK, but... :)

ldx #0

ldy COUNTER1

cpy #TIMETOCHANGE

bne notyet

inc COLOROFFSET

ldy COLOROFFSET

lda #0

sta COUNTER1

notyet

inc COUNTER1

ldy COLOROFFSET

sta WSYNC ;  wait for last line of vblank

DrawField

Top  sty COLUPF

lda #\$FF

sta PF0

sta PF1

sta PF2

lda #0

inx

iny

sta WSYNC

cpx #15

bne Top

SLEEP 3 ; sync up middle

Middle

sty COLUPF

lda #\$F0

sta PF0

lda #0

sta PF1

sta PF2

lda #0

SLEEP 15

sta PF0

lda #\$F0

sta PF2

lda #0

sta WSYNC

inx

iny

cpx #177

bne Middle

Bottom

sty COLUPF

lda #\$FF

sta PF0

sta PF1

sta PF2

sta WSYNC

inx

iny

cpx #192

bne Bottom

lda #%01000010

sta VBLANK                     ; end of screen - enter blanking

ldx #0

stx COLUPF

Overscan        sta WSYNC

inx

cpx #30

bne Overscan

jmp StartOfFrame

ORG \$FFFA

.word Reset          ; NMI

.word Reset          ; RESET

.word Reset          ; IRQ

END```

Now this has worked for a while on the emulators, but I came to discover that my vblank period was off because of the offset code which I assume put the rest of the frame out of sync slightly each pass which eventually caused the screen to hop or roll on a real tv (using cuttle cart).

I fixed this once but then noticed that my scanline count was 264 not 262 as the code above produces. This actually worked on my tv, so my question is: How far out of the range of 262 can you be for the game to work on most tvs (NTSC) or is it a matter of the atari used (jr vs 4 switcher for example)? Also, is there a way to reproduce the effects (flipping, etc) on an emulator that you would see on a tv other than counting scanlines?

### #9 Happy_DudeOFFLINE

Happy_Dude

River Patroller

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

Posted Thu Jun 5, 2003 8:21 PM

I'd like to know how that works with 384 in picture scanlines ?
I was under the impression stella only had 242 scanlines at the most (pal)

### #10 Galaga_FreakOFFLINE

Galaga_Freak

Chopper Commander

• 179 posts
• Location:St. Louis

Posted Thu Jun 5, 2003 8:39 PM

I'd like to know how that works with 384 in picture scanlines ?
I was under the impression stella only had 242 scanlines at the most (pal)

Where did you get 384? There's 3 vsych + 37 vblank + 192 picture + 30 overscan = 262 total scanlines of which only 192 are visible

### #11 Happy_DudeOFFLINE

Happy_Dude

River Patroller

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

Posted Thu Jun 5, 2003 8:47 PM

I'd like to know how that works with 384 in picture scanlines ?
I was under the impression stella only had 242 scanlines at the most (pal)

Where did you get 384? There's 3 vsych + 37 vblank + 192 picture + 30 overscan = 262 total scanlines of which only 192 are visible

Mabey I'm reading it wrong but ....
```
Top      sty COLUPF

lda #\$FF

sta PF0

sta PF1

sta PF2

lda #0

inx

iny

sta WSYNC

cpx #15

bne Top

SLEEP 3 ; sync up middle

Middle

sty COLUPF

lda #\$F0

sta PF0

lda #0

sta PF1

sta PF2

lda #0

SLEEP 15

sta PF0

lda #\$F0

sta PF2

lda #0

sta WSYNC

inx

iny

cpx #177

bne Middle

Bottom

sty COLUPF

lda #\$FF

sta PF0

sta PF1

sta PF2

sta WSYNC

inx

iny

cpx #192

bne Bottom  ```
15 lines for the top 177 scanlines for the middle and 192 for the bottom = 384 not including overscan and vblank.

### #12 Galaga_FreakOFFLINE

Galaga_Freak

Chopper Commander

• 179 posts
• Location:St. Louis

Posted Thu Jun 5, 2003 8:54 PM

Ahh, I see how you got that number now.

The x index register is never reset so after the top is done x = 15, after middle x = 177 after bottom x = 192. Basically it is the counter for the entire visible portion, not individual portions of the visible screen. :wink:

### #13 Happy_DudeOFFLINE

Happy_Dude

River Patroller

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

Posted Thu Jun 5, 2003 9:06 PM

I see now

### #14 Happy_DudeOFFLINE

Happy_Dude

River Patroller

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

Posted Thu Jun 5, 2003 9:36 PM

Galaga_Freak if COLUBK is never changed you should initalize it after Clear and before StartOfFrame.
No use doing it once every frame

I cleaned my code up a bit. There was a lot of weirdness going on.

```
;------------------------------------------------

;Top line

lda #%11111111         ;fill playfield

sta PF0

sta PF1

sta PF2

lda #15                ; It looks like white

sta WSYNC              ; all thats visable so wait

sta COLUPF             ; before writing the line

sta WSYNC

sta WSYNC

sta WSYNC

sta WSYNC

sta WSYNC

sta WSYNC

sta WSYNC              ; Give me 7

lda #%00000000         ; Clear the 2 PF's that arn't PF0

sta PF1

sta PF2

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

;Side lines

Picture         lda #15                ; Re-initalize whiteness

sta COLUPF

lda #%00010000         ; And PF0

sta PF0

sleep 2                ; let it write

lda #\$0                ; now get rid of the damn thing

sta COLUPF

sleep 25               ; and wait until the reflected bit has been written black

lda #15                ; and Re-initalize the colour (again)

sta COLUPF

lda #%10000000         ; Line up PF2

sta PF2

sta WSYNC              ; wait till end of scanline

inx

cpx #176

bne Picture            ; do it till it's done

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

lda #15

sta COLUPF

lda #%11111111

sta PF0

sta PF1

sta PF2

sta WSYNC

sta WSYNC

sta WSYNC

sta WSYNC

sta WSYNC

sta WSYNC

sta WSYNC

sta WSYNC

lda #\$0               ; Clear to return

sta COLUPF

```

### #15 Thomas JentzschOFFLINE

Thomas Jentzsch

Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

• 23,869 posts
• Always left from right here!
• Location:Düsseldorf, Germany, Europe, Earth

Posted Fri Jun 6, 2003 1:06 AM

This actually worked on my tv, so my question is:  How far out of the range of 262 can you be for the game to work on most tvs (NTSC) or is it a matter of the atari used (jr vs 4 switcher for example)?

That's a question hard to answer. The scanline range of NTSC games I have seen so far is somewhere between 241 (Artillery Duel, a few people have reported problems here!) and ~280 scanlines (e.g. Desert Falcon).

And many TV (especially with a vertical hold) can even display PAL games (standard: 312 scanlines, but there are some with up to 342 scanlines like Acid Drop).

So I assume +/- 15..20 scanlines should be no problem.

### #16 8BIT 1337OFFLINE

8BIT 1337

Chopper Commander

• 209 posts

Posted Fri Jun 6, 2003 10:11 AM

That's a question hard to answer. The scanline range of NTSC games I have seen so far is somewhere between 241 (Artillery Duel, a few people have reported problems here!) and ~280 scanlines (e.g. Desert Falcon).

And many TV (especially with a vertical hold) can even display PAL games (standard: 312 scanlines, but there are some with up to 342 scanlines like Acid Drop).

So I assume +/- 15..20 scanlines should be no problem.

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. Or is there something else that comes into play that I'm not aware of? (I'm just talking NTSC numbers here).

Another semi-related question - what if I decided to 'use' all my overscan time under VBlank? Why do the non-picture scanlines get split before/after the picture? (Or is that just a best practices standard - if so, what game(s) have done this out of curiousity?)

### #17 Thomas JentzschOFFLINE

Thomas Jentzsch

Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

• 23,869 posts
• Always left from right here!
• Location:Düsseldorf, Germany, Europe, Earth

Posted Fri Jun 6, 2003 12:46 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

Another semi-related question - what if I decided to 'use' all my overscan time under VBlank?  Why do the non-picture scanlines get split before/after the picture?

This is done to center the visible part on the screen. After OverScan we are doing a Vertical Sync to bring the beam back to the top of the screen. So both parts (called Overscan and VBLank) below and above the visible area are about the same size.

### #18 8BIT 1337OFFLINE

8BIT 1337

Chopper Commander

• 209 posts

Posted Fri Jun 6, 2003 1:45 PM

This is done to center the visible part on the screen. After OverScan we are doing a Vertical Sync to bring the beam back to the top of the screen. So both parts (called Overscan and VBLank) below and above the visible area are about the same size.

I understand what you're saying, but I've played with this a bit (I had a simple playfield with only one scanline of overscan, the rest under VBLANK) and the image was still centered as far as I can tell. Was that 'cause I was using an emulator?

### #19 Thomas JentzschOFFLINE

Thomas Jentzsch

Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

• 23,869 posts
• Always left from right here!
• Location:Düsseldorf, Germany, Europe, Earth

Posted Fri Jun 6, 2003 1:53 PM

I understand what you're saying, but I've played with this a bit (I had a simple playfield with only one scanline of overscan, the rest under VBLANK) and the image was still centered as far as I can tell.

Did you increase the VBlank time then and still had 262 scanlines?

If you only cut some blank lines at the bottom you won't notice that.

### #20 8BIT 1337OFFLINE

8BIT 1337

Chopper Commander

• 209 posts

Posted Fri Jun 6, 2003 2:04 PM

Did you increase the VBlank time then and still had 262 scanlines?

If you only cut some blank lines at the bottom you won't notice that.

Yup - I made sure my total scanlines were still 262 (using z26 to verify my math was correct).

Seems like it would be simpler to use the 67 scanlines all together in one place instead of splitting code up into the 37 VBlank and 30 Overscan portions. Generally speaking of course.

### #21 Thomas JentzschOFFLINE

Thomas Jentzsch

Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

• 23,869 posts
• Always left from right here!
• Location:Düsseldorf, Germany, Europe, Earth

Posted Fri Jun 6, 2003 3:49 PM

Looks like the emulator did some centering then. Definitely won't work that way on the real thing.

### #22 dew2050OFFLINE

dew2050

• 32 posts

Posted Fri Jun 6, 2003 5:43 PM

Any exercises ?

4. How would a game do horizontal scrolling? This is a difficult question - but I'm trying to get you to think about the implications of the odd playfield->pixel correspondence, and the implications for game writing.

I modified the kernel code to use ASL commands to shift the bits in my playfield variable to the left. Since I didn't want the playfield to repeat itself twice on the screen, I added a second variable to the original kernel lesson sample.

The code only uses PF0 to draw the screen. The result is that the playfield scrolls horizontally from left to right, jumping the center and edges of the screen (everything else not drawned by PF0). The scrolling feels a lot like Vanguard. It's not smoothy like say, Chopper Command. I think for that you would need to use the HMOVE register with something other than the playfield, but that's ok for now.

On PCAEWIN it works fine, but on Z26 it draws some garbage at the top of the screen. Take a look at the code:

```; 2600 for Newbies
; lesson 14 - playfield
; Question 4 - One way to do horizontal scrolling with the playfield.

processor 6502

include "vcs.h"

include "macro.h"

; OBJECTIVE:  This variation of the lesson 14 kernel does horizontal scrolling with the playfield.
;  Only PF0 is used. The program uses to variables to store the left and right side values
;  of the playfield. These are declared below:

PATTERN_LEFT	= \$80

PATTERN_RIGHT	= \$82

TIMETOCHANGE	= 20

SEG

ORG \$F000

RESET

; Clear RAM and all TIA regs

LDX #0

LDA #0

CLEAR

STA 0,X

INX

BNE CLEAR

LDA #\$45

STA COLUPF

LDY #0

; Here we assign the pattern values to our left and right side of the playfield.
; Try using different values.

LDA #\$0

STA PATTERN_LEFT

LDA #\$01

STA PATTERN_RIGHT

STARTOFFRAME

LDA #0

STA VBLANK

LDA #2

STA VSYNC

STA WSYNC

STA WSYNC

STA WSYNC

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
; WRITE THE PATTERN TO PF1

INY

CPY #TIMETOCHANGE

BNE SCROLLCOMPLETE

LDY #0

; The following code uses arithmetic left shift commands (ASL) to make the scrolling happen.
; We shift the bits of the playfield variables to the left. Original bit 7 is shifted to the Carry.
; The program uses BCC to check if a bit was dropped. Dropped bits are inserted to the
; opposite pattern variable by the INC command. The INC command can mess up the pattern if
; the original bit 0 is turned on. To avoid this we shift everything to the left before incrementing.

SHIFTRIGHT

CLC

ASL PATTERN_RIGHT

BCC SHIFTLEFT

ASL PATTERN_LEFT

INC PATTERN_LEFT

BCC SCROLLCOMPLETE

INC PATTERN_RIGHT

JMP SCROLLCOMPLETE

SHIFTLEFT

ASL PATTERN_LEFT

BCC SCROLLCOMPLETE

INC PATTERN_RIGHT

SCROLLCOMPLETE

; DO 192 SCANLINES OF COLOR CHANGING (OUR PICTURE)

LDX #0

PICTURE

STX COLUPF

; Load the left pattern into PF1 register.

LDA PATTERN_LEFT

STA PF1

; Wait enough cycles before drawing right pattern.

SLEEP 20

; Load right pattern to PF1.

LDA PATTERN_RIGHT

STA PF1

STA WSYNC

INX

CPX #192

BNE PICTURE

LDA #%01000010

STA VBLANK

; 30 LINES OF OVERSCAN

LDX #0

OVERSCAN

STA WSYNC

INX

CPX #30

BNE OVERSCAN

JMP STARTOFFRAME

ORG \$FFFA

INTERRUPTVECTORS

.WORD RESET

.WORD RESET

.WORD RESET

END

```

The tricky code is the bit shifting. Here is the pseudocode:

```[color=blue]; Pseudocode:
;
; Clear Carry
; Shift bits in variable PATTERN_RIGHT to the left. Original bit 7 is shifted into the Carry.
;
; if no bit was dropped from PATTERN_RIGHT (Carry Clear) then
;
;	Shift the bits in PATTERN_LEFT
;	if no bit was dropped from PATTERN_LEFT then
;
;  Scroll is complete. Continue program flow.
;
;	else
;
;  Insert dropped bit from left pattern into PATTERN_RIGHT (Using the INC command).
;
;	end
;
; else
;
;	Shift bits in PATTERN_LEFT
;	Insert dropped bit from right pattern into PATTERN_LEFT.
;	If no bit was dropped from PATTERN_LEFT then
;
;  Scroll is complete.
;
;	else
;
;  Insert dropped bit from left pattern into PATTERN_RIGHT.
;
;	end
;
; end[/color]```

This translates to:

```SHIFTRIGHT

CLC

ASL PATTERN_RIGHT

BCC SHIFTLEFT

ASL PATTERN_LEFT

INC PATTERN_LEFT

BCC SCROLLCOMPLETE

INC PATTERN_RIGHT

JMP SCROLLCOMPLETE

SHIFTLEFT

ASL PATTERN_LEFT

BCC SCROLLCOMPLETE

INC PATTERN_RIGHT

SCROLLCOMPLETE```

I am sure there is a better way of doing this without so many BCC's and ASL's (perhaps getting rid of the JMP altogether).

### #23 Thomas JentzschOFFLINE

Thomas Jentzsch

Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

• 23,869 posts
• Always left from right here!
• Location:Düsseldorf, Germany, Europe, Earth

Posted Sat Jun 7, 2003 1:35 AM

I am sure there is a better way of doing this without so many BCC's and ASL's (perhaps getting rid of the JMP altogether).

Hint: Have a look at ROL.

This will make your code much simplier.

### #24 ZachOFFLINE

Zach

Stargunner

• 1,620 posts

Posted Sat Jun 7, 2003 2:57 AM

Thanks Andrew,

It took me a lot of frustrating trial and error before I concluded that the bits in PF2 were displayed in reverse. I'm glad someone is making the TIA's quirks clear.

Zach

### #25 dew2050OFFLINE

dew2050

• 32 posts

Posted Sat Jun 7, 2003 9:38 AM

I am sure there is a better way of doing this without so many BCC's and ASL's (perhaps getting rid of the JMP altogether).

Hint: Have a look at ROL.

This will make your code much simplier.

Thanks Thomas. With your help I was able to take this:

```CLC

ASL PATTERN_RIGHT

BCC SHIFTLEFT

ASL PATTERN_LEFT

INC PATTERN_LEFT

BCC SCROLLCOMPLETE

INC PATTERN_RIGHT

JMP SCROLLCOMPLETE

SHIFTLEFT

ASL PATTERN_LEFT

BCC SCROLLCOMPLETE

INC PATTERN_RIGHT

SCROLLCOMPLETE

```

Into this:

```CLC

ROL PATTERN_RIGHT

ROL PATTERN_LEFT

BCC SCROLLCOMPLETE

INC PATTERN_RIGHT

SCROLLCOMPLETE```

Wow, what a difference ROL makes! I am glad I did it the hard way first, otherwise I wouldn't had appreciated the difference. I have a newbie assembler question: How many machine cycles does the ROL commands above take? Is it 5 for zero page?

#### 0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users