It is currently Mon Jul 16, 2018 4:07 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 6 posts ] 
Author Message
PostPosted: Thu May 10, 2018 10:36 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 559
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.


Top
 Profile  
 
PostPosted: Fri May 11, 2018 12:55 pm 
Offline

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


Top
 Profile  
 
PostPosted: Fri May 11, 2018 1:44 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:52 pm
Posts: 376
Location: UT
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..)


Top
 Profile  
 
PostPosted: Fri May 11, 2018 1:52 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7303
Location: Seattle
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)


Top
 Profile  
 
PostPosted: Fri May 11, 2018 2:24 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:52 pm
Posts: 376
Location: UT
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.


Top
 Profile  
 
PostPosted: Fri May 11, 2018 8:59 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 559
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.)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot] and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group