nesdev.org

tokumaru wrote:I'm not an expert in NESASM, but I think you're supposed to use .rsset and .rs for declaring variables... I suspect that having .org $0000 and then .org $8000 in bank 0 is generating a lot of blank ROM data, which gets output to the final ROM, throwing bank sizes and addresses off.

	.bank 0
	.org $0000
characterselected      = $0001
changescreen           = $0002
loadtext               = $0003
position               = $0004

	.bank 0
	.org $8000
	.rsset $0000
characterselected      .rs 0

	.rsset $0001
changescreen           .rs 0

	.rsset $0002
loadtext               .rs 0

	.rsset $0003
position               .rs 0

tokumaru wrote:Your NMI is placed after the end of bank 0 and before the start of bank 1. I have no idea how NESASM handles that. The NMI handler should be somewhere within the fixed bank.

tokumaru wrote:As for the reset stubs, they need to be present in every MMC1 bank, not every NESASM bank. The unnecessary stubs and vectors probably aren't causing any problems, but I though I'd point out that you only really need the ones in odd NESASM banks (1 and 3).

You can't have 3 CHR banks. ROM sizes must be powers of 2, so the number of banks needs to be a power of 2 too (1, 2, 4, 8, 16, and so on). Emulators may refuse to load ROMs with weird chip sizes, or map then in inconsistent ways.

tokumaru wrote:How big is the final .NES file, in bytes?

Jay John wrote:

Code: Select all

ldhormir:
	lda #$80
	sta $8000
	lda #%00011011
	sta $8000	
	lsr a 

tokumaru wrote:That's correct for 16 bytes + 2x 16KB + 4x 8KB, so it doesn't look like there's any big discrepancy between what you're trying to make and what the assembler is actually outputting.

The best thing to do IMO would be to trace through your program in FCEUX or Mesen... Open the debugger, pause execution and reset, then step through the instructions to see where things go wrong. This will quickly tell you if the MMC1 initialization is working, whether the fixed bank is mapped correctly, whether the bankswitch code is being correctly called...

Jay John wrote:Though I feel I haven't described the problem properly.
What happens is: The code seems to run properly through bank 0 and 1, but then I put a JMP in bank 1 to go to a routine that's at the beginning of bank 2, but instead of loading what's in bank 2, it loads what's in bank 0, basically restarting the game, but with the wrong data, making everything look glitched.

I think that the game is loading the part in the memory where the jump leads to, but in bank 0, I've no idea why though.
I've even move the location of the routine in bank 2 and it seems to confirm my theory that that's what's happening, since it loads a different screen that's in bank 0.

lidnariq wrote:This may be what's going wrong...

The effect of writing to the MMC1 with the $80s bit set is to set both "P" bits, which sets a fixed bank at $C000-$FFFF equal to the last bank. You then immediately switch that to the fixed $8000-$BFFF configuration... so your code is probably going haywire here.

You should never need to write to the MMC1's "reset" bit after you actually reset.

koitsu wrote:To solve your problem, you're going to have to step through your code in a debugger. FCEUX can do this, or Mesen. The one advantage (in this case) that Mesen has is that its debugger GUI shows you what PRG bank is actively mapped to what memory range (look at the bottom of the debugger window). Situations like "I ask for PRG bank 2 but I get PRG bank 0!" can 100% be watched/monitored by stepping through your bankswitch routine in the debugger.

The situation would affect CHR banks too, naturally, depending on what you're doing right or wrong. It just happens to be "easier" to figure out CHR bank swap issues because your code still works / nothing crashes, you just get the wrong tiles/pattern table data (for CHR-ROM, that is).

bfind	
	sei
	ldx #$80
	txs
	stx $8000
	jmp start
	.dw NMI
	.dw bfind
	.dw bfind	

lidnariq wrote:Mesen's debugger literally tells you what banks are mapped to CPU and PPU memory. You should really pay attention to that and find where it ceases to be what you believe it should be.

Jay John wrote:But after a frame it's like this

tokumaru wrote:

Jay John wrote:But after a frame it's like this

Step trough the code to see when exactly it changes to this.

ldhormir:
	lda #%00011011
	sta $8000	
	lsr a 
	sta $8000	
	lsr a
	sta $8000	
	lsr a
	sta $8000	
	lsr a
	sta $8000
	rts