Using FDS Disk IRQ (not Timer IRQ) for frame timing

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

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

Using FDS Disk IRQ (not Timer IRQ) for frame timing

Post by NewRisingSun »

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.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Using FDS Disk IRQ (not Timer IRQ) for frame timing

Post by lidnariq »

I'm a little surprised that the number 149 works out correctly. If that's one byte per IRQ, that's a data rate of 12KB/sec...

My understanding is that the entire 64KB of an FDS disk plays through in about 7.5 seconds (give or take), and that implies a data rate of about 9KB/sec....

Regardless, I'd naively expect the correct number to be some integer multiple of 8 (or 16?) of 21.5MHz clock cycles from the crystal in the FDS.
User avatar
loopy
Posts: 405
Joined: Sun Sep 19, 2004 10:52 pm
Location: UT

Re: Using FDS Disk IRQ (not Timer IRQ) for frame timing

Post by loopy »

lidnariq wrote:I'm a little surprised that the number 149 works out correctly. If that's one byte per IRQ, that's a data rate of 12KB/sec...
Yeah. 12K/s actually is the data rate of the FDS.
(Not sure where your 7.5s comes from, but there's plenty of extra slop from seeking, dead space at begin and end of disk, etc..)
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Using FDS Disk IRQ (not Timer IRQ) for frame timing

Post by lidnariq »

Hearsay. I've long since lost track of whence.

I don't suppose you have more precise timing from your FDSstick work? (Perhaps the bit rate is exactly Fosc÷224 ? That'd be 95880bit/sec, 11985Byte/sec, or a byte every 149⅓ Fcy = 448px)
User avatar
loopy
Posts: 405
Joined: Sun Sep 19, 2004 10:52 pm
Location: UT

Re: Using FDS Disk IRQ (not Timer IRQ) for frame timing

Post by loopy »

96.4kHz is often quoted as the true bit rate. I don't know where that originated (here maybe). I measured it with my fancy scope and came up with ~95.94kHz. Not a satisfying division of the 21.47727MHz crystal either, but that's what I got.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: Using FDS Disk IRQ (not Timer IRQ) for frame timing

Post by NewRisingSun »

Thanks, using an IRQ rate of 448 PPU cycles instead of 149 CPU cycles improves it somewhat. For this to work in the manner described, writing to $4024 would have to acknowledge the Disk IRQ however, and the Wiki does not mention that it does, and I don't want to change it before explicitly testing that on real hardware.

It's also not clear whether setting bit 6 of $4025, or just writing anything to $4025, should reset or align that counter; it would improve the aforementioned games, but that's not really the standard, having not seen the game perform on actual copier hardware.

(I have since found a third game using this technique: one of the two "Mapper 2" (actually FFE) hacks of Salamander uses it as well, while the other hack uses the normal CPU cycle timer found on the FFE Super Magic Card, and which is not emulated for Mapper 6 by known emulators.)
Post Reply