1

Newcomer's Board / Re: Any similar Second Quest hacks for Super Mario Bros 1?

« on: November 14, 2020, 02:08:17 am »

Doesn't this hack accomplish what you want: https://www.romhacking.net/hacks/5354/ ?

2

Newcomer's Board / Re: Super Street Fighter II: The New Challengers [Request For Assistance]

« on: November 07, 2020, 01:27:43 pm »

Can you link me the resource you were looking at?

There was no resource specific to the game.  I got the info by finding the HP address for each player, dumping trace logs of the frames around when player 2 was taking damage, and analyzing the code in the log.  I did find http://www.romhacking.net/utilities/1123/ useful for debugging.  Also, http://www.romhacking.net/utilities/963/ has a disassembler that lets you specify the starting and ending locations for disassembly.  Unfortunately, neither of those emulators allow you to copy the disassembly from the respective windows.

Here are some codes akin to what you're talking about: https://www.gamegenie.com/cheats/gamegenie/genesis/super_sf2.html

I ran some of those codes through the decoder at http://games.technoplaza.net/ggencoder/js/ and found that they do match up with ROM locations from my analysis.  For example, code 2 "Don't take damage except from throws or grabs--both players" works by calculating the damage but never updating the player's HP with the new value.  Incidentally, it also implies that throws and grabs work via a different routine than the one I've found.

There's another issue that makes hacking this game difficult: ROM checksum fixing tools do not work properly after making edits.  Probably related to the "[c] This code represents a cart with known faulty checksum routines." code that GoodGen puts on it.

3

Newcomer's Board / Re: Super Street Fighter II: The New Challengers [Request For Assistance]

« on: November 07, 2020, 01:15:16 am »

OK, so through trial and error I figured out using the RAM search function in Gens ("less than" searches for 2-byte values) that the damage scaler stars (1-8 stars per player) are stored in hex value 00FFFCEA. I was proud that I somehow figured that out. For whatever reason, player one's values are in increments of 256, whereas player 2's values are 1-8.

Good work.  It turns out that the damage scaler is only one byte for each character, though.  0x00FFFCEA is the player 1 address and 0x00FFFCEB is the player 2 address.  Not knowing the size (number of bytes) of data definitely makes searching more difficult.  If you've found the size of one value, the same type of data for other players/characters is often the same size.

I've looked into this project, and it requires knowledge of how to use a debugger and how to analyze assembly language.  The damage done depends on several variables:

