Modifying the Playfield using var0 through var 47

[CurtisP]

As I was looking for ways to rapidly update large sections of the playfield, it occured to me that I could just use the varXX variables. I decided to go with a different method anyway, but though I would go ahead and share this.

 

Of course this won't work if you are compiling for the Supership and it's not guaranteed to work with future versions, but it does work well.

 

Each of the varXX variables correspond to an eight pixel portion of the playfield.

Their positions and bit positions are as follows:

 

 

Line 7654321 1234567 7654321 1234567

. 1- .var0.. .var1.. .var2.. .var3..

. 2- .var4.. .var5.. .var6.. .var7..

. 3- .var8.. .var9.. .var10. .var11.

. 4- .var12. .var13. .var14. .var15.

. 5- .var16. .var17. .var18. .var19.

. 6- .var20. .var21. .var22. .var23.

. 7- .var24. .var25. .var26. .var27.

. 8- .var28. .var29. .var30. .var31.

. 9- .var32. .var33. .var34. .var35.

.10- .var36. .var37. .var38. .var39.

.11- .var40. .var41. .var42. .var43.

.12- .var44. .var45. .var46. .var47.

[SeaGtGruff]

As I was looking for ways to rapidly update large sections of the playfield, it occured to me that I could just use the varXX variables. I decided to go with a different method anyway, but though I would go ahead and share this.

 

Of course this won't work if you are compiling for the Supership and it's not guaranteed to work with future versions, but it does work well.

 

Each of the varXX variables correspond to an eight pixel portion of the playfield.

Their positions and bit positions are as follows:

 

 

Line 7654321 1234567 7654321 1234567

. 1- .var0.. .var1.. .var2.. .var3..

. 2- .var4.. .var5.. .var6.. .var7..

. 3- .var8.. .var9.. .var10. .var11.

. 4- .var12. .var13. .var14. .var15.

. 5- .var16. .var17. .var18. .var19.

. 6- .var20. .var21. .var22. .var23.

. 7- .var24. .var25. .var26. .var27.

. 8- .var28. .var29. .var30. .var31.

. 9- .var32. .var33. .var34. .var35.

.10- .var36. .var37. .var38. .var39.

.11- .var40. .var41. .var42. .var43.

.12- .var44. .var45. .var46. .var47.

Yes, that's a good idea. In fact, it's more or less how the "playfield:" command works, except it does the entire playfield, not just a section of it. So you should be able to write some subroutines (or user functions?) that update just a portion of the playfield in the same way-- like changing all of the bytes in just one column, or just one row, or maybe even some rectangular area of the playfield (which is probably a better generic approach). It would work fastest if you code it using inline assembly.

 

Michael

 

PS -- There's no reason why it shouldn't work with a Superchip playfield, too, if you use the base address of the playfield.

Edited April 9, 2007 by SeaGtGruff

[yuppicide]

Has anyone confirmed this works with the Superchip or not?

 

I'm needing to do PFVLINE, but it's not working so I thought I'd try this method.. only problem is I am using pfres=27.

[SeaGtGruff]

Has anyone confirmed this works with the Superchip or not?

 

I'm needing to do PFVLINE, but it's not working so I thought I'd try this method.. only problem is I am using pfres=27.

If I remember correctly, the Superchip playfield doesn't use the same variable names as the standard playfield for all the individual bytes-- it just uses a variable name for the beginning of the playfield, and uses an index with that variable name to change specific bytes. That's also how the kernel works with the standard playfield, by the way.

 

The advantage of using individual variable names is that you don't need to use an indexed addressing mode. On the other hand, if you're going to be doing some kind of generic playfield processing, you need to use an index anyway! The only kind of situation I can think of that *wouldn't* need an index is where there are specific playfield bytes that you want to change, such that you can refer to the specific variable name for the individual byte.

 

Anyway, there is one important thing you need to know about modifying the Superchip playfield directly, which is that the Superchip RAM has one set of addresses for reading the RAM, and another set of addresses for writing to the RAM. I'll post some example code later this evening.

 

Michael

[+Random Terrain]

Anyway, there is one important thing you need to know about modifying the Superchip playfield directly, which is that the Superchip RAM has one set of addresses for reading the RAM, and another set of addresses for writing to the RAM. I'll post some example code later this evening

