Bad nametable and memory access in Iceclimber

[kingdiesel]

Working on getting Ice Climber working and running into two weird issues. First the nametables seems good, but then when they start scrolling there appears to be a weird offset:



I looked over my mirroring code and I think it's correct, and SMB seems to be working well:

Code: Select all

if (GetROM().GetHeaderData().m_flags_6.Bits.m_mirroring == 0)
{
	if (mirrored_position >= 0x2400 && mirrored_position < 0x2800)
	{
		mirrored_position &= 0x23FF;
	}
	else if (mirrored_position >= 0x2C00 && mirrored_position < 0x2FFF)
	{
		mirrored_position &= 0x2BFF;
	}
}
else
{
	if (mirrored_position >= 0x2800 && mirrored_position < 0x2C00)
	{
		mirrored_position &= 0x23FF;
	}
	else if (mirrored_position >= 0x2C00 && mirrored_position < 0x2FFF)
	{
		mirrored_position &= 0x27FF;
	}
}

Second, I seem to be receiving reads to an odd memory location $58A9. I found someone else ran into this issue from a deleted reddit post, but a resolution was never posted.

Perhaps the two issues are related. If anyone's run into something like this, I'd appreciate a tip....otherwise back to sleuthing .

[rainwarrior]

The stuff from that reddit post doesn't look like code, it looks like data accidentally disassembled as code.

The problem isn't probably to do with mirroring, but maybe to do with vertical wrapping? I'm not sure what to suggest. You seem to be slipping by 1 byte every 7 rows?

[kingdiesel]

I'm starting to think the two oddities may be related. When I run FCEUX it definitely encounters the same address for BIT:

Code: Select all

F3C5: 2C A9 58  BIT $58A9 = #$55

This line of code occurs every time we scroll high enough to hit a tile boundary. So given the cpu memory map, we know that this address is in cartridge space. However given the addresses in NROM, this is not in one of the valid ranges. So I'm not sure what to return here. More sleuthing awaits

[Fiskbit]

Accesses to unmapped regions should return open bus, which holds the last value that was placed on the bus. Under normal circumstances, that BIT should operate on value $58, the high byte of the address, which was previously put on the data bus by the cartridge ROM. Things can get complicated if you have DMC DMA running, which could occur between the high address fetch and the value fetch, thus changing open bus. My understanding is that open bus also decays over time, but that's something you don't need to worry about in emulation.

[Quietust]

Disassembling the code in that region reveals that the BIT instruction is actually being used as a 3-byte NOP in order to conditionally execute an LDA #imm instruction:

Code: Select all

F3BB: A4 00     LDY $00
F3BD: A5 8D     LDA $8D
F3BF: 29 01     AND #$01
F3C1: D0 03     BNE $F3C6 <-- jumps into the middle of the BIT instruction
F3C3: A9 55     LDA #$55

F3C5: 2C A9 58  BIT $58A9
_or_
F3C5: 2C        .db $2C
F3C6: A9 58     LDA #$58

F3C8: 99 04 03  STA $0304,Y
F3CB: 99 04 03  STA $0305,Y
F3CE: 99 04 03  STA $0306,Y
F3D1: 60        RTS

None of the code following that BIT instruction depends on any of the relevant flags, so the value it got from open bus shouldn't matter.

[calima]

Now that's what I call desperate to save bytes.

[Fiskbit]

I've actually made use of that a lot, though sometimes it can cost you extra cycles, and you need to be careful that the embedded instruction doesn't point into registers that are modified on read.