Famicom Jump II (Mapper 153) IRQ

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Famicom Jump II (Mapper 153) IRQ

Post by NewRisingSun »

https://wiki.nesdev.com/w/index.php/Bandai_FCG_board states that "The IRQ counter is clocked by M2. There is no reload value, nor does it stop: after it becomes 0, it becomes 65535. Writes are not shadowed, so you either need to be careful about timing or pause the counter while you manually reload."

This cannot be true for Famicom Jump II (Mapper 153), as the screen split at the title screen will be glitched, and CHR RAM will become corrupted, if writes are not shadowed. FCEUX loads the IRQ counter from the shadow value when register 0xA is written to, and has registersx 0xB and 0xC go to the shadow value instead of the IRQ counter itself. When I do that as well, the problems disappear.
AWJ
Posts: 433
Joined: Mon Nov 10, 2008 3:09 pm

Re: Famicom Jump II (Mapper 153) IRQ

Post by AWJ »

Results of some very brief debugging and disassembling:

$800A (IRQ enable/acknowledge) is set first thing in the NMI handler, before any code with unpredictable running time (e.g. VRAM transfers, music engine), and is cleared by the IRQ handler.

$800B and $800C (16-bit cycle counter) are set in the "spin-and-wait-for-next-frame" routine, which is reached above the raster split (i.e. when $800A is set to 1) but with a variability of tens of scanlines. The code that sets them doesn't touch $800A at all.

I don't see how the title screen can possibly work according to the description of the mapper in the wiki. Both FCEUX and Nestopia implement $800B-800C as a latch which is copied to the live counter when $800A is written to.

(Incidentally, Famicom Jump II is clearly based on Dragon Quest IV's codebase, which I've reverse engineered a fair bit of. Its IRQ/BRK handler thus has to handle both raster IRQs and the BRK-based interbank function call system inherited from DQIV, which didn't use hardware IRQs)
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Famicom Jump II (Mapper 153) IRQ

Post by lidnariq »

... I have a sinking feeling that this might be a difference in behavior between the FCG-1/2 and LZ93D50. Naruko did not notice a difference in behavior, but he may have not been looking.

"Fortunately" m153/157/159 are unambiguously an LZ93D50.
AWJ
Posts: 433
Joined: Mon Nov 10, 2008 3:09 pm

Re: Famicom Jump II (Mapper 153) IRQ

Post by AWJ »

I can write a test program if someone has cartridge(s) they can EPROM-ize.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Famicom Jump II (Mapper 153) IRQ

Post by lidnariq »

If you can find a game that could be tested via hot-swapping, that's even more likely to find someone willing to help. "All" you should need is a game that points its IRQ vector via RAM, or can be tricked into something equivalent...
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: Famicom Jump II (Mapper 153) IRQ

Post by NewRisingSun »

On a less technical note, why does this game have no copyright note at the title screen? Or is it like Final Fantasy, where the real title screen appears after having played the game for thirty minutes? :)
Post Reply