21 replies to this topic

[Random Terrain]

I use CTRLPF to put the sprites behind the playfield pixels. Then in a certain spot during the game over loop, I use CTRLPF to put the sprites in front of the playfield pixels, but when that happens, the right side of the screen (with or without using PF0) jumps to the middle of the screen and pushes the rest of the playfield to the right edge of the screen.

Does anybody know why that would happen?

[RevEng]

It's by design.

Your entry on CTRLPF says the following "$x1 none of the below" when it should say "$x1 reflect the playfield".

bB relies on a reflected playfield setting to make an asymmetric playfield. You've inadvertently changed it to a repeated playfield.

Edited by RevEng, Sun Oct 10, 2010 1:38 PM.

[Random Terrain]

RevEng, on Sun Oct 10, 2010 1:38 PM, said:

It's by design.

Your entry on CTRLPF says the following "$x1 none of the below" when it should say "$x1 reflect the playfield".

bB relies on a reflected playfield setting to make an asymmetric playfield. You've inadvertently changed it to a repeated playfield.

Thanks. I just updated the page. Is it possible to make the sprites pop to the front when you already had them in the background?

Even CTRLPF=0 makes it reflect.

Edited by Random Terrain, Sun Oct 10, 2010 2:55 PM.

[RevEng]

CTRLPF=0 makes it repeat.

To have the sprites back in front and reflected playfield (which is the way bB wants it for asymmetric playfield) use "CTRLPF=1"

[Random Terrain]

This is freakin' weird. I copied "CTRLPF=$25" from my main loop setup, pasted it in my game over loop, then changed it to "CTRLPF=$21" since the info from batari says $x1 is "none of the below" and ended up with a reflected playfield.

After trying various things that didn't work, I tried what you said and used "CTRLPF=1" and it worked. Then I thought, isn't "CTRLPF=1" the same as "CTRLPF=$01"? So I tried "CTRLPF=$21" again and the playfield looks the way it is supposed to. Either I'm extremely stupid, my computer is infested by gremlins, or my brain is being attacked by aliens or demons.

I don't know why it's working now, but it looks like I need to change the bB page back to what batari originally had.

Edited by Random Terrain, Sun Oct 10, 2010 3:58 PM.

[RevEng]

Random Terrain, on Sun Oct 10, 2010 3:38 PM, said:

I don't know why it's working now, but it looks like I need to change the bB page back to what batari originally had.

Yeah, I see what batari meant. Setting CTRLPF=$01 does "none of the below" for certain. It also sets the playfield to reflected, which is how it needs to be for the bB asymmetric playfield timing to work, but I guess that's a behind-the-scenes detail that the user doesn't need to know.

[Omegamatrix]

RT, does this help? It's straight out of the Stella Programmers Guide.




To me that diagram makes it clear what bits need to be set. It also shows what bits aren't used (the greyed out ones). The Stella Programmers Guide does this for every register, and has a nice summary table at the end too.

[Random Terrain]

Omegamatrix, on Mon Oct 11, 2010 3:44 AM, said:

RT, does this help? It's straight out of the Stella Programmers Guide.

Thanks. By looking at that, you'd think that simply turning D2 on or off would make the sprites be in front or in back, but with batari Basic, it seems D0 always has to be on for D2 to work. So if you only want your sprites behind the playfield, you have to use "CTRLPF=$x5" (--??-101) and to put the sprites back in front of the playfield, you have to use "CTRLPF=$x1" (--??-001).

I just don't understand how I was getting a reflected playfield using "CTRLPF=$x1" then after a while, it started acting like it's supposed to. It's like batari Basic forgot it was batari Basic for an hour or two when it came to CTRLPF. Like I said, it was a freakin' weird problem. I'm glad the problem went away, but I didn't change anything in the program to fix it. It seems the problem fixed itself after I used "CTRLPF=1" one time, then switched back to "CTRLPF=$21". Either batari Basic or Stella or something in-between fixed itself.

[Random Terrain]

Omegamatrix, on Mon Oct 11, 2010 3:44 AM, said:

To me that diagram makes it clear what bits need to be set. It also shows what bits aren't used (the greyed out ones). The Stella Programmers Guide does this for every register, and has a nice summary table at the end too.

