This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

SMB2J Question

SMB2J Question
by on (#104164)
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.
Re: SMB2J Question
by on (#104165)
If it's code, maybe post the disassembly of the surrounding area. Did anything really obvious get changed, like a copyright date?
Re: SMB2J Question
by on (#104192)
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/

$0082B7: .BYTE $FF
$0082B8: .BYTE $50
$0082B9: .BYTE $40
$0082BA: .BYTE $20
$0082BB: LDA $0770
$0082BE: BEQ $830F
$0082C0: LDA $0E
$0082C2: CMP #$08
$0082C4: BCC $830F
$0082C6: CMP #$0B
$0082C8: BEQ $830F
$0082CA: LDA $B5
$0082CC: CMP #$02
$0082CE: BPL $830F
$0082D0: LDA $0787
$0082D3: BNE $830F
$0082D5: LDA $07EC
$0082D8: ORA $07ED
$0082DB: ORA $07EE
$0082DE: BEQ $8306
$0082E0: LDY $07EC
$0082E3: DEY
$0082E4: BNE $82F2
$0082E6: LDA $07ED
$0082E9: ORA $07EE

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.
Re: SMB2J Question
by on (#104210)
These offsets are found in Hex Editor
Re: SMB2J Question
by on (#104211)
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.
Re: SMB2J Question
by on (#104212)
So should 4a for 0x82df be preferred over 18 and the same for 0x82e9?
Re: SMB2J Question
by on (#104213)
Yes. Without the original instructions the routines will not poll correctly on the original hardware.
Re: SMB2J Question
by on (#104214)
I guess you are saying that the current fds dump besides crc and gap data is a good dump, it should not be changed to 18, for 4a would be correct?
Re: SMB2J Question
by on (#104249)
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?