That will be cool. I might actually try messing around with a Superchip game with that kind of useful info.

[SeaGtGruff]

Okay, here's a sample program that shows a Superchip playfield with 32 pfrows. The last pfrow is normally hidden by the score, but I scrolled the playfield up a line so only part of the first pfrow is visible, such that part of the last pfrow is also visible. (Not that it has anything to do with the topic at hand.)

 

   rem * Modifying the Superchip Playfield Directly

  set romsize 8kSC

  set kernel_options no_blank_lines

  const pfres = 32

  playfield:
  ................................
  XXXXX.X....X....................
  ..X...X.........................
  ..X...X.X..X..XXX...............
  ..X...XX.X.X.X..................
  ..X...X..X.X..XX................
  ..X...X..X.X....X...............
  ..X...X..X.X.XXX................
  ................................
  ................................
  ................................
  .X...X....X...............X.....
  .X...X..........................
  XXXX.X.X..X.X.X...XX......X..XXX
  .X...XX.X.X.XX.X.X..X.....X.X...
  .X...X..X.X.X..X.X..X.....X..XX.
  .X.X.X..X.X.X..X.X..X.....X....X
  ..X..X..X.X.X..X..XXX.....X.XXX.
  ....................X...........
  ..................XX............
  ................................
  ......................X...X.....
  ......................X...X.....
  .XXX.X.X.X..XX...XX..XXXX.X.....
  X....X.X.X.X..X.X..X..X...X.....
  .XX..X.X.X.XXXX.XXXX..X...X.....
  ...X.X.X.X.X....X.....X.X.......
  XXX...X.X...XXX..XXX...X..X.....
  ................................
  ................................
  ................................
  XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end

  pfscroll up

  COLUBK = $02
  COLUPF = $1A

loop

  drawscreen

  goto loop

If we generate an assembly listing when compiling this code, we can search the listing for "playfield" and find the following bit of code in it:

 

	197  3000 ????					  ifconst	superchip
198  3000 ????		   10 d0	   playfieldbase =	$10D0
199  3000 ????			  -		  else
200  3000 ????			  -playfieldbase =	$A4
201  3000 ????					  endif
202  3000 ????
203  3000 ????					; define playfield start based on height
204  3000 ????			  -		  ifnconst	pfres
205  3000 ????			  -playfield  =	playfieldbase
206  3000 ????					  else
207  3000 ????		   10 80	   playfield  =	playfieldbase-(pfres-12)*4
208  3000 ????					  endif

What that does is set a constant named "playfieldbase" to a value (or address) of $10D0, which is in the Superchip RAM. (If the Superchip option were *not* being used, "playfieldbase" would have been set to $A4 instead.) Then, since we're using the "pfres" constant to get a higher-res playfield, it calculates the address for another constant named "playfield," based on the values of "playfieldbase" and "pfres." All of that is behind the scenes, and you don't need to worry about it, except to be aware that there's a constant named "playfield" which tells bB where the playfield's RAM is kept. In this particular case, the starting address of the playfield's RAM ends up being $1080, which is in the middle of the Superchip RAM area. Actually, it's at the very beginning of the Superchip's 128 bytes of RAM, but the RAM area is "doubled up" in the address space so that it takes up 256 bytes, because the first 128 bytes ($1000 through $107F) are used for writing to the Superchip RAM, and the second 128 bytes ($1080 through $10FF) are used for reading from the Superchip RAM.

 

Now that bB has automatically calculated the address of "playfield" for itself, we can use the "playfield" constant ourselves to directly modify the Superchip playfield. As long as we just want to *read* bytes from the Superchip playfield, we can use the "playfield" constant by itself, since it points to the playfield's read area. But we want to *write* to it, so we really need to make another constant for ourselves that points to the playfield's write area. (bB just subtracts 128 from "playfield," but we can't do that in bB statements, and we'd rather not have to resort to inline assembly.) So let's call it "pokepf" (i.e., poke the playfield):

 

   const pokepf = playfield-128

