This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
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.htmlI 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.
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.
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.
- 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 aloneYou 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 allocatedRight. 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.
>00:C13F:A5 52 LDA $0052
00:C141:48 PHA ; Save the value of $0052
00:C142:A2 00 LDX #$00
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:C15A:D0 E9 BNE $C145
00:C15D:85 52 STA $0052 ; Restore the value of $0052
00:C15F:A2 00 LDX #$00
00:C162:9D 00 01 STA $0100,X ; Clear out the stack
00:C166:D0 FA BNE $C162
00:C169:9A TXS ; S = 0xFF
>00:C16A:A5 52 LDA $0052 ; A = game selection
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:C179:BD 17 C3 LDA $C317,X ; 0x0327 in the ROM file
00:C17C:85 00 STA $0000
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
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:C55C:E0 06 CPX #$06
00:C55E:D0 F5 BNE $C555
00:C560:A5 55 LDA $0055 ; From above
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: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
> :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
00:B81E:A5 15 LDA $0015
00:B81E:A9 00 LDA #$00
>07:C064:8D 03 20 STA $2003The 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.
07:C067:A0 02 LDY #$02
07:C069:8C 14 40 STY $4014
>00:80F4:9D 00 02 STA $0200,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.
00:80F7:B1 08 LDA ($08),Y
00:80F9:9D 01 02 STA $0201,X
>00:80F9:9D 01 02 STA $0201,XThe last line in the trace logger should be
$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.