Question 4 Nightwulf (or NES hackers)

[MarquisEXB]

Hey Nightwulf I have a question. Obviously the game takes the ERA value (bit) and adds 100, then divides that by 100. For example, the highest ERA value that can be stored is 3.55, which is stored by a bit of 255. When the computer checks a pitcher's ERA, he gets that value (255) then puts it through the above equation (255+100)/100=3.55. Similarly, a value of 0 comes up as a 1.00 ERA.

So my question is: can we find where it does that in the program & edit it so that we can gets the ERA values between let's say 2 & 4.55?

[nightwulf]

I bet we could. I've got a few files with the ROM disassembled. I'll take a look at it tomorrow .. I'm all tired.

Nightwulf

[MarquisEXB]

Thanks. I forgot there is a debugger in FCEU. Unfortunately it's lacking a varying degree of where you can stop it (IE. run 1 step, run 5 steps, run 10 steps, run 100 steps...). I tried last night, but using that debugger got me nowhere.

I had one for a Sega emulator that had this functionality & hacked Madden '92 (my favorite football game) so that the checksum doesn't run & you can edit the stats.

I appreciate the help & if you have a better debugger I'd be willing to try that as well.

Mike

[Gantry]

This might be tricky to find, since we don't really know where and how they make this calculation.  The best thing would proabably use a Hex editor and fuck with values...

Hopefully they use the Hex code for 100 (64) in their calculations, perhaps just edit each one (in the non-player data fields) and see what happens...

[nightwulf]

Got it!! First off, I'd like to thank those who made this discovery possible: fceud for a working 6502 debugger, nester for a clean view of RAM in real-time, Dr. Pepper for providing caffeine, and Camel for providing smokes. Without any of these, none of this would've been possible.

That said, it's a little tough to explain. Without a working knowledge of 6502 assembler, it's very tough to explain. Attached is a text file showing how ERAs are converted from their stored value to their displayed value. Read it if you're that bored.

I do have a little assembler knowledge. If you wanted to change the offset to zero, it could be done by modifying one byte of the ROM. Anything other than that will require adding instructions to the ROM and changing the filesize. It's very possible. Just let me know what you'd like it changed to.

Nightwulf

[nightwulf]

Even better. I was feeling nerdly today, and have written a hack for the game to allow you to change the offset between stored ERA and displayed ERA to any arbitrary value. Instructions will be available at the following URL:

http://nightwulf.rbicentral.com/erahack.txt

I'm almost sure this works perfectly. Please let me know of any problems.

Nightwulf

[Gantry]

Warning! - This is a bit over the place, forgive me.  Probably should research a little more but asking you is easier (smiley):

This is all great nightwulf!  Finally got off my ass and looked at those text files.  Don't know 6502 assembler (though referenced quickly with a doc on Zophar, not too many instructions) but is it possible to perform instructions (specifically store to a memory location) on half a byte?  If so, then some of what I say is unnecessary...

It seems like most of the logic in your text files is used to calculate the bytes stored in $40 $42 & $43.  I don't understand where these addresses are located.   If it's a zero-page address, isn't $0040 already storing player data?  

Though it may be a bit ugly, couldn't we store the ERA in three bytes instead of one?  I was thinking we could use "Unknown 1 & 2" in the pinch-hitter spots.  Since these bytes aren't used for hitters, we'll have each pitcher use the U1 & U2 bytes to their corresponding pinch-hitter.  By "corresponding pinch-hitter" I mean the pinch hitter who is in the same spot in the selection as the pitcher.  So Tudor, since he's the first pitcher, would use the unknown bytes for the first pitch-hitter, Oquendo.  This would give us three bytes to work with and all pitcher fields are exactly 64 bytes from their corresponding pinch hitter field.  This should make obtaining the data quite easy...

Again with Tudor:

His standard RBI ERA byte - 01
Oquendo's Unknown 1 - 02
Oquendo's Unknown 2 - 08

With three bytes for the ERA data, we wouldn't have to use all that logic and simply LDA/STA those bytes right to $40, $42 and $43.   Most importantly, this would let us give the pitchers any ERA we want to.  We wouldn't have any offset or 2.55 range...

Does this make sense?  In my mind it seems easy to implement and should result in less code than the method used by the game itself.  But once again, I don't really have a grasp of 6502 or how this may affect other portions of the game...

[nightwulf]

It seems like most of the logic in your text files is used to calculate the bytes stored in $40 $42 & $43.  I don't understand where these addresses are located.   If it's a zero-page address, isn't $0040 already storing player data?  

I have no idea specifically what $40-$43 are being used for in this case, since I didn't go much further in the code after I found what I was looking for. Notice though, that #$25 is written to $41. In the character tiles used in RBI Baseball, #$25 is the decimal point. My assumption is that the entire "ERA string" is stored temporarily in $40-$43 before being passed along to the PPU to display it.

These addresses are located in NES address space. Note that offsets in ROM data do not correlate directly to NES RAM. The NES address space is 65536 bytes, from $0000-$FFFF. $8000-$FFFF is reserved for software (the ROM). ROMs are different sizes, and there are many "memory mappers" which load parts of the ROM into memory. As an example, RBI Baseball uses the "MMC3" memory mapper. There are 4 "pages" of PRG RAM, each of which is 16384 (4000 hex) bytes long. The last page (ROM offsets C010-1000F) is always available in RAM from C000-FFFF. The other three pages (ROM offsets 0010-400F, 4010-800F, 8010-C00F) are switched in and out of RAM as needed at 8000-BFFF.

So, when the code is writing to an address, it's writing to NES RAM; not to what you see in the game ROM.

With three bytes for the ERA data, we wouldn't have to use all that logic and simply LDA/STA those bytes right to $40, $42 and $43.   Most importantly, this would let us give the pitchers any ERA we want to.  We wouldn't have any offset or 2.55 range...

As we talked about earlier, my biggest concern with changing the storage method of ERAs is that it wouldn't work correctly in any existing RBI editor. It's definitely possible though. ROM editors: any interest in this feature?

Nightwulf

[MarquisEXB]

It's a great idea, but I think it's too much work for the small gain you would get. I'm quite content with knowing I can change the range of ERAs, although they would still be limited between 2.55. It's a limitation I can live with.

If you're going to change that, you might as well edit it so you can have 5 pitchers, or a DH, etc.

Mike

[nightwulf]

If you're going to change that, you might as well edit it so you can have 5 pitchers, or a DH, etc.

This really wouldn't be that difficult to code. 5 pitchers would require massive changes that I couldn't do without suffering a nervous breakdown and killing innocent people.

A designated hitter. Oh my god. I hate you again ... I bet I could code that.

Nightwulf

[Gantry]

What nightwulf and I were talking about via IM was the possibility of adding more teams to the game.  We're fairly sure it wouldn't be all that difficult.  If RBI doesn't concern itself with the number of teams once you select them, I think it can be done...

Difficult yes (especially with man-hours not brain hours, assembly code isn't too elegant) but doable.  Of course it's easy for me to say since nightwulf will do 95% of the work, but I think it's our highest long-term goal...

That's definitely long-term though, much work to be done before we can even think of that.  I think adding rangless ERA (and like nightwulf said, average) are attainable short-term goals...

My goal is to get the RBI tech page up, with all the memory offsets for editable fields in the game.  I'll be getting started on it hopefully soon...