Now we can use "pokepf" to poke values directly into the Superchip playfield's bytes. The best way to do this generically would be to use an index (i.e., bB's array format). For example, the following program simultaneously draws four vertical lines down the right side of the Superchip playfield:

 

   rem * Modifying the Superchip Playfield Directly

  set romsize 8kSC

  set kernel_options no_blank_lines

  const pfres = 32
  const pokepf = playfield-128

  pfclear

  for a = 3 to 127 step 4
  pokepf[a] = %10101010
  next

  COLUBK = $02
  COLUPF = $1A

loop

  drawscreen

  goto loop

Note that we're poking an entire byte-- or 8 pfpixels-- at once, so the binary value will define the pattern being poked into the playfield bytes.

 

By the way, it must also be noted that some of the PF registers are "backwards" or reflected:

 

left copy of PF1 = normal bit order (left-to-right)

left copy of PF2 = reversed bit order (right-to-left)

right copy of PF2 = normal bit order (left-to-right)

right copy of PF1 = reversed bit order (right-to-left)

 

So when we poke %10101010 into the last byte on each pfrow (i.e., the right copy of PF1), the bits are in reverse order-- the first "1" after the "%" is turning on the pfpixel in pfcolumn 31, the second "1" is turning on the pfpixel in pfcolumn 29, the third "1" is turning on the pfpixel in pfcolumn 27, and the fourth "1" is turning on the pfpixel in pfcolumn 25.

 

Michael

[yuppicide]

So how would I take your code and make it so random blocks are missing? I am thinking something like this:

 

main
  i=rand
  if i< 1  || i>4 then goto main
  if i=1 then goto one
  if i=2 then goto two
  if i=3 then goto three
  if i=4 then goto four

  for a = 3 to 127 step 4
one
  pokepf[a] = %11111100
  goto main2
two
  pokepf[a] = %11110011
  goto main2

three
  pokepf[a] = %11001111
  goto main2

four
  pokepf[a] = %00111111

main2
	 next

  COLUBK = $02
  COLUPF = $1A

loop

  drawscreen

  goto loop

 

I can't seem to get that working. How would I position that line elsewhere? I need just one line moving left with my two blocks missing.

[+Random Terrain]

Thanks for the info SeaGtGruff. I can get almost halfway there on my own and then I get lost in the woods.

 

By the way, it must also be noted that some of the PF registers are "backwards" or reflected:

 

left copy of PF1 = normal bit order (left-to-right)

left copy of PF2 = reversed bit order (right-to-left)

right copy of PF2 = normal bit order (left-to-right)

right copy of PF1 = reversed bit order (right-to-left)

That's how it is without Superchip RAM too. Freaked me out when I first noticed it. "What in the heck?!! Am I on drugs?!!"

 

 

Note that we're poking an entire byte-- or 8 pfpixels-- at once, so the binary value will define the pattern being poked into the playfield bytes.

Are we stuck using bytes or can we change only certain bits too without changing anything else?

[+Random Terrain]

I can't seem to get that working. How would I position that line elsewhere? I need just one line moving left with my two blocks missing.

With every BASIC style language I have ever used, you can't jump into the center of a for-next loop like that.

[+Random Terrain]

I can't seem to get that working. How would I position that line elsewhere? I need just one line moving left with my two blocks missing.

If you're talking about the same example, just turned random, you'd use something like this:

 

 

  rem * Modifying the Superchip Playfield Directly

  set romsize 8kSC

  set kernel_options no_blank_lines

  dim rand16=z

  const pfres = 32
  const pokepf = playfield-128

  pfclear

  for a = 3 to 127 step 4
  pokepf[a] = rand
  next

  COLUBK = $02
  COLUPF = $1A

loop

  drawscreen

  goto loop

[SeaGtGruff]

So how would I take your code and make it so random blocks are missing?

 

[...]

 

I can't seem to get that working. How would I position that line elsewhere? I need just one line moving left with my two blocks missing.

It's like Random Terrain said, you can't jump into the middle of the for...next loop like that (with the if). You would need to rearrange a few statements, and you could also simplify the random number selection, as follows:

 

main

  i = rand & %00000111

  if i = 0 then i = %11111100
  if i = 1 then i = %11110011
  if i = 2 then i = %11001111
  if i = 3 then i = %00111111

  for a = 3 to 127 step 4

  pokepf[a] = i

  next

  COLUBK = $02
  COLUPF = $1A

loop

  drawscreen

  goto loop