• The damage scaler values for both the attacking player and defending player
• The character selected for the attacking player
• The type of attack being done
• The health of each player (there's something special about values of 0x50 for the attacker and 0x26 for the defender)
• Some other value that might come from the RNG

There might be other variables that I haven't found yet.  For example, there's an address that gets a special value if one of the characters is Vega, but IDK if that ends up being used for the damage calculation or is used for something else.  Based on the analysis I've done so far, my best guess is that the raw damage values are stored in a table ranging from 0x31772 to 0x31881 in the ROM file.

If you want more practice with RAM searching, try to find the addresses of some of those variables I listed.

4

Newcomer's Board / Re: Super Street Fighter II: The New Challengers [Request For Assistance]

« on: October 27, 2020, 12:11:38 pm »

Would that allow me to adjust how many "stars" correspond to the damage scaler on the 2P screen?

It will be a starting point, but you might need to analyze the game's assembly in order to actually make that a permanent change.

Is there a program to do this sort of thing to find the hex values, or is this something that you do in the actual emulator while it's running, and you look to see which values are changing?

RAM search is something you do in an emulator while it's running.  I don't know if Kega Fusion has that capability.  I mostly use BizHawk for systems other than the NES.  There are tutorials available about searching RAM, such as this one and this one from TASVideos.  You can also find video tutorials on YouTube.

5

Newcomer's Board / Re: Super Street Fighter II: The New Challengers [Request For Assistance]

« on: October 22, 2020, 10:05:33 pm »

I would start off with a RAM search to determine where the damage scaling option is stored for each player in VS. Mode.  It might also be helpful to find the player HP addresses.  Then you'll likely need to use a debugger or a trace log to determine how the damage scale is converted to damage amounts.

6

ROM Hacking Discussion / Re: Wizards & Warriors

« on: January 21, 2020, 01:39:42 am »

As far as maps go, I've made some notes about tiles and collision detection in Wizards & Warriors III as part of a project to improve the current TAS.  I also have information about how enemy spawns, item spawns, doors, and a number of other things work in that game.

7

Help Wanted Ads / Re: Iron Sword TITLE SCREEN

« on: January 12, 2020, 02:53:50 am »

What type of glitches are you getting?

8

Help Wanted Ads / Re: Iron Sword TITLE SCREEN

« on: January 07, 2020, 07:23:35 pm »

I wrote a Python script to compress nametables using Ironsword's format.  It's available here.  Note that it requires a 960-byte input file of the nametable data.  This is only 0x3C0 bytes.  My earlier post said to copy 0x400 bytes.  The last 0x40 bytes in the PPU memory are the attribute table.  This is stored elsewhere in the ROM file, so you should not compress it along with the other nametable data.

9

Help Wanted Ads / Re: Iron Sword TITLE SCREEN

« on: January 07, 2020, 01:33:49 pm »

Getting an uncompressed copy of the nametable can be relatively easy.  Open up FCEUX's Hex Editor, change the view to PPU Memory, and go to the nametable area based on the memory map.  You'll need to determine which nametable is used to display the graphics, which you can do by opening the Name Table Viewer.  For both Ironsword and Wizards & Warriors III, it looks like the same information is mirrored in each nametable.  So go to $2000 in the hex editor and copy 0x400 bytes.  You now have the nametable.  You can do the same thing with the pattern tables, which store the graphical tiles (the memory map indicates that each pattern table is 0x1000 bytes long).

Figuring out the compression scheme can be more difficult.  In this case, I looked for a sequence of bytes in the nametable that I could use to search for the data in the Ironsword ROM file.  There's a nice sequence at $2049 starting with 0xC0 and ending with 0xD1.  In the best case scenario, you'll find this sequence or some subset of it exactly once in the ROM file.  This turns out to be the case for Ironsword; the sequence occurs only at 0x97D5.  Actually, it looks like it extends to the following 0x00 0xC2 0xC3.  Then the 0xD2 0xD3 0xD4 sequence from PPU memory $2069 occurs a few bytes later in the ROM.  The 0xFE 0x09 0x03 that separates the two sequences is probably part of the compression scheme; there's something similar (0xFE 0x09 0x02) right before that first sequence.

Using the debugger, I stepped through some of the decompression routine and determined that the first byte (0xFE) is a control byte.  The second and third bytes are used to generate an offset via the formula 0x20 * byte3 + byte2.  For example, taking byte2 = 0x09 and byte3 = 0x02, you get an offset of 0x49.  Adding that to $2000 yields the starting point for the 0xC0 sequence in the PPU memory.

This works nicely but leads to the question of how you actually put a byte with value 0xFE into the PPU memory, corresponding to a lower part of the N in Ironsword.  It turns out that there are some other control bytes, including 0xFF and 0xFD.  0xFF appears to indicate the end of the nametable data.  0xFD is followed by another byte that indicates how many of the following bytes are supposed to be transferred to PPU memory.  For example, you have the sequence 0xFE 0x09 0x05 0xFD 0x13 starting at 0x9814 in the ROM file.  You calculate the value 0xA9 based on the 0xFE part, yielding a starting point of $20A9.  Then the 0x13 bytes starting with 0xF6 and ending with 0xF9 should appear at $20A9 in the PPU, which is indeed the case.

Since you dumped/copied the nametable data from Wizards & Warriors III using the hex editor, you don't technically need to figure out that compression scheme.

- decompress and extract the Ironsword and WW3 nametable data for the title screen (using a pre-existing decompressor & tool, I assume)

FCEUX's hex editor is the tool, in this case.  For other systems, the emulator may or may not have similar capabilities.  Figuring out the compression scheme may require knowledge of assembly language.

hoping that the game title is done with background tiles alone

You can toggle background and sprite graphics on/off via the Config -> Display menu in FCEUX to check this.  It turns out to not be the case for Ironsword but is the case for Wizards & Warriors III.

- rewrite the portion of the Ironsword nametable data that displays the game's title, using the WW3 nametable data (which I assume reuses the same tiles for "W", etc.) as a model -- no need to reinvent the wheel there, except to change "III" to "II"

Right, except that the tiles are different in the two games.

- recompress the Ironsword nametable data, hoping that it fits in to the space already allocated

Right.  The available space is probably the most significant problem.  Also, I'm not aware of a tool to do the recompression.

- individually replace the relevant tiles in Ironsword with the corresponding tiles in WW3, hoping that nothing in the game's title graphic is reused elsewhere on screen (or in the game).

Right.  Depending on how many tiles you need to replace, you may need to eliminate part of the knight graphic in order to make them all fit.

But how do you organize the nuts and bolts of this process in a way that doesn't leave you hopelessly disoriented?

The workflow that you posted is a good guide.  Take it one step at a time, and finish each step before you move onto the next.

10

Help Wanted Ads / Re: Iron Sword TITLE SCREEN

« on: January 06, 2020, 07:46:41 pm »

My intentions with the previous posts were not to make you give up on this project but rather to provide some starting knowledge that you will need in order to get it done.  The problem is that I'm not sure just how much you know already.  Obviously, you can use a graphics editor, such as Tile Layer Pro.  What can you tell me about hexadecimal numbers?  How about nametables for NES games?  Both of those are key things that will be necessary in order to get this project done.

For example, when I posted earlier that title screen graphics start at 0x24383 in the ROM for background and 0x373CD for sprites, what did that tell you?  Were you able to find the graphics in Tile Layer Pro or some other editor?

11

Help Wanted Ads / Re: Iron Sword TITLE SCREEN

« on: January 06, 2020, 12:16:11 pm »

Can you list some of the other games that don't have a graphical "mess"?  One possible factor with Ironsword is that the graphical data are not all aligned on a multiple of 4 or 16 bytes.  It's possible that the graphical data are intermixed with code, but I haven't analyzed the ROM adequately to say that for sure.

12

Help Wanted Ads / Re: Iron Sword TITLE SCREEN

« on: January 04, 2020, 03:13:06 am »

Are you familiar with how NES graphics work, including pattern tables and nametables?  If you do not understand these terms, you might want to read this document or the nesdev wiki to learn more.  To accomplish what you want, you will need to extract the graphical data from the Wizards & Warriors III ROM, insert it into the Ironsword ROM, then modify the nametable for the Ironsword title screen.  Each game has a different compression scheme for the nametable data.

[Spoiler:]

13

Help Wanted Ads / Re: Iron Sword TITLE SCREEN

« on: January 03, 2020, 02:09:21 pm »

Which other programs have you tried, specifically, and what do you mean by the tiles being a mess?  Have you tried adjusting the starting address/offset in the programs to a value other than a multiple of 16 (0x10)?  By doing that and comparing to the graphics in FCEUX's PPU Viewer, it looks like the title screen is a combination of background and sprites, with the data starting at

Spoiler:

0x24383 for background
0x373CD for sprites

14

ROM Hacking Discussion / Re: Dumping old lost NES roms/games

« on: December 31, 2019, 02:28:20 pm »

I decided to take a look into the Elf Land situation using FCEUX 2.2.3.  The multicart ROM that I used is 393,333 bytes in size and has these hashes:

MD5: aad2e7bc4e1da2ddc7f91b44bb8181a9
SHA-1: af767130ec844ab7fe5952e4ac1cfcfe8b53ba71

Based on the way that FCEUX's hex editor shows the ROM file, it appears that FCEUX removes bytes 0x10 through 0x63 from the ROM (additional header info?).  The ROM locations indicated below all assume that this removal has been done, unless specified otherwise.

Via basic RAM search, you find that $0052 stores the game selection on the menu screen.  Setting a read breakpoint on that address leads to this code when you press A or B:

Code: [Select]

>00:C13F:A5 52     LDA $0052
 00:C141:48        PHA         ; Save the value of $0052
 00:C142:A2 00     LDX #$00
 00:C144:8A        TXA
 00:C145:95 00     STA $00,X   ; Clear out RAM
 00:C147:9D 00 02  STA $0200,X
 00:C14A:9D 00 03  STA $0300,X
 00:C14D:9D 00 04  STA $0400,X
 00:C150:9D 00 05  STA $0500,X
 00:C153:9D 00 06  STA $0600,X
 00:C156:9D 00 07  STA $0700,X
 00:C159:CA        DEX
 00:C15A:D0 E9     BNE $C145
 00:C15C:68        PLA
 00:C15D:85 52     STA $0052   ; Restore the value of $0052
 00:C15F:A2 00     LDX #$00
 00:C161:8A        TXA
 00:C162:9D 00 01  STA $0100,X ; Clear out the stack
 00:C165:CA        DEX
 00:C166:D0 FA     BNE $C162
 00:C168:CA        DEX
 00:C169:9A        TXS         ; S = 0xFF
At this point, all of the internal RAM should be zero except for the value of $0052.  Then this happens:

Code: [Select]

>00:C16A:A5 52     LDA $0052   ; A = game selection
 00:C16C:AA        TAX
 00:C16D:BD 87 C1  LDA $C187,X ; 0x0197 in the ROM file
 00:C170:85 54     STA $0054
 00:C172:BD 4F C2  LDA $C24F,X ; 0x025F in the ROM file
 00:C175:85 55     STA $0055
 00:C177:0A        ASL
 00:C178:AA        TAX
 00:C179:BD 17 C3  LDA $C317,X ; 0x0327 in the ROM file
 00:C17C:85 00     STA $0000
 00:C17E:E8        INX
 00:C17F:BD 17 C3  LDA $C317,X
 00:C182:85 01     STA $0001
 00:C184:6C 00 00  JMP ($0000) ; $C33F for Elf Land = 0x034F in the ROM file
The data at 0x0327 seems to be the jump table mentioned by PowerPanda previously.

Code: [Select]

00:C33F:A5 54     LDA $0054   ; From above
 00:C341:85 15     STA $0015
 00:C343:4C 53 C5  JMP $C553
...
>00:C553:A2 00     LDX #$00
 00:C555:BD 7F C5  LDA $C57F,X ; 0x058F in the ROM file
 00:C558:9D 00 04  STA $0400,X
 00:C55B:E8        INX
 00:C55C:E0 06     CPX #$06
 00:C55E:D0 F5     BNE $C555
 00:C560:A5 55     LDA $0055   ; From above
 00:C562:0A        ASL
 00:C563:AA        TAX
 00:C564:BD 85 C5  LDA $C585,X ; 0x0595 in the ROM file
 00:C567:05 5D     ORA $005D   ; Should be 0 because RAM was cleared out
 00:C569:8D 01 04  STA $0401
 00:C56C:E8        INX
 00:C56D:BD 85 C5  LDA $C585,X ; 0x0595 in the ROM file
 00:C570:8D 02 04  STA $0402
 00:C573:78        SEI         ; This looks typical for
 00:C574:D8        CLD         ; game start-up code
 00:C575:A2 FF     LDX #$FF
 00:C577:AD 02 20  LDA PPU_STATUS
 00:C57A:10 FB     BPL $C577
 00:C57C:4C 00 04  JMP $0400
The values at $0400 were set in the code starting at $C553 earlier.  For Elf Land, it looks like:

Code: [Select]

>  :0400:8D C8 F0  STA $F0C8   ; Causes a bank switch
   :0403:6C FC FF  JMP ($FFFC) ; $FFFC is the reset vector = $B814 for Elf Land
Examining the values that get loaded into $8000, $A000, $C000, and $E000 after the bank switch suggests that the Elf Land part of the ROM starts at 0x8064 in the fully headered (i.e., without removing bytes 0x10 throught 0x63) multicart ROM.  I haven't tested further to determine if any additional bank switching is done, but this should serve as a start for making a ROM that contains only Elf Land.

EDIT:
I did some more work on this.  By comparing FCEUX's PPU Viewer with the graphics in YY-CHR, it appears that Elf Land's graphics are the 32 KiB (0x8000 bytes) starting at 0x5006C in the fully headered multicart ROM.  You can combine the 32 KiB starting at 0x8064 (PRG) with those 32 KiB (CHR) to make an Elf Land-only ROM.  The NESDev wiki says that Elf Land is a CNROM game, so I added an iNES header with values 0x02 0x04 0x31 for bytes 4-6 and 0x00 for bytes 7-15.  This allows the game to run, but it loads incorrect level data when you start playing.  I think that this is a result of FCEUX's default initial RAM state.  You might be able to fix this by inserting that internal RAM clearing code somewhere in the ROM, if you can find free space.

EDIT 2:
It turns out that someone from Bootleg Games Central (see Googie's post earlier) has already done the fix.  The solution was more simple than I thought, simply changing:

Code: [Select]

00:B81E:A5 15     LDA $0015
to

Code: [Select]

00:B81E:A9 00     LDA #$00
FCEUX's default initial RAM state would cause A to be loaded with 0xFF when reading $0015, leading to the incorrect level data that I mentioned.  The fixed ROM has four other bytes changed, including two in the header, but I believe that the game should work with just the info provided so far.

15

ROM Hacking Discussion / Re: List of Co-op / Multiplayer hacks

« on: October 20, 2019, 05:39:01 pm »

This may not meet your criteria, since it expands upon the multiplayer capabilities already present in the game rather than adding more players: https://www.romhacking.net/hacks/414/

I've considered making a four-player Tournament Mode hack but have other projects that I'd like to finish first.

16

Gaming Discussion / Re: How to use mGBA for Zook Man ZX4 (Luke Ren ZX4)

« on: March 17, 2019, 04:28:22 pm »

Please check if your ROM matches these hashes:

MD5: 9f966d8f9f2865e96a42eed33a201cde
SHA-1: f0b655c5b01870da92c9ea84736cb005a4cc4f9c
SHA-256: 52af6d9323f43254fe958c90f07d08bb48adafc534517433a14fddf18eca4b37

17

Gaming Discussion / Re: How to use mGBA for Zook Man ZX4 (Luke Ren ZX4)

« on: March 17, 2019, 12:30:09 am »

Which version of mGBA are you trying?  Does the "black screen" contain any text or graphics at all?

18

ROM Hacking Discussion / Re: Need help tracking down a hex address in ROM (Castlevania)

« on: September 03, 2017, 12:04:04 am »

First, I'd like to point out that NesDev is a good reference for NES programming and Andrew Jacobs's site is a good reference for the 6502 CPU in particular.  You may want to use the Addressing and Reference pages of the latter site when going over the code that follows.

The emulator I used was FCEUX 2.2.3.  If you open the PPU viewer while on the title screen, you see the sprites on the left and the background tiles on the right.  It looks like the sprite for the first part of the C is tile 0x3C and the second part is 0x3E; you can get the number by hovering your mouse over the tiles in the PPU viewer.  This will be useful later.

Sprites are handled via NES registers $2003, $2004, and $4014.  The first one of those determines where data is written into sprite RAM, which is usually called OAM.

The FCEUX debugger comes into play here.  Load the ROM and pause emulation at the title screen.  Then open up the debugger and add a write breakpoint on $2003 (Add button -> enter 2003 into Address box -> check the Write box -> leave the CPU Mem option toggled -> click OK).  This causes emulation to stop on a write to register $2003.  Click Run, and the debugger should stop at the following code:

Code: [Select]

>07:C064:8D 03 20  STA $2003
 07:C067:A0 02     LDY #$02
 07:C069:8C 14 40  STY $4014The second and third lines are the useful ones, because they indicate that the sprite information is copied from CPU RAM $0200-$02FF via DMA.  DMA is used to copy 256 bytes into OAM at once rather than having to do it byte-by-byte.  This means that the sprite information is stored in CPU RAM $0200-$02FF in the order y-coordinate, tile, attributes, x-coordinate for each sprite that you mentioned above.  So $0200, $0204, $0208, etc. have the y-coordinate; $0201, $0205, $0209, etc. have the tile; and so on.

Now we need to find out where the data at $0200-$02FF comes from.  Set a write breakpoint on that range of addresses using the same process as before, but enter 200 into the first Address box and 2FF into the second.  You can disable the $2003 breakpoint by double-clicking on it in the list so that the letter E disappears after the colon.  When you click Run, the debugger should stop at the following code:

Code: [Select]

>00:80F4:9D 00 02  STA $0200,X
 00:80F7:B1 08     LDA ($08),Y
 00:80F9:9D 01 02  STA $0201,XThis is nice, because the second and third lines indicate that the tile values come from an address related to the value at $0008 in CPU RAM.  It may not be the C tile that's being processed, however.  To find that one in particular, we'll modify the breakpoint.  Select the $0200-$02FF breakpoint, click Edit, enter A==#3C into the Condition box, then hit OK.  This is now a conditional breakpoint because it will only work when the A==#3C condition is met.  It causes emulation to stop when $0200-$02FF is being written to but only if the accumulator (A) has value 0x3C, which is the first part of the C tile.  We know that the accumulator will have that value because of the LDA and STA instructions.

One thing to mention here is that the disassembly you see on the left side of the debugger is not always the order in which the code is executed.  Branch and jump instructions can cause instructions to be skipped or can jump to other areas of code.  This is relevant because the instruction immediately above the one indicated by the > may not be the one that was executed before it.  The trace logger can record the instructions in the order in which they are executed.  So open up the trace logger (Debug -> Trace Logger) and set it to log the last 100 lines in the drop-down box.  Then click Start Logging.  Now go back to the debugger and click Run.  It should stop at code similar to

Code: [Select]

>00:80F9:9D 01 02  STA $0201,XThe last line in the trace logger should be

Code: [Select]

$80F7:B1 08     LDA ($08),Y @ $9AAB = #$3CAgain, this means that the tile value comes from an address related to the value at $0008 in CPU RAM.  The info after the @ symbol indicates that the exact address is $9AAB. 

In the hex editor, go to $9AAB; File -> Goto Address is easier than scrolling.  You should see that 0x3C value that we want.  If you right-click on it and select Go Here In ROM File, you'll end up at 0x1ABB.  The nice thing about the hex editor is that you can change values as desired and see the effects without having to modify, save, and reload the ROM file.  You may need to reset the emulation, however.  Just select the address that you want to modify and type whatever value you want.  (Note: This may cause the game to crash depending on what you modify.)  To play around with this without interruptions, disable any breakpoints in the debugger and click Stop Logging in the trace logger.

If you look at the values following that 0x3C at 0x1ABB, you'll see 0x3E four bytes later.  This is the tile value for the second part of the C.  This may be a coincidence, since the data doesn't have to be stored sequentially in the ROM, but changing it in the hex editor also changes that part of the C.  Now we can hypothesize that the data indeed is stored sequentially, so the X-coordinate should be two bytes after the tile value, at 0x1ABD.  If you change this in the hex editor, the first tile of the C moves horizontally.  Keep doing this for every fourth byte, and you'll modify the positions of the sprites on the title screen.  You can do File -> Save Rom As to save your hack as a new ROM file when you're done.

There are a number of potential problems with this approach that I could discuss at this point, but what questions do you have first?

19

ROM Hacking Discussion / Re: Need help tracking down a hex address in ROM (Castlevania)

« on: August 24, 2017, 11:01:35 pm »

The data for the sprite positions on the title screen starts at 0x1ABA in the ROM.  The quick way to move the sprites for the C 8 pixels to the left (your screenshot suggests to me that this is what you want to achieve) is to subtract 8 from each fourth byte starting at 0x1ABD and ending at 0x1B12.  I would be happy to explain how I found that information, but it does involve assembly and debugging.

20

ROM Hacking Discussion / Re: How to add more teams to a sports game? (SNES)

« on: February 25, 2012, 11:57:57 pm »

You could start by determining how the stats for the teams are stored currently. You will need to know this in order to successfully add info for the new teams.