nesdev.com
http://forums.nesdev.com/

Mapper 153 and Famicom Jump 2 (CRC: 3F15D20D)
http://forums.nesdev.com/viewtopic.php?f=3&t=14497
Page 1 of 1

Author:  colinvella [ Wed Jul 06, 2016 9:06 am ]
Post subject:  Mapper 153 and Famicom Jump 2 (CRC: 3F15D20D)

Does anyone have experience with Famicom Jump 2 (CRC: 3F15D20D? My ROM was actually mapped to mapper 16 but with some header overrides ala NEstopia), I set this ROM to run on mapper 153 (LZ93D50 with SRAM). I suspect the problem is the outer bank register in the range $8000-$8003, which allows the programmer to switch to the upper 256K of PRG rom.

My logic is that if a byte value set in any of the four addresses $8000, $8001, $8002, $8003 has the lower bit set (value & 0x01 != 0), then $40000 is added to the PRG banked address. Is this logic correct? The code seems to set different values across the 4 addresses so I'm thinking I got it all wrong.

Author:  Joe [ Wed Jul 06, 2016 9:50 am ]
Post subject:  Re: Mapper 153 and Famicom Jump 2 (CRC: 3F15D20D)

The outer bank register is selected by the PPU address (A11 and A10). If the four outer bank registers contain the same value, then you can ignore that inconvenient detail. However, if the four outer bank registers don't all contain the same value, you have to use the PPU address to figure out which register is currently selecting the outer bank.

Author:  colinvella [ Wed Jul 06, 2016 12:37 pm ]
Post subject:  Re: Mapper 153 and Famicom Jump 2 (CRC: 3F15D20D)

Joe wrote:
The outer bank register is selected by the PPU address (A11 and A10). If the four outer bank registers contain the same value, then you can ignore that inconvenient detail. However, if the four outer bank registers don't all contain the same value, you have to use the PPU address to figure out which register is currently selecting the outer bank.


Does this mean I have to track the 4 values (0th bits) in $8000, $8001, $8002, $8003 individually and then decide which one applies depending on the bit 11 and 10 combination of the last PPU read or write?