Do you know if there is an online HTML version of that which shows the greyed out boxes? I haven't found one yet. The only version with greyed out boxes I have seen so far are at places like scribd.com where the pages seem to be scans or PDF.

If a version that looks like what you posted doesn't exist as HTML, I'll converted it myself when I'm done with the game I'm working on if someone can point me to the most up-to-date version of the Stella Programmers Guide.


Thanks.

[Omegamatrix]

Random Terrain, on Mon Oct 11, 2010 10:00 AM, said:

Do you know if there is an online HTML version of that which shows the greyed out boxes?

None that I'm aware of.

Quote

If a version that looks like what you posted doesn't exist as HTML, I'll converted it myself when I'm done with the game I'm working on if someone can point me to the most up-to-date version of the Stella Programmers Guide.

This is the one I use. As far as I know no one has ever made a newer copy. Pages 38-46 contain all the quick references. I use these all the time to figure out what bits to enable/disable.


 Stella Programmers Guide.pdf   754.38K   31 downloads

[Random Terrain]

Omegamatrix, on Mon Oct 11, 2010 2:07 PM, said:

This is the one I use. As far as I know no one has ever made a newer copy. Pages 38-46 contain all the quick references. I use these all the time to figure out what bits to enable/disable.

Thanks. When I get done with the game I'm working on, I'll start working on an HTML version.

I went Googlig again and I see that there was a Stella Programmer's Guide Overhaul Project by Chad Hendrickson. The file name was stellaoh.zip, but it doesn't seem to be online. Maybe someone around here has it. If the AtariAge member Chad Hendrickson is the same guy, he hasn't been active since Apr, 24 2008. I can send him a PM and see what happens.


The original Stella Programmer's Guide was also HTMLified by B. Watson on 9/14/2001:

http://alienbill.com...ocs/stella.html

Maybe I can base my version on that and update it so it will have the greyed out boxes and other things. If the file from Chad Hendrickson can be found, maybe I can mix the two.

Edited by Random Terrain, Mon Oct 11, 2010 3:40 PM.

[eshu]

Random Terrain, on Mon Oct 11, 2010 3:31 PM, said:

Omegamatrix, on Mon Oct 11, 2010 2:07 PM, said:

This is the one I use. As far as I know no one has ever made a newer copy. Pages 38-46 contain all the quick references. I use these all the time to figure out what bits to enable/disable.

Thanks. When I get done with the game I'm working on, I'll start working on an HTML version.

I went Googlig again and I see that there was a Stella Programmer's Guide Overhaul Project by Chad Hendrickson. The file name was stellaoh.zip, but it doesn't seem to be online. Maybe someone around here has it. If the AtariAge member Chad Hendrickson is the same guy, he hasn't been active since Apr, 24 2008. I can send him a PM and see what happens.

I've always found the HTML version at: http://www.alienbill...ocs/stella.html perfectly usable....

[Random Terrain]

eshu, on Mon Oct 11, 2010 3:37 PM, said:

I've always found the HTML version at: http://www.alienbill...ocs/stella.html perfectly usable....

It seems to be missing the greyed out boxes and other things. I can adapt it and maybe mix in the Chad Hendrickson info (if the file can be found). I can "Random Terrain it" so various charts will have mouseover effects and things like that. Stuff like you'd see on the batari Basic Commands page.

[Random Terrain]

After more Googling, I found this page:

http://www.whimsey.com/atari_docs/

It has one version updated by Darryl May and different version updated by Charles Sinnett.

[stephena]

Random Terrain, on Mon Oct 11, 2010 10:00 AM, said:

Omegamatrix, on Mon Oct 11, 2010 3:44 AM, said:

To me that diagram makes it clear what bits need to be set. It also shows what bits aren't used (the greyed out ones). The Stella Programmers Guide does this for every register, and has a nice summary table at the end too.

Do you know if there is an online HTML version of that which shows the greyed out boxes? I haven't found one yet. The only version with greyed out boxes I have seen so far are at places like scribd.com where the pages seem to be scans or PDF.

If a version that looks like what you posted doesn't exist as HTML, I'll converted it myself when I'm done with the game I'm working on if someone can point me to the most up-to-date version of the Stella Programmers Guide.


Thanks.

All of the available versions of the guide I've found are missing some other things too. The little things are related to behaviour I've fixed in Stella, and commented on in the code itself. They really should be added to the guide too. If only I had the time ...