I'm not sure if that does what you want it to do, but I think it does what it looked like you were trying to do.

 

Michael

[SeaGtGruff]

By the way, it must also be noted that some of the PF registers are "backwards" or reflected:

 

left copy of PF1 = normal bit order (left-to-right)

left copy of PF2 = reversed bit order (right-to-left)

right copy of PF2 = normal bit order (left-to-right)

right copy of PF1 = reversed bit order (right-to-left)

That's how it is without Superchip RAM too. Freaked me out when I first noticed it. "What in the heck?!! Am I on drugs?!!"

It's the way the playfield registers are designed to be read by the TIA in the Atari 2600. But it also depends on what kind of playfield you're using.

 

With a repeated or non-reflected playfield, it's as follows:

 

left copy of PF0 = reversed bit order (right-to-left)

left copy of PF1 = normal bit order (left-to-right)

left copy of PF2 = reversed bit order (right-to-left)

right copy of PF0 = reversed bit order (right-to-left)

right copy of PF1 = normal bit order (left-to-right)

right copy of PF2 = reversed bit order (right-to-left)

 

With a reflected playfield, it's as follows:

 

left copy of PF0 = reversed bit order (right-to-left)

left copy of PF1 = normal bit order (left-to-right)

left copy of PF2 = reversed bit order (right-to-left)

right copy of PF2 = normal bit order (left-to-right)

right copy of PF1 = reversed bit order (right-to-left)

right copy of PF0 = normal bit order (left-to-right)

 

bB uses a reflected playfield, although the kernel doesn't use PF0, and the PF1 and PF2 registers are updated between the left and right halves of the screen to get an asymmetric playfield.

 

Note that we're poking an entire byte-- or 8 pfpixels-- at once, so the binary value will define the pattern being poked into the playfield bytes.

Are we stuck using bytes or can we change only certain bits too without changing anything else?

If you want to change some bits without changing the rest of the byte, you'd need to use bit operations. But if you're going to do that, then it might be just as fast (and probably easier) to just use pfvline instead-- depending on whether you wanted to change just one bit in each byte, or more than one bit at once.

 

If you wanted, you could even write a routine to draw a diagonal line.

 

Michael

[+Random Terrain]

By the way, it must also be noted that some of the PF registers are "backwards" or reflected:

 

left copy of PF1 = normal bit order (left-to-right)

left copy of PF2 = reversed bit order (right-to-left)

right copy of PF2 = normal bit order (left-to-right)

right copy of PF1 = reversed bit order (right-to-left)

That's how it is without Superchip RAM too. Freaked me out when I first noticed it. "What in the heck?!! Am I on drugs?!!"

It's the way the playfield registers are designed to be read by the TIA in the Atari 2600. But it also depends on what kind of playfield you're using.

 

With a repeated or non-reflected playfield, it's as follows:

 

left copy of PF0 = reversed bit order (right-to-left)

left copy of PF1 = normal bit order (left-to-right)

left copy of PF2 = reversed bit order (right-to-left)

right copy of PF0 = reversed bit order (right-to-left)

right copy of PF1 = normal bit order (left-to-right)

right copy of PF2 = reversed bit order (right-to-left)

 

With a reflected playfield, it's as follows:

 

left copy of PF0 = reversed bit order (right-to-left)

left copy of PF1 = normal bit order (left-to-right)

left copy of PF2 = reversed bit order (right-to-left)

right copy of PF2 = normal bit order (left-to-right)

right copy of PF1 = reversed bit order (right-to-left)

right copy of PF0 = normal bit order (left-to-right)

 

bB uses a reflected playfield, although the kernel doesn't use PF0, and the PF1 and PF2 registers are updated between the left and right halves of the screen to get an asymmetric playfield.

 

Note that we're poking an entire byte-- or 8 pfpixels-- at once, so the binary value will define the pattern being poked into the playfield bytes.

Are we stuck using bytes or can we change only certain bits too without changing anything else?

If you want to change some bits without changing the rest of the byte, you'd need to use bit operations. But if you're going to do that, then it might be just as fast (and probably easier) to just use pfvline instead-- depending on whether you wanted to change just one bit in each byte, or more than one bit at once.

 

If you wanted, you could even write a routine to draw a diagonal line.

 

Michael

