Question about Virtual Sprite Registers

[jrok]

From Random Terrain's bB documentation:

 

Also, although the multisprite kernel doesn't have special variables for REFPx, you can set the reflection bit for each individual sprite by using bit 3 of _NUSIZ1 or NUSIZ2-NUSIZ5, as this bit is unused by the TIA register NUSIZx.

 

This works fine for me when I'm only setting the reflection bit or the number/size bits for a virtual sprite. But what if I need to both reflect and resize a virtual sprite? It seems that a combined-write wouldn't work, since these are pointed at variables instead of registers. For instance:

 

  NUSIZ2 = $058

... will not produce a double-wide, reflected sprite. But is there any other way to produce this sort of sprite?

 

Also, since _NUSIZ1-NUSIZ5 and _COLUP1-COLUP5 are pointed to variables, does that mean we could potentially test their current value in "if...then" statements (without reserving an additional variable) or even perform operations on them?

Edited June 30, 2009 by jrok

[SeaGtGruff]

From Random Terrain's bB documentation:

 

Also, although the multisprite kernel doesn't have special variables for REFPx, you can set the reflection bit for each individual sprite by using bit 3 of _NUSIZ1 or NUSIZ2-NUSIZ5, as this bit is unused by the TIA register NUSIZx.

 

This works fine for me when I'm only setting the reflection bit or the number/size bits for a virtual sprite. But what if I need to both reflect and resize a virtual sprite? It seems that a combined-write wouldn't work, since these are pointed at variables instead of registers. For instance:

 

  NUSIZ2 = $058

... will not produce a double-wide, reflected sprite. But is there any other way to produce this sort of sprite?

You need to combine the bits-- i.e., it would be $0D, or %00001101.

 

Also, since _NUSIZ1-NUSIZ5 and _COLUP1-COLUP5 are pointed to variables, does that mean we could potentially test their current value in "if...then" statements (without reserving an additional variable) or even perform operations on them?

Yes, you could. In fact, you could define RAM variables for NUSIZ0, REFP0, and COLUP0, so you could test their current values and perform operations on them-- but then you'd need to move them to the real registers:

 

   dim _COLUP0 = a
  dim _NUSIZ0 = b

  COLUP0 = _COLUP0
  NUSIZ0 = _NUSIZ0
  REFP0 = _NUSIZ0

(assuming that _NUSIZ0 combines the bits for NUSIZ and REFP the way the others do).

 

Michael

[jrok]

From Random Terrain's bB documentation:

 

Also, although the multisprite kernel doesn't have special variables for REFPx, you can set the reflection bit for each individual sprite by using bit 3 of _NUSIZ1 or NUSIZ2-NUSIZ5, as this bit is unused by the TIA register NUSIZx.

 

This works fine for me when I'm only setting the reflection bit or the number/size bits for a virtual sprite. But what if I need to both reflect and resize a virtual sprite? It seems that a combined-write wouldn't work, since these are pointed at variables instead of registers. For instance:

 

  NUSIZ2 = $058

... will not produce a double-wide, reflected sprite. But is there any other way to produce this sort of sprite?

You need to combine the bits-- i.e., it would be $0D, or %00001101.

 

Thanks, Michael. I think I grasp why %00001101 would work, but not so sure about "$0D." Is there a good article you can point me to that explains this?

 

Also, since _NUSIZ1-NUSIZ5 and _COLUP1-COLUP5 are pointed to variables, does that mean we could potentially test their current value in "if...then" statements (without reserving an additional variable) or even perform operations on them?

Yes, you could. In fact, you could define RAM variables for NUSIZ0, REFP0, and COLUP0, so you could test their current values and perform operations on them-- but then you'd need to move them to the real registers:

 

   dim _COLUP0 = a
  dim _NUSIZ0 = b

  COLUP0 = _COLUP0
  NUSIZ0 = _NUSIZ0
  REFP0 = _NUSIZ0

(assuming that _NUSIZ0 combines the bits for NUSIZ and REFP the way the others do).

 

Michael

 