[Random Terrain]

stephena, on Tue Oct 12, 2010 7:36 AM, said:

All of the available versions of the guide I've found are missing some other things too. The little things are related to behaviour I've fixed in Stella, and commented on in the code itself. They really should be added to the guide too. If only I had the time ...

When I start working on the updated page, feel free to send me bits of info to add or change as you find the time.


Thanks.

[SeaGtGruff]

Random Terrain, on Mon Oct 11, 2010 3:47 PM, said:

It seems to be missing the greyed out boxes

The grayed-out bits are grayed-out because they aren't used. You can set them to whatever you want and they don't make any difference. Examples from the Stella Programmer's Guide:

The WSYNC and RSYNC registers have all of their boxes (bits) grayed-out, because they're "strobe" registers-- the very act of writing to them causes them to perform their functions, and it doesn't matter what value you write to them-- 0, 1, 100, 120, 200, etc.

VSYNC has all of its boxes grayed out except D1, because D1 (bit 1) is the only bit used.

CTRLPF has three boxes grayed-out, because those three bits aren't used.

This can actually come in useful in some cases. For example, batari Basic's multi-sprite kernel uses five RAM variables named _NUSIZ1, NUSIZ2, NUSIZ3, NUSIZ4, and NUSIZ5, which you can use to specify the number, size, and direction of players 1, 2, 3, 4, and 5. Whatever value you store in one of those RAM variables will be written to both NUSIZ1 and REFP1. (Notice the difference between NUSIZ1 and _NUSIZ1-- NUSIZ1 is a TIA register, and _NUSIZ1 is a RAM variable.) The NUSIZ1 register uses bit 0, bit 1, bit 2, bit 4, and bit 5, but it does *not* use bit 3, bit 6, or bit7. On the other hand the REFP1 register uses bit3, but it doesn't use any of the other bits. So you can store a combined value into _NUSIZ1, and batari Basic's multi-sprite kernel will write that value into both NUSIZ1 and REFP1. In essence, you can store two values for the price of one, and batari Basic doesn't even need to mask the bits to separate the two values from each other, because any bits that aren't used by NUSIZ1 or REFP1 will be ignored-- NUSIZ1 only cares about bit 0, bit 1, bit 2, bit 4, and bit 5, whereas REFP1 only cares about bit 3. And since neither one of them cares about bit 6 or bit 7, you can use bit 6 and bit 7 of _NUSIZ1 to store two bit variables for your own uses.

I don't know if it's relevant to the problem you had, but keep in mind that CTRLPF is a write-only register, meaning you can "POKE" a new value into it, but you can't "PEEK" into it to see what its existing value is. That means you *cannot* do something like this:

   if CTRLPF{0} then goto the_playfield_is_reflected
   CTRLPF = CTRLPF & % 00110110 : rem * turn off reflected playfield without changing anything else
   CTRLPF = CTRLPF | % 00000001 : rem * turn on reflected playfield without changing anything else

If you need to "save" the value of CTRLPF for some reason, so you can check its value later, or so you can change some of its bits without changing all of its bits, you'll need to dim a byte of RAM for it, and then write the RAM variable to it during your loop:

   dim _CTRLPF = a
   _CTRLPF = % 00000101 : rem * reflected playfield and players behind playfield
loop
   CTRLPF = _CTRLPF : rem * set CTRLPF to the saved value
   drawscreen
   if monkeyshines > 15 then _CTRLPF{2} = 0 : rem * make the players be in front of the playfield
   goto loop : rem * the first statement in the loop will update CTRLPF as desired

Michael

Edited by SeaGtGruff, Tue Oct 12, 2010 7:53 PM.

[Random Terrain]

SeaGtGruff, on Tue Oct 12, 2010 7:50 PM, said:

Random Terrain, on Mon Oct 11, 2010 3:47 PM, said:

It seems to be missing the greyed out boxes

The grayed-out bits are grayed-out because they aren't used. You can set them to whatever you want and they don't make any difference.

I meant that the HTML versions that I've seen lack the 'pretty' stuff that the PDF file has. Things that make the info easier to understand.

[SeaGtGruff]

