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

Famicom Jump II (Mapper 153) IRQ
http://forums.nesdev.com/viewtopic.php?f=3&t=15967
Page 1 of 1

Author:  NewRisingSun [ Sun May 21, 2017 6:20 am ]
Post subject:  Famicom Jump II (Mapper 153) IRQ

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.

Author:  AWJ [ Sun May 21, 2017 9:13 am ]
Post subject:  Re: Famicom Jump II (Mapper 153) IRQ

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)

Author:  lidnariq [ Sun May 21, 2017 11:18 am ]
Post subject:  Re: Famicom Jump II (Mapper 153) IRQ

... 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.

Author:  AWJ [ Mon May 22, 2017 7:18 pm ]
Post subject:  Re: Famicom Jump II (Mapper 153) IRQ

I can write a test program if someone has cartridge(s) they can EPROM-ize.

Author:  lidnariq [ Tue May 23, 2017 12:33 am ]
Post subject:  Re: Famicom Jump II (Mapper 153) IRQ

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...

Author:  NewRisingSun [ Thu May 25, 2017 11:46 am ]
Post subject:  Re: Famicom Jump II (Mapper 153) IRQ

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? :)

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