Thanks. Now I'm even closer to making a Superchip game one of these days. Once I get over my uneasiness about bank switching, I can have a ton of fun.

[SeaGtGruff]

Once I get over my uneasiness about bank switching, I can have a ton of fun.

No reason to be uneasy about bankswitching, especially with bB doing almost all of the work for you!

 

Michael

[MausGames]

If you want to change some bits without changing the rest of the byte, you'd need to use bit operations. But if you're going to do that, then it might be just as fast (and probably easier) to just use pfvline instead-- depending on whether you wanted to change just one bit in each byte, or more than one bit at once.

 

I haven't been able to get bit operations to work with superchip playfield variables. Trying to set only one bit turns all 8 playfield pixels on or off.

[SeaGtGruff]

If you want to change some bits without changing the rest of the byte, you'd need to use bit operations. But if you're going to do that, then it might be just as fast (and probably easier) to just use pfvline instead-- depending on whether you wanted to change just one bit in each byte, or more than one bit at once.

 

I haven't been able to get bit operations to work with superchip playfield variables. Trying to set only one bit turns all 8 playfield pixels on or off.

I'm guessing it might be the way you're doing it. Superchip RAM-- and all the other "old" expanded RAM methods-- require that you read the RAM from one address, and write to the RAM at another address, so you'll need to keep that in mind. In fact, you have to keep that in mind even if all you're doing is adding 1 to a Superchip variable:

 

   w000 = r000 + 1 : rem * where r000 is the read address and w000 is the write address

So you might need to use a temporary variable when doing bit operations:

 

   temp1 = r000
  temp1{5} = 1
  w000 = temp1

Or you could write a macro to do it without using a temporary variable. I'll try it later.

 

Michael

[MausGames]

I can't use bit operations at all with superchip variables. When I try to turn playfield pixels on or off, nothing happens. In fact, I don't think the superchip variables work at all. They won't hold a value, not even the ones that aren't being used for the playfield. I know I'm using them the right way, it just isn't working.

 

edit: Oops, it looks like I don't have the file 2600basic_variable_redefs.h, where do I get that?

 

edit²: I checked the 1.0 archive, the file isn't included. Does that mean I don't need it, and that isn't the problem?

Edited January 23, 2009 by MausGames

[SeaGtGruff]

I can't use bit operations at all with superchip variables. When I try to turn playfield pixels on or off, nothing happens. In fact, I don't think the superchip variables work at all. They won't hold a value, not even the ones that aren't being used for the playfield. I know I'm using them the right way, it just isn't working.

 

edit: Oops, it looks like I don't have the file 2600basic_variable_redefs.h, where do I get that?

 

edit²: I checked the 1.0 archive, the file isn't included. Does that mean I don't need it, and that isn't the problem?

I thought the redefs file gets created automatically when you compile, and is program-specific? How about posting code showing how you're using the Superchip variables? And any error messsges you may be getting when you compile?

 

Michael

[MausGames]

trying to use superchip variables doesn't work at all. For example:

 

w012 = r012 + 1

score = score + r012

 

produces nothing

 

Same with:

 

w010 = 12 : w011 = 12

 

pfpixel r010 r011 on

temp1 = r010 : temp2 = r011

pfpixel temp1 temp2 on

 

Absolutely nothing, reading and writing to the superchip variables doesn't work, neither does trying to assign their value to an a-z variable. Everything compiles just fine though. I found your "pokepf" code, and that got around altering the playfield bits using the SC variables; but since I'm only using pfres=24, it'd be nice to be able to use the leftover superchip ram variables.

Edited January 23, 2009 by MausGames

[SeaGtGruff]

trying to use superchip variables doesn't work at all. For example:

 

w012 = r012 + 1

score = score + r012

 

produces nothing

 

Same with:

 

w010 = 12 : w011 = 12

 

pfpixel r010 r011 on

temp1 = r010 : temp2 = r011

pfpixel temp1 temp2 on

 

Absolutely nothing, reading and writing to the superchip variables doesn't work, neither does trying to assign their value to an a-z variable. Everything compiles just fine though. I found your "pokepf" code, and that got around altering the playfield bits using the SC variables; but since I'm only using pfres=24, it'd be nice to be able to use the leftover superchip ram variables.