I suppose what I was really asking was whether the pointers for the virtual sprite registers themselves could be treated as variables. I guess I'm trying to figure out what's going on under the hood that actually sets the registers for the color and size of the virtual sprites. For instance, the multisprite memory map lists these as:

 

$93	NewNUSIZ
   _NUSIZ1
$94	NUSIZ2
$95	NUSIZ3
$96	NUSIZ4
$97	NUSIZ5
$98	NewCOLUP1
   _COLUP1
$99	COLUP2
$9a	COLUP3
$9b	COLUP4
$9c	COLUP5

 

So, basically, I see that we are able to do the following:

 if COLUP2<255 then COLUP2=COLUP2+1
if COLUP2=255 then COLUP2=0

 

Which is pretty great! Basically, we have a few more variables at our disposal, as long as we aren't updating those virtual players at the moment, or if we don't mind the transformations that are being applied to them. I guess what I am curious about is, if we know a certain virtual sprite (say, player2 in above example) in our program is always going to to use the same bits for it's color or number&size, could we modify the multisprite kernel to set this register as a constant for that virtual sprite, and literally free up the variables for COLUP2 and NUSIZ2 to use for other things? What would be the best way to go about this?

 

Thanks again.

Jarod.

Edited July 1, 2009 by jrok

[SeaGtGruff]

Thanks, Michael. I think I grasp why %00001101 would work, but not so sure about "$0D." Is there a good article you can point me to that explains this?

$0D works because it's the hex equivalent of %00001101. The bits are combined in the virtual register-- bits 4 and 5 control the size of the missile, bits 0, 1, and 2 control the number of copies for the player and missile, and bit 3 is squeezed in to control the reflection, since that bit isn't used by the NUSIZx registers. So you store the value you want in the virtual register, and the batari Basic multisprite kernel will write the virtual register to the NUSIZ1 and REFP1 registers.

 

If you make your own virtual registers for player0, you'll need to write them to the real registers yourself, because the multisprite kernel wasn't written to use virtual registers for player0. In general, virtual registers waste RAM if they aren't needed, and I'm sure Fred (batari) didn't want to waste another two bytes of RAM and take away some of the user RAM. That's why he squeezed the values for NUSIZ1 and REFP1 into a single virtual register-- because given the bits that each one uses and doesn't use, you can OR them together into a single byte, and then write the same byte into the two (real) registers.

 

Basically, we have a few more variables at our disposal, as long as we aren't updating those virtual players at the moment, or if we don't mind the transformations that are being applied to them.

If you aren't going to use a given player, you can actually dim one of your own variables to its virtual color register or virtual number/size/reflect register-- but that's assuming the player will always be defined with a shape of all 0s, or will always be positioned "offscreen."

 

I guess what I am curious about is, if we know a certain virtual sprite (say, player2 in above example) in our program is always going to to use the same bits for it's color or number&size, could we modify the multisprite kernel to set this register as a constant for that virtual sprite, and literally free up the variables for COLUP2 and NUSIZ2 to use for other things? What would be the best way to go about this?

Yes, you could probably customize the mulrisprite kernel to do that. Or, if you have two or more virtual players that will always be the same color as each other, or have the same number/size/reflect settings, you could customize the header file to redefine those virtual registers to the same addresses as each other, which would free up their usual addresses for your own purposes.

 

Michael

[jrok]

I guess what I am curious about is, if we know a certain virtual sprite (say, player2 in above example) in our program is always going to to use the same bits for it's color or number&size, could we modify the multisprite kernel to set this register as a constant for that virtual sprite, and literally free up the variables for COLUP2 and NUSIZ2 to use for other things? What would be the best way to go about this?

Yes, you could probably customize the mulrisprite kernel to do that. Or, if you have two or more virtual players that will always be the same color as each other, or have the same number/size/reflect settings, you could customize the header file to redefine those virtual registers to the same addresses as each other, which would free up their usual addresses for your own purposes.

 

Thanks again. Matching the addresses in the header file seems like the easiest route. But if I wanted to hard code certain registers into the kernel itself, would it be a matter of writing a special case for the sprite index in the SetupP1Subroutine? Sorry for all the dumb questions.