[quote name='Random Terrain' date='Tue Oct 12, 2010 10:02 PM' timestamp='1286935371' post='2113755']
The grayed-out bits are grayed-out because they aren't used. You can set them to whatever you want and they don't make any difference.[/quote]
I meant that the HTML versions that I've seen lack the 'pretty' stuff that the PDF file has. Things that make the info easier to understand.
[/quote]
Oh. Yeah, there's one PDF version that seems to "have it all" (although I believe it's missing a table of timing values). There are some other PDF versions that appear to be missing some things. However, the one that seems to have it all is actually a combination of two documents.

There's a "[url="http://www.atariarchives.org/dev/tia/index.php"]TIA 1A Manual[/url]," which is a typed and hand-drawn document. The version at <-- that link has the typed part re-typed on a computer. Another version, scanned from the original typewriter version, is [url="http://www.whimsey.com/atari_docs/"]here[/url] (click on the *second* link on that page).

Then there's the "Stella Programmer's Guide," which is also a scanned typewriter version (in its original version, which can be seen [url="http://chomikuj.pl/voyssgdial/Dokumenty+atarowskie/Konsole/Atari+2600+Video+Computer+System/2600_Stella_Guide_Rev_A_12-3-79.pdf"]here[/url]).

The newer-looking copy of the Stella Programmer's Guide-- with the nicer typing and drawings and pictures-- is a revision of the original, and includes a nicer version of the TIA 1A Manual-- so it's really a combination of what were originally two separate documents.

Michael

[atari2600land]

Omegamatrix, on Mon Oct 11, 2010 3:44 AM, said:

RT, does this help? It's straight out of the Stella Programmers Guide.

CTRLPF.jpg


To me that diagram makes it clear what bits need to be set. It also shows what bits aren't used (the greyed out ones). The Stella Programmers Guide does this for every register, and has a nice summary table at the end too.

Sorry about bumping a semi-old topic, but I was looking at that picture, thinking that the score could be two colors? I'm working on something that would be really useful to have a part of the score be the color or player0 and the other be the color of player1. Since I don't know what "setting bits" means, what would I need to type in to do this?
edit: never mind, it says PLAYFIELD instead of SCORE. Wonder if there is a way to make the score two colors without the minikernel?

[SeaGtGruff]

atari2600land, on Mon Nov 22, 2010 5:56 AM, said:

Omegamatrix, on Mon Oct 11, 2010 3:44 AM, said:

RT, does this help? It's straight out of the Stella Programmers Guide.

CTRLPF.jpg


To me that diagram makes it clear what bits need to be set. It also shows what bits aren't used (the greyed out ones). The Stella Programmers Guide does this for every register, and has a nice summary table at the end too.

Sorry about bumping a semi-old topic, but I was looking at that picture, thinking that the score could be two colors? I'm working on something that would be really useful to have a part of the score be the color or player0 and the other be the color of player1. Since I don't know what "setting bits" means, what would I need to type in to do this?
edit: never mind, it says PLAYFIELD instead of SCORE. Wonder if there is a way to make the score two colors without the minikernel?

You can make the score be two colors by setting player0 and player1 to different colors, but the colors will have to alternate-- such as red-blue-red-blue-red-blue. That's because of the way the copies of player0 and the copies of player1 alternate with each other. It wouldn't even be very difficult to do this, because the score routine sets player0 and player1 to the same color-- i.e., scorecolor-- and all you'd need to do is modify that section of code so they're set to two different colors.

Michael

[Random Terrain]

SeaGtGruff, on Tue Oct 12, 2010 8:57 PM, said:

Oh. Yeah, there's one PDF version that seems to "have it all" (although I believe it's missing a table of timing values). There are some other PDF versions that appear to be missing some things. However, the one that seems to have it all is actually a combination of two documents.

There's a "TIA 1A Manual," which is a typed and hand-drawn document. The version at <-- that link has the typed part re-typed on a computer. Another version, scanned from the original typewriter version, is here (click on the *second* link on that page).

Then there's the "Stella Programmer's Guide," which is also a scanned typewriter version (in its original version, which can be seen here).

The newer-looking copy of the Stella Programmer's Guide-- with the nicer typing and drawings and pictures-- is a revision of the original, and includes a nicer version of the TIA 1A Manual-- so it's really a combination of what were originally two separate documents.

Michael

I forgot to say thanks for the links. I'll be working on this pretty soon, so I'll need the latest, best, most fixed up versions out there. I'd like to get my version done before the summer is over.