nesdev.com

It looks like Nestopia, also, only supports M2- and PPUA12- based IRQs. I have no idea if any existing emulator can support this mapper hack authentically.

Hey, looks like it's emulation is troublesome!!

Just a small epilogue... when I bought it, the vendor sold me cheaper because it was "defective":

I took the risk and bought it anyway, since it was playable at least.
I tested it in a couple of clones and this supposed deffect never showd up.
Looks like the defect was on his console, who knows...

Still can't working.

joe,can you working fine?

I think that it's more of a Splinter Cell scenario in your case, Fisher.


sorry

_________________
This is a block of text that can be added to posts you make. There is a 255 character limit.

Is there an emulator that can use PPU A13 to generate IRQs? (MMC3 uses PPU A12 to generate IRQs.)

Otherwise, you can use a hack to generate one IRQ for every two scanlines (count += 43 on each scanline), but timing won't be correct.

Oh yeah!
People keep saying I should play that series of games, and I always keep forgotting.

Don't feel sorry!
It was a joke, intended to someone else to laugh and joke too, like you did.

Joe and Zxbdragon, I think proper support for this pirate mapper would need a rewrite of the emulator's core. Would it?
For a user's perspective this would not do much difference, since the original game is already playable.
But the on the developer's side, it's the challenge of doing it properly that makes all the difference.
If I'm understanding properly what I've been reading, this is the fuel that keeps emulation community as a whole active.
So I say: Power to you guys! Don't give up.
As a old boss I had said: The impossible is only a little bit protracted. (hope I have translated it right)

That depends on the emulator. I've only looked at FCEUX, and it doesn't provide any way for the mapper to track PPU A13. The easy hack would be to just trigger the IRQ every other scanline, but timing would be wrong. It may be possible to do it better using a combination of scanline and CPU-cycle counters in FCEUX, but that's more work than I'm willing to put into this (and probably still wouldn't be accurate).

If there's an emulator core that has some way for the mapper to track the PPU A13 line, then I'll give it a shot.

Nestopia's code base also seems to have only implemented support for PPU A12 and M2-based IRQs, even though the OO goo makes it look like it should be more useful... ("What do you mean no one ever implemented Nst::Core::Timer::A13 ?")

I strongly suspect the answer is "no one has ever written support for that in an emulator because this is the first board documented to do this"

I thought MMC5's timer used three consecutive PPU reads with A13 low as the trigger to find the next scanline. What did I miss?

Nestopia doesn't implement it that way.

It implements the MMC5 IRQ by violating the abstraction around the PPU's H and V counters.

What is the difference between A13,A12?

There are 341 dots in each scanline. The PPU reads memory every other dot, or 170 reads per scanline.
Normally, the PPU alternates between two nametable reads and two pattern table reads, performing 42 full sets of four reads each scanline.
When the PPU is reading the first pattern table, A12 and A13 are both low.
When the PPU is reading the second pattern table, A12 is high and and A13 is low.
When the PPU is reading nametables, A12 is low and and A13 is high.

How an A12-based timer works: (MMC3)
The PPU performs 32 sets of reads for background, 8 sets of reads for sprites, and then 2 more sets of reads for the background to set up the next scanline. If a game puts background tiles in the first pattern table and sprite tiles in the second pattern table, then A12 will be low during nametable and background pattern fetches, which represent most of the line, and it will go high several times near the end of the scanline when the PPU is fetching sprite patterns. By watching for several successive reads with A12 low followed by a read with A12 high, the mapper can infer that a new scanline has started.

How an A13-based timer might work:
Between one scanline and the next, the PPU's state machine pauses, causing it to read nametables four times in a row: the first of a set of four twice (ignored) plus the first two of the next set of four (used). By watching for several successive reads with A13 low, the mapper can infer that a new scanline has started.

EDIT: MMC5 relies on the same phenomenon as an A13 spreader but compares the whole address instead of just watching A13.

This should be titled "How the MMC5's scanline timer works":


This pirate port instead just counts falling edges of PPU A13, which happens during at the beginning of each pattern table fetches for both sprites and background tiles.

So I guess this must be the PA13 counterpart of the JY Company mapper (209 and its subsets 90 and 211), whose PA12 counter is followed by a division by 8 instead of a pulse spreader.

M2 prescaler: VRC IRQ, JY Company
PA12 spreader: MMC3
PA12 prescaler: JY Company
PA13 spreader: MMC5
PA13 prescaler: This


EDIT: Mistake stricken per Drag's result