Asymmetric playfield problem

[jbs30000]

Hi. Although I'm not new to programming, or even 2600 programming, I am new to 2600 asm programming.

 

I've been following along with the tutorials made by Andrew Davie. They're fantastic and easy to follow. But I've come upon a strange problem.

 

I'm on chapter 20, which is asymmetric playfields. I wrote code, OK, mostly copied code, to display my own 40x192 playfield. When I first ran the program the playfield was upside down, but otherwise displayed right. So I flipped the playfield, re-ran the FSB program to create playfield data and re-assembled the program. Now the image isn't quiet drawn correctly.

 

Here is the upside down version and here is the right-side up version

 

Here is the asm file Test.asm

and if it will help, the image data Test1.asm

 

Thank you.

Edited December 1, 2011 by jbs30000

[RevEng]

The glitch at the top of the screen is because you're not clearing PF0,PF1, and PF2 at the end of each frame, so it's displaying the last data in those registers at the top.

 

The glitch at the bottom of the screen is because your data crosses a page boundary... when you're loading PF data and the page boundary is crossed an extra cycle is needed, throwing off the timing of your kernel.

 

A quick fix is to add "align 256" strategically above data to ensure it doesn't do this, though a less wasteful solution is to explicitly place the data in specific locations so this doesn't happen.

[jbs30000]

Oh, and to make sure that it wasn't the image file that was the problem, I reused the image file that was displaying upside down and changed the code in the test program to display it right side up. It looks better, but it has some garbage on the top of the screen.

 

I guess I'm having a hard time telling if it's the image or the code to display it.

[jbs30000]

The glitch at the top of the screen is because you're not clearing PF0,PF1, and PF2 at the end of each frame, so it's displaying the last data in those registers at the top.

 

The glitch at the bottom of the screen is because your data crosses a page boundary... when you're loading PF data and the page boundary is crossed an extra cycle is needed, throwing off the timing of your kernel.

 

A quick fix is to add "align 256" strategically above data to ensure it doesn't do this, though a less wasteful solution is to explicitly place the data in specific locations so this doesn't happen.

Sorry, for some reason when I posted my second post, I didn't see this one.

 

OK, so do I place the data in a specific location by using the SEG and ORG directives? Or maybe just ORG?

 

Thank you.

Edited December 1, 2011 by jbs30000

[jbs30000]

Just to add, I tried a SEG ORG $F100 which is exactly 256 bytes after the start of the kernel (the kernel ends at $F099). The screen look exactly like the screen in post 3.

[Joe Musashi]

You do not need the SEG at the beginning, only ORG $F000.

 

In Test1.asm put an "align 256" in front of every strip label:

 

align 256

Test1_STRIP_0

.byte 255

...

align 256

Test1_STRIP_1

.byte 255

...

 

And since you are using an inverted playfield you need to add

 

lda #$FF

sta PF0

sta PF1

sta PF2

 

after sta VBLANK. That should fix it.

[RevEng]

To save a bit of rom, you can throw in a check to ensure its only done when the data is crossing a boundary. I also like to include a message to let me know how many bytes the padding wasted...

 

  if >. != >[.+192]
pad1start
  align 256
pad1end
  echo "padding 1 wasted ",(pad1end-pad1start)," bytes"
  endif

[jbs30000]

You do not need the SEG at the beginning, only ORG $F000.

 

In Test1.asm put an "align 256" in front of every strip label:

 

align 256

Test1_STRIP_0

.byte 255

...

align 256

Test1_STRIP_1

.byte 255

...

 

And since you are using an inverted playfield you need to add

 

lda #$FF

sta PF0

sta PF1

sta PF2

 

after sta VBLANK. That should fix it.

 

OK, I did what you said, and it looks a lot better, but there is a line that goes across most of the top of the screen.

 

I've been checking my code against what the tutorial and what you and RevEng have been saying, and it appears to match, but apparently I have done something wrong. If you, or somebody, wouldn't mind checking my code one last time I would really appreciate it. I'm sure it must be a tiny error. Thank you.

 

I'll just post the program code, as the image code is what I posted with align 256 added before each data table.

Test.asm

[jbs30000]

Nevermind, I'm a moron.

Edited December 2, 2011 by jbs30000

[jbs30000]

OK, I found a solution. Before Test1_STRIP_0 I put ORG $F100. Before Test1_STRIP1 I put ORG $F200, and so on.

 

I thought that doing that would do the same thing as putting an align 256 before each data table, but apparently not.

[RevEng]

OK, I found a solution. Before Test1_STRIP_0 I put ORG $F100. Before Test1_STRIP1 I put ORG $F200, and so on.

 

I thought that doing that would do the same thing as putting an align 256 before each data table, but apparently not.

 

Not sure what went wrong, but it should. I use this very same approach (the conditional one) with strips of bitmap data in the bB titlescreen kernel module, since I can't dictate what ORG the data will eventually wind up at. Never had a problem with it.

[GroovyBee]

You are starting your reads from the tables at index 192. However, only indexes 0 through to 191 have valid data. To correct this problem change all the "lda Test1_STRIP_0,x" instructions to "lda Test1_STRIP_0-1,x" (repeat for all the strips). I know that doesn't look right but you actually terminate the loop after a pass where X is equal to 1. There is no pass through the loop with X equal to 0 meaning you have an out by one error.

[Joe Musashi]

I don't know if you got it running by now, but here is what I used to create the above image. It's a modification of your first Test.asm. Since this uses an incrementing loop, it runs from 0 to 191 and avoids the issue GroovyBee mentioned.

 

I also included the listing created by dasm (add -lTest.lst, I renamed it to Test.list.asm so that I could upload it). It can be seen that the aligns work as expected, strip 0 at $F100, strip 1 at $F200 and so on.

Test.asm

Test1.asm

Test.list.asm

[jbs30000]

I don't know if you got it running by now, but here is what I used to create the above image. It's a modification of your first Test.asm. Since this uses an incrementing loop, it runs from 0 to 191 and avoids the issue GroovyBee mentioned.

 

I also included the listing created by dasm (add -lTest.lst, I renamed it to Test.list.asm so that I could upload it). It can be seen that the aligns work as expected, strip 0 at $F100, strip 1 at $F200 and so on.

 

Yes, adding the ORG statements made the program run fine, but I will check out what you did. Thank you.