(forgive me for my general ignorance of hardware - one of the reasons of doing this project is to fill in a low-level hardware gap I've had for decades!)

This is what I found in the spec:
Code:
Mapper 153 ($8000-$8003 only):
7  bit  0
---- ----
xxxx xxxP
        |
        +-- Select 256KiB PRG ROM outer bank
As this mapper has no CHR ROM and only 8KiB fixed CHR RAM, the CHR ROM selection lines are repurposed similarly to SUROM. So CHR A10 OUT is connected to PRG A18 out on the mapper IC. The mapper's PPU A12 and PPU A13 inputs are tied to ground, but the PPU A11 and PPU A10 inputs are still connected, so the first 4 CHR bank 'P' bits should be set to the same value, or the game will flip between 256KiB PRG outer banks while rendering.

Author:  colinvella [ Wed Jul 06, 2016 1:19 pm ]
Post subject:  Re: Mapper 153 and Famicom Jump 2 (CRC: 3F15D20D)

Tracing the writes to $8000-$8003 yielded the following:

Code:
Outer PRG Bank ($8000) = $01
Outer PRG Bank ($8001) = $01
Outer PRG Bank ($8002) = $01
Outer PRG Bank ($8003) = $01
:
Outer PRG Bank ($8000) = $01
Outer PRG Bank ($8001) = $01
Outer PRG Bank ($8002) = $01
Outer PRG Bank ($8003) = $01
:
Outer PRG Bank ($8000) = $01
Outer PRG Bank ($8001) = $01
Outer PRG Bank ($8002) = $01
Outer PRG Bank ($8003) = $01
:
Outer PRG Bank ($8000) = $00
Outer PRG Bank ($8001) = $00
Outer PRG Bank ($8002) = $00
Outer PRG Bank ($8003) = $00

Author:  colinvella [ Thu Jul 07, 2016 3:01 am ]
Post subject:  Re: Mapper 153 and Famicom Jump 2 (CRC: 3F15D20D)

Update: Tracing through the code reveals that writes to $8000-$8003 are written in immediate succession and with the same value. I think this is to ensure that the register value is correct, regardless of A10 and A11. The code actually also sets $8004-$8007 to the same value. The CPU goes through two instances of setting the outer PRG bank before it seemingly starts interpreting bogus code until it crashes to a read from absolute address $4B01 via the undocumented ALR opcode (a clear sign something has gone haywire). I'm beginning to think the problem is not the registers themselves (at least concerning this ROM), but how I am computing the address into the ROM file's PRG buffer.

I have a related question concerning PRG bank $C000-$FFFF. I know that in the Bandai mapper variants this is mapped to the last bank. My question is, in the case of mapper 153 that uses the outer PRG bank, is the last bank the last one of the lower 256K, and hence, is it affected by the outer bank register? Alternatively, is it set to the last bank of the upper 256K, that is, treated as the last bank of a flat 512K PRG buffer?

First instance of setting outer PRG Bank:
Code:
    ADDR  CODE         ASSEMBLER
    ============================
    $C86C $A9 $01      LDA #$01
    $C86E $8D $00 $80  STA $8000
    $C871 $8D $01 $80  STA $8001
    $C874 $8D $02 $80  STA $8002
    $C877 $8D $03 $80  STA $8003
    $C87A $8D $04 $80  STA $8004
    $C87D $8D $05 $80  STA $8005
    $C880 $8D $06 $80  STA $8006
    $C883 $8D $07 $80  STA $8007


Second instance of setting outer PRG Bank:
Code:
    ADDR  CODE         ASSEMBLER
    ============================
    $FFC0 $A9 $00      LDA #$00
    $FFC2 $2A          ROL A
    $FFC3 $8D $00 $80  STA $8000
    $FFC6 $8D $01 $80  STA $8001
    $FFC9 $8D $02 $80  STA $8002
    $FFCC $8D $03 $80  STA $8003
    $FFCF $8D $04 $80  STA $8004
    $FFD2 $8D $05 $80  STA $8005
    $FFD5 $8D $06 $80  STA $8006
    $FFD8 $8D $07 $80  STA $8007

Author:  lidnariq [ Thu Jul 07, 2016 10:10 am ]
Post subject:  Re: Mapper 153 and Famicom Jump 2 (CRC: 3F15D20D)

Like the various MMC1 boards that support 512 KiB of PRG by repurposing the CHR banking bits, the "fixed" bank isn't. (It tracks the outer bank select)

Author:  colinvella [ Fri Jul 08, 2016 1:27 am ]
Post subject:  Re: Mapper 153 and Famicom Jump 2 (CRC: 3F15D20D)

lidnariq wrote:
Like the various MMC1 boards that support 512 KiB of PRG by repurposing the CHR banking bits, the "fixed" bank isn't. (It tracks the outer bank select)


Thanks for clarifying this. Unfortunately I can't for the life of me figure out what's going wrong. I'm find it hard to follow what's happening with all the interleaved IRQ and JSR calls, but it's as if the stack is being corrupted somehow.

Code:
    $C0BF $20 $AC $FF  JSR $FFAC   ; call subroutine at SubRtFFAC
SubRtFFAC:
    $FFAC $8D $07 $05  STA $0507 
RelBrC0C2:
    $C0C2 $EE $0C $05  INC $050C 
    $C0C5 $BA          TSX       
    $C0C6 $BD $05 $01  LDA $0105,X
    $C0C9 $85 $20      STA $20   
    $C0CB $BD $06 $01  LDA $0106,X
    $C0CE $85 $21      STA $21   
    $C0D0 $A0 $00      LDY #$00   
    $C0D2 $B1 $20      LDA ($20), Y
    $C0D4 $29 $0F      AND #$0F   
    $C0D6 $C9 $07      CMP #$07   
    $C0D8 $F0 $16      BEQ $16     ; branch to RelBrC0F0
    $C0DA $C9 $0F      CMP #$0F   
    $C0DC $F0 $12      BEQ $12     ; branch to RelBrC0F0
    $C0DE $C9 $03      CMP #$03   
    $C0E0 $F0 $0E      BEQ $0E     ; branch to RelBrC0F0
    $C0E2 $C9 $0B      CMP #$0B   
    $C0E4 $F0 $0A      BEQ $0A     ; branch to RelBrC0F0
    $C0E6 $68          PLA       
    $C0E7 $A8          TAY       
    $C0E8 $68          PLA       
    $C0E9 $AA          TAX       
    $C0EA $68          PLA       
    $C0EB $40          RTI       
    $82A0 $54 $8C      DOP $8C,X  ; <--- things seem to start to go wrong after RTI (DOP, SAX, SRE undocumented opcodes are a bad sign)
    $82A2 $97 $4E      SAX $4E,Y 
    $82A4 $5F $D4 $CB  SRE $CBD4,X
    $82AA $C0 $F0      CPY #$F0   
    $82AC $98          TYA       
    $82AD $1C $3C $7A  TOP $7A3C,X
    $82B0 $00          BRK       
IrqHandler:
    $C68F $08          PHP       
    $C690 $78          SEI       
    $C691 $2C $15 $40  BIT $4015 
    $C694 $85 $30      STA $30   
    $C696 $86 $31      STX $31   
    $C698 $84 $32      STY $32   
    $C69A $BA          TSX       
    $C69B $BD $03 $01  LDA $0103,X
    $C69E $38          SEC       
    $C69F $E9 $01      SBC #$01   
    $C6A1 $85 $36      STA $36   
    $C6A3 $BD $04 $01  LDA $0104,X
    $C6A6 $E9 $00      SBC #$00   
    $C6A8 $85 $37      STA $37   
    $C6AA $A0 $01      LDY #$01   
    $C6AC $B1 $36      LDA ($36), Y
    $C6AE $48          PHA       
    $C6AF $29 $0F      AND #$0F   
    $C6B1 $29 $0F      AND #$0F   
    $C6B3 $C9 $07      CMP #$07   
    $C6B5 $F0 $3E      BEQ $3E     ; branch to RelBrC6F5
    $C6B7 $C9 $0F      CMP #$0F   
    $C6B9 $F0 $3A      BEQ $3A     ; branch to RelBrC6F5
    $C6BB $C9 $03      CMP #$03   
    $C6BD $F0 $33      BEQ $33     ; branch to RelBrC6F2
    $C6BF $C9 $0B      CMP #$0B   
    $C6C1 $F0 $60      BEQ $60     ; branch to RelBrC723
    $C6C3 $68          PLA       
    $C6C4 $28          PLP       
    $C6C5 $24 $A2      BIT $A2   
    $C6C7 $10 $22      BPL $22     ; branch to RelBrC6EB
RelBrC6EB:
    $C6EB $A4 $32      LDY $32   
    $C6ED $A6 $31      LDX $31   
    $C6EF $A5 $30      LDA $30   
    $C6F1 $40          RTI       
    $82B1 $00          BRK       
    $82B2 $00          BRK       
    $82B3 $00          BRK       
    $82B4 $60          RTS         ; ----------------
    $4101 $41 $41      EOR ($41,X) ; <---- something definitely wrong here, most likely before
    $4103 $41 $41      EOR ($41,X)
    $4105 $41 $41      EOR ($41,X)
    $4107 $41 $41      EOR ($41,X)
    $4109 $41 $41      EOR ($41,X)

Author:  AWJ [ Fri Jul 08, 2016 4:25 am ]
Post subject:  Re: Mapper 153 and Famicom Jump 2 (CRC: 3F15D20D)

colinvella wrote:
lidnariq wrote:
Like the various MMC1 boards that support 512 KiB of PRG by repurposing the CHR banking bits, the "fixed" bank isn't. (It tracks the outer bank select)


Thanks for clarifying this. Unfortunately I can't for the life of me figure out what's going wrong. I'm find it hard to follow what's happening with all the interleaved IRQ and JSR calls, but it's as if the stack is being corrupted somehow.[/code]


Can your emulator run Dragon Warrior 3 and 4, or the Final Fantasy 1+2 multicart? The Famicom Jump 2 board needs to work exactly the same way as the SUROM/SXROM boards. When the outer bank changes, $8000-BFFF must immediately remap to the appropriate inner bank (depending on the normal PRG register) of the new outer bank, and $C000-$FFFF must immediately remap to the last inner bank of the new outer bank. It looks like you aren't remapping $8000-BFFF correctly when the outer bank changes.

Author:  colinvella [ Fri Jul 08, 2016 4:49 am ]
Post subject:  Re: Mapper 153 and Famicom Jump 2 (CRC: 3F15D20D)

AWJ wrote:
Can your emulator run Dragon Warrior 3 and 4, or the Final Fantasy 1+2 multicart? The Famicom Jump 2 board needs to work exactly the same way as the SUROM/SXROM boards.


The games you suggested just generate a grey screen for now, but they are all MMC1 so that is a separate (albeit probably similar) issue in a different mapper implementation. I should say here that I do not reuse a lot of bank switching code, unlike what I have seen in some implementations of established emulators. Worth nothing is that the Final Fantasy 2 rom (CRC: 93A2EEFB) runs well on my MMC1 implementation but presumably, it does not use the MMC1 outer bank.

AWJ wrote:
When the outer bank changes, $8000-BFFF must immediately remap to the appropriate inner bank (depending on the normal PRG register) of the new outer bank, and $C000-$FFFF must immediately remap to the last inner bank of the new outer bank. It looks like you aren't remapping $8000-BFFF correctly when the outer bank changes.


My Bandai Jump 2 mapper should be doing exactly that. When using the lower bank, $8000-$BFFF is determined by a $4000 byte bank within the lower 256K as determined by the PRG register (which should range from $00 to $0F). When the outer bank is set, the $8000-$BFFF address range maps to a $4000 byte bank in the upper 256K.

The same goes for the $C000-$FFFF "fixed" bank that is mapped to $3C000-$3FFFF of the lower 256K rom, and likewise for the upper rom (that is, $7C000-$7FFFF when treating the ROM as a contiguous 512K array)

Author:  colinvella [ Fri Jul 08, 2016 6:35 am ]
Post subject:  Re: Mapper 153 and Famicom Jump 2 (CRC: 3F15D20D)

On a related note, my MMC1 implementation didn't support outer bank registers. Because MMC1 has quite a few variants, the online documentation recommends working on heuristics based on the catridge PRG ROM and CHR ROM/RAM sizes. Based on this I did manage to get Final Fantasy 1 & 2 multi cart to work. I had no success however with Dragon Warrior 3 and 4. Perhaps there are other unrelated issues.

Also, no further progress on Famicom Jump 2 - mapper 153.

Author:  colinvella [ Fri Jul 08, 2016 7:46 am ]
Post subject:  Re: Mapper 153 and Famicom Jump 2 (CRC: 3F15D20D)

Update: Final Fantasy I & II multicart is not crashing, but the initial game selection is not working - only FF I is loading. It seems quite obvious that the two games are stored in the individual banks and that somehow, the outer bank for FF II is not being selected. I will have to investigate further.

Update 2: Solved for FF I & II. Turned out I was not ignoring outer bank registers in CHR bank 1 when in 8k CHR mode, so the outer bank was being reset to the lower one, thus loading FF I instead of FF II.

Still no luck with DW III (gray screen) and DW IV (KIL opcode encountered)

Author:  AWJ [ Fri Jul 08, 2016 9:03 am ]
Post subject:  Re: Mapper 153 and Famicom Jump 2 (CRC: 3F15D20D)

Maybe the problem is with something other than the banking. Are you sure you implement the BRK instruction correctly? (IIRC DW4 uses it)

Author:  colinvella [ Thu Jul 14, 2016 3:48 am ]
Post subject:  Re: Mapper 153 and Famicom Jump 2 (CRC: 3F15D20D)

Update: I managed to get Dragon Quest IV, Dragon Warrior III and IV working!

It was all due to a bug in the BRK opcode instruction (I hadn't tested any games that explicitly called BRK up to this point). I was basically pushing PC instead of PC + 1 on the stack.

Solved thanks to the test ROM NEStress.nes. Kudos to whoever wrote it!

Edit: Mainly thanks to AWJ for pointing it out.. you were right on the mark!

Page 1 of 1 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/