FCEUX Default Memory Values and Rom for Reading Values.

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

CLChambers00
Posts: 78
Joined: Wed Jul 19, 2017 10:23 am

Re: FCEUX Default Memory Values and Rom for Reading Values.

Post by CLChambers00 »

For example, when I load NES Who Framed Roger Rabbit into Bizhawk all the FF values in the start of the hex editor change to mostly 00 on the 2nd frame, and they change to certain values. When I set FCEUX to all FF, this same region starts with FF but switches to mostly 00 on the 4th frame but then populates different values than did Bizhawk. This setting change in FCEUX does not appear to be simulating Bizhawk results as expected.
CLChambers00
Posts: 78
Joined: Wed Jul 19, 2017 10:23 am

Re: FCEUX Default Memory Values and Rom for Reading Values.

Post by CLChambers00 »

To get more specific, with NES Who Framed Roger Rabbit, the addresses 0012, 0013, 0014, 0015, 0043 are constantly changing variables every frame and are even influenced by inputs, and even though I get one set of values for these addresses with Bixhawk for the first 10 frames, I am not able to simulate these same values with FCEUX even after setting the RAM Init to all FF, load the rom, start the tas editor, and watch these addresses in the RAM. No matter what setting I choose, whether default, 00, or FF, even if for a frame or two it may appear to have used the setting, by frame 4 it all switches to the exact values it gives me every single time no matter what. So it does not appear to be working as intended because Bizhawk which defaults to all FF, gives me a set of values that I am unable to duplicate with FCEUX.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: FCEUX Default Memory Values and Rom for Reading Values.

Post by rainwarrior »

MOST games will set initial values for quite a lot of RAM within a frame or two of startup (often all RAM). In these cases whatever the emulator initialized it as is irrelevant, it's determined by the ROM not the emulator. What you see in RAM on frame 2 usually has little or nothing to do with what was in RAM at power-up.

This setting ONLY matters in games where the game accidentally (or in some cases intentionally) does not initialize some value in RAM before it reads it, but this is a relatively rare thing.

BizHawk and FCEUX could have many other emulation differences besides the power-on RAM state. Just because you have them both start with RAM with $FF doesn't mean they are the same emulator in all other respects. (Though, if you're not using the "new ppu" setting, I would recommend doing that at least, since it is a lot more accurate than the default old ppu.)
CLChambers00
Posts: 78
Joined: Wed Jul 19, 2017 10:23 am

Re: FCEUX Default Memory Values and Rom for Reading Values.

Post by CLChambers00 »

I was under the impression that Who Framed Roger Rabbit had uninitialized memory since I was able to manipulate the RNG via inputs and these manipulations did not yield the same results in Bizhawk, FCEUX, Frontloader w/ Everdrive. Who Framed Roger Rabbit is an LJN title like Nightmare on Elm Street which I know functions similarly. I was using Old PPU in FCEUX, will this yield different results by using New?

