In my frivolous quest to support every mapper under the sun, I spent some time getting those "wonderful" old FFE-modified ROM images to run properly, and noticed something possibly relevant beyond that niche application. (I eventually hope to support original FFE-format images but cannot seem to find that mythical "FFE CD-ROM" that the ancient iNES documents talk about.)
The [h FFE] version of "Dragon Ball: Daimaou Fukkatsu" uses a very odd method of frame timing. You recall that the game originally uses Mapper 16, which has a simple 16 bit cycle IRQ at $7F0A/$7F0B/$7F0C (enable/low/high), which the game uses to bankswitch mid-screen. Well, the FFE hack replaces these writes with a simple $E3 write to $4025, and precedes the normal IRQ handler routine with a write to $4024 (without bothering to initialize the accumulator) and a simple countdown of its own. Experimentation shows that raising repeated IRQs in intervals of 149 CPU cycles get the frame timing about right. This matches puNES' "drive_delay". Nintendulator and FCEUX use a delay of 200 instead. Another [h FFE] hack that uses this method is "Super Chinese 2".
As later generations of the Game Doctor/FFE Super Magic Card have their own proper cycle IRQ, this hack must have been made for an earlier, IRQ-less model, which is why it seems to abuse the RAM adapter's disk IRQ instead (although it's still not clear why they would not just use the RAM Adapter's timer IRQ). Recall that those "copier" units are set up to sit between the Famicom and the FDS RAM adapter. I wonder how reliable this method would be for normal FDS games, whether it can be used at all, and what the correct delay value would be, given the difference between emulator implementations.
The [h FFE] version of "Dragon Ball: Daimaou Fukkatsu" uses a very odd method of frame timing. You recall that the game originally uses Mapper 16, which has a simple 16 bit cycle IRQ at $7F0A/$7F0B/$7F0C (enable/low/high), which the game uses to bankswitch mid-screen. Well, the FFE hack replaces these writes with a simple $E3 write to $4025, and precedes the normal IRQ handler routine with a write to $4024 (without bothering to initialize the accumulator) and a simple countdown of its own. Experimentation shows that raising repeated IRQs in intervals of 149 CPU cycles get the frame timing about right. This matches puNES' "drive_delay". Nintendulator and FCEUX use a delay of 200 instead. Another [h FFE] hack that uses this method is "Super Chinese 2".
As later generations of the Game Doctor/FFE Super Magic Card have their own proper cycle IRQ, this hack must have been made for an earlier, IRQ-less model, which is why it seems to abuse the RAM adapter's disk IRQ instead (although it's still not clear why they would not just use the RAM Adapter's timer IRQ). Recall that those "copier" units are set up to sit between the Famicom and the FDS RAM adapter. I wonder how reliable this method would be for normal FDS games, whether it can be used at all, and what the correct delay value would be, given the difference between emulator implementations.