Do you know how to generate an assembly listing, which shows the actual hex byte values of each command and variable? I'm wondering what it shows for the Superchip variables. If you can generate a listing, could you email it to me (SeaGtGruff-at-aol-dot-com)?

 

Michael

[yuppicide]

Alright. I am revisiting this thread to try and learn it again. I understand it now! I can't wait to go to the office tomorrow where I have the latest version of my code! I am so excited. First and foremost thank you guys.

 

Here's where my problem was and if anyone else needs an explanation to learn this as well.

 

Michael gave the following code:

 

for a = 3 to 127 step 4

 

This generates a line down the right side of the playfield if we had pokepf[a] = %11111111. I didn't want that. I wanted one single row line across the screen. I didn't understand what step 4 did, but I do now.

 

Looking at the original post you will see 4 sections of bits you can can set. Let's say you want a line across row 1 like I do, you'd do set your pokepf like I just showed above, and you'd do for a = 0 to 3 step 1. That will draw a line across the screen 32 pixels across.

 

****************************

 

If you would use step 2, you'd end up with this:

 

********XXXXXXXX ********XXXXXXXX

 

.. and if you'd use step 3 you'd end up with:

 

********XXXXXXXXXXXXXXXX********

 

.. and if you'd use anything higher you'd end up with:

 

********XXXXXXXXXXXXXXXXXXXXXXXX

 

The X's are where no pixel's are.

 

Once I figured that out I totally understand it now and will hopefully put this to great use.

Edited April 13, 2009 by yuppicide

[yuppicide]

I've been working here a little bit. I can pfpoke my horizontal line and I'll continue to pfvline my two side lines. Here's my problem. I have three variables m (left line) and q (right line) and g (y position). This was used to tell my pfhline where the two side pfvlines were. Thus, it would draw pfhline m g q on. So, it knew that if the left pfvline was in 5 columns and the right pfvline was in 9 columns, it knew exactly how long to draw my pfhline and on what row it needed.

 

How will I accomplish this with pfpoke? The only way I can figure out right now is VERY LONG code as follows:

 

updateline
if m = 1 && q = 31 then pokepf0 = %11111110 : pokepf1 = %11111111 : pokepf2 = %11111111 : pokepf3 = %11111110 : goto updateline2
if m = 2 && q = 31 then pokepf0 = %11111100 : pokepf1 = %11111111 : pokepf2 = %11111111 : pokepf3 = %11111110 : goto updateline2
if m = 3 && q = 31 then pokepf0 = %11111000 : pokepf1 = %11111111 : pokepf2 = %11111111 : pokepf3 = %11111110 : goto updateline2
if m = 4 && q = 31 then pokepf0 = %11110000 : pokepf1 = %11111111 : pokepf2 = %11111111 : pokepf3 = %11111110 : goto updateline2

.. etc etc.

 

As you can see in that example the left side moves in, right side is staying put. It's okay that the pfpoke is writing 0's because my pfvline comes after this in my code, so it'll draw the side lines.

 

The most the two pfvlines can move in is 22 columns total. So, between the both of them they can only move in 22. Meaning, if the left has moved in 20 already, the right can only move in 2.

 

This will create a boatload of combinations as shown above.. m = 1 && q = 30, m = 1 && q = 29, etc, and then all the ones inbetween like m = 5 && q = 25, etc.

[SeaGtGruff]

This will create a boatload of combinations as shown above.. m = 1 && q = 30, m = 1 && q = 29, etc, and then all the ones inbetween like m = 5 && q = 25, etc.

Yeah, that won't work. I was thinking about this the other night, and I'm seeing if I can come up with a less cycle-intensive version of the pfhline routines.

 

Michael

[yuppicide]

I worked it out on an Excel sheet because I'm bored at work and I believe I'd come to over 253 combinations.

 

Although this pfpoke thing is still very useful knowledge.

[SeaGtGruff]

I worked it out on an Excel sheet because I'm bored at work and I believe I'd come to over 253 combinations.

 

Although this pfpoke thing is still very useful knowledge.

No need for 253+ combinations, the pfhline routine ought to be able to be rewritten to work with entire bytes at once, but using a starting and ending column. It would still take up more ROM and more cycles than a macro, but it would take up a lot less cycles than the existing pfhline routine.

 

Michael