[Mr. Saturn]

Whilst hacking the Earthbound Zero ROM, everything became tinted green. I edited it, saved it and came back to it later, and it was tinted green. I checked the palettes but they were unchanged.
Unfortunately I have no idea what I was doing before this happened. So I don't know if anything can be done about it.

[Jorpho]

Your last thread suggested you were trying to copy and paste all the colors from one version of a ROM to another.
http://www.romhacking.net/forum/index.php?topic=29394.msg383380

Is that what you tried to do?

[Cyneprepou4uk]

Unfortunately I have no idea what I was doing before this happened.

Compare original and hacked files. Make changes one by one in original file and test it until you find the source of your issue.

And for starters learn how to ask proper questions. We are not telepathists here. 

[nesrocks]

Sounds like you wrote emphasis bits to the ppu mask.  https://wiki.nesdev.com/w/index.php/PPU_registers#PPUMASK

[Mr. Saturn]

Sounds like you wrote emphasis bits to the ppu mask.

I thought that's what it was, but couldn't quite figure it out. The value in my hex editor (FCEUX), the 2nd value of 2000 (as that's where going to $2001 took me) is identical to that of the unmodified ROM. Maybe I'm looking in the wrong place?

We are not telepathists here.

Sorry about that, the last thing I remember doing was haphazardly searching for where a certain sprite's data was stored. Editing things, seeing what happened, then switching it back. I may have forgotten to change a value back, or gave it the wrong value. It was kinda all over the place, so I guess that probably doesn't help much.

Your last thread suggested you were trying to copy and paste all the colors from one version of a ROM to another.

I wound up just doing that the hard way, going to every sprite in the game and changing it's palette. The palettes themselves (their values and whatnot) are unchanged, but they've all been tinted green.

[nesrocks]

I thought that's what it was, but couldn't quite figure it out. The value in my hex editor (FCEUX), the 2nd value of 2000 (as that's where going to $2001 took me) is identical to that of the unmodified ROM. Maybe I'm looking in the wrong place?

Imagine the $2001 address as a command. It's a special address. You're not writing the byte to a memory location that you can read from later, it's just how the processor takes these very specific instructions. So somewhere in your new code you're writing a byte that has the green bit set to the $2001 address. Set breakpoints to writes to $2001 and see if you're writing any byte with that bit set (anything from #40-#7F or #C0-#FF).

Since you forgot what you changed you can open the original file and your modified file in Frhed (a free hex editor) to compare differences.

[Mr. Saturn]

Thanks for your advice.
I downloaded Frhed and compared both files. There are a LOT of differences (specifically 6256).
So I moved onto trying the breakpoints.
Admittedly, I've never used breakpoints before. I set the address to 2001, set it to write, and kept it in CPU memory. I tried several different things with the condition, but I'm kinda at a total loss.
I'm assuming I need to find if (thingy here) is greater than #40 or less than #7F, or greater than #0F and less than #FF, but nothing I've tried so far has worked.

Shortly after writing the above, I thought to try switching the breakpoint from CPU memory to PPU memory. The game runs now, but nothing else is really happening. There doesn't appear to be any indication of, well, anything.

The main two conditions I'm using are:
A >= #40 || A<= #7f
and
A >= #C0 || A<= #FF

[nesrocks]

You don't need to use conditions, leave it blank. Set the breakpoint for writes to $2001, reset the game, and run. Then look into the instruction that is writing to $2001, likely a STA, which means it is taking the value at the accumulator (A) and copying it into $2001. So it is a matter of keep clicking "run" while keeping your eyes on A. Once A has one of the values that meets the criteria you may have found the problem. Now mark the address where this happens and compare to the same address on the original ROM.

If you really want to use conditions, then it has to be A >= #40 && A<= #7f. When you use || you're writing "or" which means it will break on any values in that expression you wrote (anything that is bigger than 40 or smaller than 7F is all values from 0-FF, so that doesn't help). You want to use && which means "and".
A more complete condition then is
(A >= #40 && A<= #7F) || (A >= #C0 && A<= #FF)

[Cyneprepou4uk]

Better use W instead of A in case it is not written via A. W is a condition on "write value", basically it is like all 3 registers combined.

And you don't need to compare the very original rom. Take the rom where you don't have green, and compare to the rom where it's started. You do have previous hack versions, don't you?

[nesrocks]

Better use W instead of A in case it is not written via A. W is a condition on "write value", basically it is like all 3 registers combined.

I wasn't aware of W in the conditions setter. Nice! Yes, so it is

Code: [Select]

(W >= #40 && W<= #7F) || (W >= #C0 && W<= #FF)

[Mr. Saturn]

I'm not totally sure I'm doing this right:
I have a breakpoint set to $2001, and I'm running about in the game watching the A value shown under Seek To and all that stuff.
Whenever it breaks I'm looking at the line the breakpoint has selected
(such as 0F:F973:8D 07 20  STA PPU_DATA = #$00)
and watching to see if the #$00 matches up with the A value.
So far the #$00 has only ever been #$00 and #$0A. The A value hasn't matched up with it except for on the title screen where A is also 00, which is identical to my backup ROM. This is after wandering around in the game for a while doing this.

[Fox Cunning]

I'm not totally sure I'm doing this right:
I have a breakpoint set to $2001, and I'm running about in the game watching the A value shown under Seek To and all that stuff.
Whenever it breaks I'm looking at the line the breakpoint has selected
(such as 0F:F973:8D 07 20  STA PPU_DATA = #$00)
and watching to see if the #$00 matches up with the A value.
So far the #$00 has only ever been #$00 and #$0A. The A value hasn't matched up with it except for on the title screen where A is also 00, which is identical to my backup ROM. This is after wandering around in the game for a while doing this.

FCEUX is not main main emu/debugger, but I'm fairly sure what you are seeing is the value of the register at the moment execution was stopped.
In this case, you can completely ignore that value and check the code before that instruction, e.g.:

Code: [Select]

  LDA $04 = #$0A
  STA PPU_DATA = #$00

or:

  LDA #$0A
  STA PPU_DATA = #$00

In both these examples #$0A is being written, not #$00, and it should be the value in the Accumulator if execution stops at the "STA".
But you can ignore any value read from PPU_Data unless you are specifically reading PPU_Data (in that case, only ignore the first read).

Anyway, I believe you should be looking at writes to $2001 (PPU_MASK), not $2007 (PPU_DATA). Double-check your breakpoints.

[nesrocks]

That "= $00" is a value stored in ram address $2001. That's not the value you need to look at. Like I said, you need to look at the value in the accumulator A at the moment the breakpoint occurs. It should be to the right inside a small box. If A holds one of the no-no values, then that may be where the problem is.

[Mr. Saturn]

If A holds one of the no-no values, then that may be where the problem is.

What values am I looking for?
I know that bit 5 in the PPU_mask controls the green tint, but admittedly I don't know how these bits are stored. I'm guessing that they're somehow compiled into what is seen in A? Or is A modifying the PPU_mask bits? Basically, how do I know if a value is the problematic one?

Also, when I do find the green value, would I find it in the hex editor or can I change it in the debugger? I'm guessing it's the former, but regardless, how would I do that?

But you can ignore any value read from PPU_Data unless you are specifically reading PPU_Data (in that case, only ignore the first read).

The breakpoint is pretty much only finding PPU_data lines. Should I (and how would I) add some sort of condition to exclude them?

[Cyneprepou4uk]

If you forgot what values you are looking for, read this thread again.

If you don't know bits work, then look it up.

[nesrocks]

Fiddling with registers and bits may not be the easiest task to start with when learning assembly and NES. But I didn't want to say that because if there's a task that gets you to learn something it is going to be the task that you actually want to do. So, okay.

You should read more about how bytes and bits work. There's a lot of info about that online. But, to make it short, the values I mentioned all have the 5th bit set. So whenever any of those byte values are written to $2001, that's setting the green emphasis bit (and may be doing other irrelevant things to this case).
The other thing that you should learn is some level of 6502 asm coding. This is because in order to detect the problem and fix it you're gonna need to read and write assembly code, respectively. The good news is that it's not too hard, it's just basically some instructions executed one at a time that change values in memory or registers. You don't need to know them all, you can check them as you read them. Fceux's debugger is great at showing you how the ROM's byte code would probably be interpreted by the CPU. To answer your question, you can use the debugger to navigate, but changes need to be made in the hex editor (when viewing the ROM memory, not RAM).

When setting the breakpoint you write 2001-2001 in the address range. I don't know how you got 2007 there. And I think you can leave it at CPU space, no need to select PPU. I can't be sure of that one right now.

[Cyneprepou4uk]

He needs to select CPU memory option.

He doesn't need to write 2001 in both fields if it's not a range (but it will work anyway even if he uses range for a single address).

[Mr. Saturn]

If you forgot what values you are looking for, read this thread again.

I forgot those were there. My bad.

When setting the breakpoint you write 2001-2001 in the address range. I don't know how you got 2007 there.

I know what I did wrong here. I had 2001-unspecified instead of 2001-2001.

He doesn't need to write 2001 in both fields if it's not a range (but it will work anyway even if he uses range for a single address).

...Or maybe I don't know what I did wrong there. So 2001-unspecified probably wasn't the problem?
I just tested it, and 2001-2001 still gives PPU_Data breaks. Definitely not the problem.

You should read more about how bytes and bits work.

I did do a little research on bits/bytes, but didn't catch much of it due to lack of time. What you've said helps a lot though. Now I've got a much better idea of where to start researching, and where to go from there.

Now that's I've got a breakpoint with the address set to 2001-2001, with write and CPU memory selected, the game freezes.
Sometimes clicking 'run' will make at least change where it breaks and the A value (I assume it also makes the game run, but stops again before it's noticeable). Then it invariably gets caught on A=88.
This particular 88 and it's line are identical to that of the non-green ROM.
The values that happen before it aren't between #40-#7F or #C0-#FF.
Specifically they are 00, 1e, 18, and 88.
So I went back to the conditions that were discussed a while ago. I found that any inclusion of 'W' in a condition makes it invalid. When using the variant with A's it never breaks. When I initially tried the conditions I had the same results, but figured I'd just go without them.
However, when I have the A variant of the condition the game doesn't freeze.

I'd try to be more thorough before posting this, but I'm rather short on time again. Sorry if that's a problem.

[Cyneprepou4uk]

"W" being invalid means you are using older emulator version. Since debugger shows "PPU_DATA" words, I presume it's 2.2.3 from official site. Download the latest build instead.

I'd like to see a video of exactly what you are doing (preferably with voice comments). And also screenshots of normal game and green game.

[nesrocks]

#88 is not within the problematic values range (#40-#7F or #C0-#FF). That's not where the problem is. Set the breakpoint, pause the emulator, reset the game, and unpause the emulator.