If the game initialize these values then that does not explain why Bizhawk has this occur on frame 2 and FCEUX has this occur on frame 4, or perhaps maybe that difference does not matter at all? IF more differences can exist than mere RAM Initial State, then perhaps this is more complicated than I first thought. :(
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: FCEUX Default Memory Values and Rom for Reading Values.

Post by rainwarrior »

CLChambers00 wrote:I was under the impression that Who Framed Roger Rabbit had uninitialized memory...
Who Framed Roger Rabbit initializes everything except the stack page:

Code: Select all

 00:8031: A9 00     LDA #$00
 00:8033: AA        TAX
 00:8034: 95 00     STA $00,X @ $0000 = #$00
 00:8036: 9D 00 02  STA $0200,X @ $0200 = #$00
 00:8039: 9D 00 03  STA $0300,X @ $0300 = #$60
 00:803C: 9D 00 04  STA $0400,X @ $0400 = #$36
 00:803F: 9D 00 05  STA $0500,X @ $0500 = #$21
 00:8042: 9D 00 06  STA $0600,X @ $0600 = #$1F
 00:8045: 9D 00 07  STA $0700,X @ $0700 = #$32
 00:8048: E8        INX
 00:8049: D0 E9     BNE $8034
Unless the PRNG is on the stack page (which doesn't seem likely to me, from a brief inspection with the debugger), the power-on values of RAM are not going to influence it.

It does seem to use the stack page for NMI updates (the PLA, STA $2007 technique) but it appears to fully initialize any part of the stack page it uses before reading it. So... I don't see any "unitialized RAM" bug here, at first glance.

Do you know where the PRNG seed is stored in this game?
...since I was able to manipulate the RNG via inputs and these manipulations did not yield the same results in Bizhawk, FCEUX, Frontloader w/ Everdrive.

I was using Old PPU in FCEUX, will this yield different results by using New? ... If the game initialize these values then that does not explain why Bizhawk has this occur on frame 2 and FCEUX has this occur on frame 4, or perhaps maybe that difference does not matter at all?

IF more differences can exist than mere RAM Initial State, then perhaps this is more complicated than I first thought. :(
In a lot of cases the difference between emulators will be subtle/irrelevant to what you're trying to do.

RAM's power-on state, for example, isn't necessarily a factor in why the behaviour is different (and from what I mentioned above, it really shouldn't be a factor in this game).

There are a lot of things that could explain the difference between seeing something on frame 2 and frame 4. NES games normally need to wait 2 frames before they start doing anything because the PPU has a warmup cycle that you need to wait for. How that warmup state is emulated might effect this specific timing, not really in a way that would change how a game works, but it might make that initial wait last more time, so yes I think it's probable that this 2 frame difference doesn't matter in this case. It could even be something as simple as maybe BizHawk has an additional 1 or 2 frames of "reset" that comes before the first frame of CPU running, etc. I'm not really sure, but this difference isn't necessarily very meaningful.

New PPU has better emulation, and BizHawk is a more recent and more accurate emulator in general, so the new PPU setting should maybe be closer to BizHawk's, but I don't really know how different they are as emulators. I think it's just generally a good idea to use the new PPU unless trying to run an old TAS file or have a slow computer.

Lots of games have a PRNG that ticks every frame, so the very specific timing of when you press buttons can easily change the outcome. In a game that does that, unless you're using a TAS there's really no way to compare it. You wouldn't be able to get the same results every time with human input.


If you want to investigate the PRNG, the first thing I'd suggest is try to figure out where it resides in RAM, and then watch how/when it changes.
CLChambers00
Posts: 78
Joined: Wed Jul 19, 2017 10:23 am

Re: FCEUX Default Memory Values and Rom for Reading Values.

Post by CLChambers00 »

Thanks for the response. I have been observing the addresses 0012, 0013, 0014, 0015, and 0043 because they are constantly changing every frame and are even influenced by inputs. Are one of these the PRNG address you are referring to? I am not sure. But I have observed that the values in these addresses were always the same in FCEUX no matter what RAM Init State I used. But in Bizhawk, these addresses had different values. For instance,

FCEUX
Address 0043 had with Old PPU
Frame 4: Zero
Frame 5: 125
Frame 6: -40
Frame 7: -2
Frame 8: 1

Though with New PPU 0043 has 127 in frame 5, and has a 77 instead of 76 on frame 17, but a lot of the other numbers seem the same. Address 0043 can not be manipulated with inputs until frame 18.

What is interesting is that with New PPU values for addresses 0012, 0013, 0014, and 0015 are also different with new versus with Old, these start changing values at frame 16:

Values at Frame 16 with NEW:

0012 has 69

0013 has 109

0014 has -71

0015 has 55

Old PPU has:

0012 has -61

0013 has 47

0014 has -71

0015 has -22

Now let me share a little more of what I have been doing. I have been able to duplicate the same "seed" with Roger Rabbit in order to speed run the same item placements. I have been holding A from power on and press and hold start around the first opportunity to do so, and I continue to hold A and Start until the following addresses populate with values which do so within 4 frames during a deadzone transition between the title screen and the screen that show how many lives you begin with. I have been able to get the same outcome using both an Everdrive with my Frontloader, and the same Everdrive with my TopLoader. I have not yet tried an original cart which should arrive in a few days to do more testing.

Address for item spawns. These addresses populate with values as explained and remain the same unless it is an item that is replenish-able and re-spawns in another location once collected.
0657 Shoes
064B Rattle
0639 Detonator
0631 Whistle
0645 Baseball
0661 Will Piece #1
065D Will Piece #2
0663 Will Piece #3
065F Will Piece #4

When I run NEW PPU, and I use no input manipulation, and only do start for one frame on Frame #534, which is the first frame possible to start the game, the item spawns are

0657 has 41
064B has 128
0639 has 28
0631 has 21
0645 has 52
0661 has 6
065D has 2
0663 has 16
065F has 13

But with Old PPU these values are

0657 has 43
064B has 42
0639 has 22
0631 has 20
0645 has 53
0661 has 6
065D has 2
0663 has 16
065F has 12

So simply using either Old or New PPU changes the outcomes in FCEUX using the default 00 00 00 00 FF FF FF FF Ram Init State.

However, using Bizhawk gives us another set of values with same one frame input start on frame number 534.

0657 has 41
064B has 128
0639 has 28
0631 has 19
0645 has 47
0661 has 7
065D has 2
0663 has 16
065F has 13

This Bizhawk outcome is similar to NEW PPU in FCEUX except that three of the addresses are different.

So changing the initial Ram state in FCUEX does not alter the outcome, but using NEW verses Old PPU in FCEUX changes it, and Bizhawk is unlike either of these outcomes.

And the outcomes I get with my Everdrive with Top and Front Loader also differs from these three emulator outcomes. I will try an original cart with my Top and Front Loader to see if any of these three emulator outcomes match with one of these two hardware configurations. If not, then I am not sure how to force these emulators to correlate so I can TAS out variations of input manipulations that I can utilize in actual speedrun attempts.
CLChambers00
Posts: 78
Joined: Wed Jul 19, 2017 10:23 am

Re: FCEUX Default Memory Values and Rom for Reading Values.

Post by CLChambers00 »

I am curious exactly how the different PPU is causing these values to be different, and if it would be possible or a simple solution just to write a Lua Script to overwrite address 0043 with different values and then check outcomes, but I am not sure if 0043 is what I think it is, nor do I know if it would be this simple to respond to the different PPU outcomes?
CLChambers00
Posts: 78
Joined: Wed Jul 19, 2017 10:23 am

Re: FCEUX Default Memory Values and Rom for Reading Values.

Post by CLChambers00 »

So I wrote a Lua Script in order to change the 0043 address on frame 5 to what it was with Old PPU, while still using New PPU, and it continued to changed according to New PPU instead of old. I was hoping that by changing this initial value that it would progress differently but it didn't do anything at all, hmmm.
CLChambers00
Posts: 78
Joined: Wed Jul 19, 2017 10:23 am

Re: FCEUX Default Memory Values and Rom for Reading Values.

Post by CLChambers00 »

I just tried the same thing with addresses 0012, 0013, 0014, and 0015 and the same thing happened. I changed the values on one frame to what it would be for Old PPU, and when I advanced one frame I only got the New PPU results. Not sure how these numbers are being influenced or what else I might be able to try to hopefully get the emulator to play out differently. Maybe it is a single memory address but I am sure it is much deeper than that perhaps???
CLChambers00
Posts: 78
Joined: Wed Jul 19, 2017 10:23 am

Re: FCEUX Default Memory Values and Rom for Reading Values.

Post by CLChambers00 »

Is there a quick way to see what is causing the initial values in these addresses on the first frame it is changed from a zero value?
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: FCEUX Default Memory Values and Rom for Reading Values.

Post by rainwarrior »

Debug > Debugger...

There's a breakpoints panel in the top right. Click "Add"

Type in the address (or address range), check off "write", select CPU Mem.

This breakpoint will halt execution whenever it is written to and show you the code that is responsible. (You can click "Run" to resume, and in the breakpoints list you can double click one to toggle it on or off.)
CLChambers00
Posts: 78
Joined: Wed Jul 19, 2017 10:23 am

Re: FCEUX Default Memory Values and Rom for Reading Values.

Post by CLChambers00 »

I see read and execute as options to check as well, it doesn't stop if I have nothing checked though does this mean that read is when that address is read by something else, and execute is when it is used by something else? I am confused.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: FCEUX Default Memory Values and Rom for Reading Values.

Post by tepples »

"Read" means the address is the operand in an instruction that reads memory, such as $0127 in LDX #$04 ADC $0123,X.

"Execute" means the address is the first byte of an instruction, such as $A060 if the first byte of ADC $0345 is at $A060.
CLChambers00
Posts: 78
Joined: Wed Jul 19, 2017 10:23 am

Re: FCEUX Default Memory Values and Rom for Reading Values.

Post by CLChambers00 »

Anyone interested in helping me determine what causes values to populate and why the values that it does in the following addresses:

0657 Shoes
064B Rattle
0639 Detonator
0631 Whistle
0645 Baseball
0661 Will Piece #1
065D Will Piece #2
0663 Will Piece #3
065F Will Piece #4

Likewise, anyone interested in helping me understand why FCEUX (Old PPU), FCEUX (New PPU), and Bizhawk all have different values for the following addresses:

0012, 0013, 0014, 0015, and 0043

What specifically is causing different values and different outcomes? And how might I change how it works so that I can TAS more states than just FCEUX (Old PPU), FCEUX (New PPU), and Bizhawk?

Any and all help would be greatly appreciated, would be willing to compensate someone's time and expertise in helping me unravel this.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: FCEUX Default Memory Values and Rom for Reading Values.

Post by rainwarrior »

addresses $43-45 appear a temporary place that A,X,Y are stored during the NMI routine. Since the A register is changing constantly in normal use, the very specific timing that NMI fires will interrupt it and store different values. (Thus old PPU or new PPU could cause very subtle differences in timings that affect what code is interrupted). The NMI only stores A most of the time, which is why you noticed only $43 changing.

I don't think the contents of $43-45 have any gameplay effects, though. They seem to be isolated for this purpose.
Post Reply