I recently looked at the Virtual Console version of SMB2J and saw that besides GAP and CRC data there were three differences in three bytes compared to the current fds dump. one at 0x2260 which had ff for 58 (I figured out that this controls the World A-D lag on the top of the screen).
But I cannot figure out the assembly and needed help to figure out the two other changes, and what they affect, they are at 0x82df, which has 4a in reg dump but the VC dump has 18 and at 0x82e9 has 4a in reg dump but VC dump has also 18. Can you help out by telling me what is located here at 0x82df and 0x82e9 (headered rom)? I know it has to do something with the game loading but don't know exactly what? Thanks for your time
P.S. I know its not graphics as they are earlier bytes in the rom and they don't seem to affect levels (I tried changing the bytes to something else to see if the byte change would be visible). This is important because the VC might either be a bug correction, or it means our current fds dump is bad.
No DWedit, the copyright data is located closer to the beginning of the rom. Here is the disassembly of the area (I believe, as I said I can't read asm it may be the wrong place for the headered rom, I used my hex editor to find the differences at offset 0x82df and 0x82e9, which is how I found the differences). The full disassembly file can be found at: http://www.romhacking.net/documents/613/
If anybody can help me find the differences at the offsets 0x82df and 0x82e9 please do let me know what is located here, I want to know if SMB2J is good dump or VC was just a bug correction.
Those offsets you posted, being file offsets for the ROM file itself, did not correspond at all to the disassembly you posted.
As for the changes, those two bytes are actually opcodes. $4A is the opcode for LSR, and $18 is the opcode for CLC. The code surrounding the two does indeed revolve around disk loading, but more specifically, handling disk errors. The code waits for a disk eject and disk reinsert by polling the FDS drive status register at $4032. What's strange to me is that both of these were patched with CLC, when one should have been patched with an SEC (the first one). I'm guessing the change was implemented in case the code ever ran, to prevent it from being stuck in a loop waiting for a non-existent $4032 on the VC NES emulator, though I could be wrong since I know zero about it.
doppelganger wrote:What's strange to me is that both of these were patched with CLC, when one should have been patched with an SEC (the first one). I'm guessing the change was implemented in case the code ever ran, to prevent it from being stuck in a loop waiting for a non-existent $4032 on the VC NES emulator, though I could be wrong since I know zero about it.
I assume that if the emulator never emulates the disk removal (probably it just flips directly) it's always going to be in the same value, thereby both checks should be identical to skip it. I assume it's CLC for when the disk is inserted?