Edited July 1, 2009 by jrok

[jrok]

I guess what I am curious about is, if we know a certain virtual sprite (say, player2 in above example) in our program is always going to to use the same bits for it's color or number&size, could we modify the multisprite kernel to set this register as a constant for that virtual sprite, and literally free up the variables for COLUP2 and NUSIZ2 to use for other things? What would be the best way to go about this?

Yes, you could probably customize the mulrisprite kernel to do that. Or, if you have two or more virtual players that will always be the same color as each other, or have the same number/size/reflect settings, you could customize the header file to redefine those virtual registers to the same addresses as each other, which would free up their usual addresses for your own purposes.

 

Thanks again. Matching the addresses in the header file seems like the easiest route. But if I wanted to hard code certain registers into the kernel itself, would it be a matter of writing a special case for the sprite index in the SetupP1Subroutine? Sorry for all the dumb questions.

 

EDT: Sorry... I really am a dummy. I see now that I just have to modify the header itself.

Edited July 1, 2009 by jrok

[jrok]

Thanks again. Matching the addresses in the header file seems like the easiest route. But if I wanted to hard code certain registers into the kernel itself, would it be a matter of writing a special case for the sprite index in the SetupP1Subroutine? Sorry for all the dumb questions.

 

EDT: Sorry... I really am a dummy. I see now that I just have to modify the header itself.

 

Hmm... well I was able to free up the addresses for missile0y and bally in the header (since these are static #'s in the program).

 

objecty = #4
missile0y = #4
missile1y = $84
bally = #5

base1life = $85
base2life = $83

 

But I can't seem to do the same for NUSIZ3 (a sprite which will always have the same number/size/reflect).

 

NewNUSIZ = $93
_NUSIZ1 = $93
NUSIZ2 = $94
NUSIZ3 = $0D
NUSIZ4 = $96
NUSIZ5 = $97

 

Is there a proper syntax to map these combined bits in a header to free up $95?

Edited July 1, 2009 by jrok

[SeaGtGruff]

I take back what I said about pointing two or more virtual registers at the same address-- it won't work. batari Basic puts the virtual registers and other variables together so it can access them using the sprite number as an index.

 

Also, you can't redefine one of the virtual registers as a constant to free up any bytes of RAM, because of the way batari Basic accesses them with an index.

 

If you were to completely rewrite the multisprite kernel, or write your own multisprite kernel, then it might could work.

 

Michael

[SeaGtGruff]

NewNUSIZ = $93
_NUSIZ1 = $93
NUSIZ2 = $94
NUSIZ3 = $0D
NUSIZ4 = $96
NUSIZ5 = $97

 

Is there a proper syntax to map these combined bits in a header to free up $95?

What you wrote won't work. I meant that you would store the value $0D in the NUSIZ3 virtual register in your code:

 

   NUSIZ3 = $0D

If you do what you did in the header, then you're telling batari Basic that virtual register NUSIZ3 is located at address $0D (or $000D). These virtual player registers need to be defined one after the other, in order, with nothing in between them, so batari Basic can read them using the sprite number as an index.

 

Michael

[jrok]

NewNUSIZ = $93
_NUSIZ1 = $93
NUSIZ2 = $94
NUSIZ3 = $0D
NUSIZ4 = $96
NUSIZ5 = $97

 

Is there a proper syntax to map these combined bits in a header to free up $95?

What you wrote won't work. I meant that you would store the value $0D in the NUSIZ3 virtual register in your code:

 

   NUSIZ3 = $0D

If you do what you did in the header, then you're telling batari Basic that virtual register NUSIZ3 is located at address $0D (or $000D). These virtual player registers need to be defined one after the other, in order, with nothing in between them, so batari Basic can read them using the sprite number as an index.

 

Michael

 

Yes, I knew it wouldn't work, and I did define the register in my code (which did work, thanks again!). I suppose I was just wondering if there was a way to define the register in the map, like defining a #, so I could free up NUSIZ3 for another use.