Jump to content
IGNORED

editing playfields and colors in stella


bradhig

Recommended Posts

Where are you typing in the values, and what game are you working on, first of all?

 

Each game is different, and I'm not sure how much experience you have with machine language, but you have to find where the code does the color changing.

 

Sometimes it's obvious, like:

 

LDA #00

STA COLUPF

 

If your game is like that, just change the value at LDA and the playfield color will change.

 

But very often it won't be so obvious...like the programmer will have one of the RAM addresses hold the playfield color. So in one spot in the code he may have (let's say he chose $D4 as a the address--it could be any of them).

 

LDA $D4

STA COLUPF

 

And then in another spot (or multiple spots) he sets the values for D4. That may be as simple as

 

LDA #00

STA $D4

 

Or it could be pulling the values from a table based on the value of Y like:

 

LDA FF00, Y

STA $D4

 

Or even something more complicated, like he's pulling from an indirect address or something.

 

If the game you're working on has a good disassembly, then check that out first. Otherwise, when I'm trying to figure a game out without a disassembly, I just advance by frames, scans, and steps in Stella, watching the TIA registers closely the whole time to see exactly when in the code the playfield or colors are changing. Back up a step or two and you can then see which RAM addresses or tables are involved.

  • Like 1
Link to comment
Share on other sites

Doing hacking like this is possible in Stella, but messy. Stella is an awesome tool for finding where and when colors are being set, but you do have to backtrack the value a lot like CDS has said.

 

You also have to be aware:

 

1) The value you are hacking might be used for more than the color. Especially when it is "0" being loaded. "0" is a color for black, but "0" is often used for clearing other registers at the same time.

 

Example:

LDA #0

STA COLUBK ; color background black

STA ENABL ; disable ball

STA PF0 ; clear playfield 0

STA PF1 ; clear playfield 1

STA PF2 ; clear playfield 2

STA GRP0 ; clear player graphics register 0

STA GRP1 ; clear player graphics regiser 1

 

In this case all of these things are using the same value. Changing the color or playfield graphics in this case is best done in a disassembly.

 

 

2) The value loaded is also used to do a branch. A branch is a place in the code where the program will either continue from where it is or jump to somewhere else all depending on the condition (state) of flags used by that particular branch instruction.

 

Branches take 2 bytes of rom where as the jump instruction "JMP" takes 3. Since program space is limited on the 2600 it is quite common to use branches that will always execute in a place of a "JMP".

 

Example:

LDA #0

STA COLUBK

BEQ .goThere ; this branch will always be taken

 

Changing that value to anything other then 0 will cause the branch to fail. However you can change the value if you change the branch instruction as well. If your value is 127 or less then "BPL" can be used for an always branch. Likewise if the value is 128 to 255 a "BMI" can be used.

 

 

 

So yeah, lots to know. It all depends on the game itself. It's impossible to know how hard a game is to hack without looking in depth at it first.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...