PowerPak MMC3 fixes: accurate IRQ, MC-ACC submapper, iNES 2 CHR-RAM

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderator: Moderators

User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: PowerPak MMC3 jitter fix for loopy's mapper

Post by rainwarrior »

Thanks for the verification.

Yeah, I did notice that Mesen's mapper randomization caused it to have wrong CHR. I wasn't sure if that was relevant on the real hardware or not, so it's good to have info on that.

When 4-scanline_timing.nes failed, did it fail on #3 specifically? (If the uninitialized CHR means the text is unreadable, the sound will still spell out the test number in a series of binary high/low tones, always starting with 1 leading 0 low tone.)
Trirosmos
Posts: 50
Joined: Mon Aug 01, 2016 4:01 am
Location: Brinstar, Zebes
Contact:

Re: PowerPak MMC3 jitter fix for loopy's mapper

Post by Trirosmos »

It seemed to always fail test #2, which is what we expected.

The weird part is that it seemed to only fail if it happened to land on the right CHR bank. Otherwise, it would always pass. He did try it several times.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: PowerPak MMC3 jitter fix for loopy's mapper

Post by rainwarrior »

Trirosmos wrote: Tue Nov 08, 2022 2:49 pmIt seemed to always fail test #2, which is what we expected.
Oh. Hrm, my mapper was always failing test #3.

Though looking at the source code for the test, I don't think I understand what should have been expected... why #2?

Let me ask if I have this explanation right, which is how I've understood it based on the wiki's PPU frame timing article:

With $2000=$10 every BG CHR fetch is A12 high, and NT/AT fetches are A12 low, but since NT/AT only takes 4 dots the M2 filter is not fulfilled and we continue as if A12 remains high while in a repeating NT AT CHR CHR pattern.

At the end of a scanline we get an extra NT NT, then an idle dot that's equivalent to BG CHR, then resumes NT AT CHR CHR... so, no interruption on an even frame becuase that idle dot was A12 high

On an odd frame, the idle dot is skipped and now we have a sequence of NT NT NT AT between the end of pre-render and first-visible. This leaves A12 low for 8 dots, satisfying the filter if 3 M2 falls happen to align inside that 8-dot window.

Is that correct?

Am I also correct in believing that this only affects $2000=$10, because with $2000=$08 the BG CHR A12 matches NT/AT A12 (0) and with A12 not oscillating the avoided?

(Incidentally, does this being an alignment-dependent behaviour also confirm that the filter has to be 3 M2 falls, because with only 2 M2 falls the extra clock would happen regardless of alignment?)

Test source code:

Code: Select all

	scanline_0_08 = 6976
	scanline_1_08 = scanline_0_08
	
	set_test 2,"Scanline 0 IRQ should occur later when $2000=$08"
	test $08, 0, scanline_0_08 - 1
	cmp #$22
	jne test_failed
	
	set_test 3,"Scanline 0 IRQ should occur sooner when $2000=$08"
	test $08, 0, scanline_0_08
	cmp #$21
	jne test_failed
	
	set_test 4,"Scanline 1 IRQ should occur later when $2000=$08"
	test $08, 1, scanline_1_08 + 341 - 1
	cmp #$22
	jne test_failed
	
	set_test 5,"Scanline 1 IRQ should occur sooner when $2000=$08"
	test $08, 1, scanline_1_08 + 341
	cmp #$21
	jne test_failed
	
	set_test 6,"Scanline 239 IRQ should occur later when $2000=$08"
	test $08, 239, scanline_1_08 + 239*341 - 1
	cmp #$22
	jne test_failed
	
	set_test 7,"Scanline 239 IRQ should occur sooner when $2000=$08"
	test $08, 239, scanline_1_08 + 239*341
	cmp #$21
	jne test_failed
	
	
	scanline_0_10 = 6976 - 256
	scanline_1_10 = scanline_0_10 - 21
	
	set_test 8,"Scanline 0 IRQ should occur later when $2000=$10"
	test $10, 0, scanline_0_10 - 1
	cmp #$22
	jne test_failed
	
	set_test 9,"Scanline 0 IRQ should occur sooner when $2000=$10"
	test $10, 0, scanline_0_10
	cmp #$21
	jne test_failed
	
	set_test 10,"Scanline 1 IRQ should occur later when $2000=$10"
	test $10, 1, scanline_1_10 + 341 - 1
	cmp #$22
	jne test_failed
	
	set_test 11,"Scanline 1 IRQ should occur sooner when $2000=$10"
	test $10, 1, scanline_1_10 + 341
	cmp #$21
	jne test_failed
	
	set_test 12,"Scanline 239 IRQ should occur later when $2000=$10"
	test $10, 239, scanline_1_10 + 239*341 - 1
	cmp #$22
	jne test_failed
	
	set_test 13,"Scanline 239 IRQ should occur sooner when $2000=$10"
	test $10, 239, scanline_1_10 + 239*341
	cmp #$21
	jne test_failed
So... shouldn't tests 2-7 work on all alignments, and then, depending on which alignment the tests were tuned against, it should sometimes fail 8,9,12 or 9,11,13?

I'm assuming the extra clock should happen on 2/3 of alignments. If that's what's common, I'd expect to fail the "sooner" tests 9,11,13 when a lack of extra clock makes the IRQ later. If the other way around, I'd expect to fail the "later" tests 8,10,12.

So... my assumption was that the "sooner" test was the one that was supposed to fail, and test 3 made sense to me, before I realized $2000=08 shouldn't be subject to the problem. So that's mystery #1.

However, there's yet another mystery because each test, at least according to the comments, starts with a sync to an even frame specifically to avoid the missing dot! Why would any of these fail due to alignment? Mystery #2.
Trirosmos wrote: Tue Nov 08, 2022 2:49 pmThe weird part is that it seemed to only fail if it happened to land on the right CHR bank. Otherwise, it would always pass. He did try it several times.
I guess that's mystery #3 because I can't think of a reason that CHR banking (or mirroring) should affect the test. PRG should have to be initialized for the test to even work, and all 4 IRQ registers are definitely being written to.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: PowerPak MMC3 jitter fix for loopy's mapper

Post by rainwarrior »

Looking at Mesen which passes on some resets, and not others, what I've found:

In Mesen sync_vbl_even will return at either dot 38 or 39 of an even frame. There's a 50/50 chance of one or the other each reset. In the latter case, it will fail the first test (#2, a "later" test) because the IRQ has happened too soon.

This 1 cycle makes the difference between the IRQ happening after the 2nd NOP or after the INC.

Code: Select all

end_:
	setb irq_flag,$10
	cli
	nop
	nop
	inc irq_flag
	delay 1000
	sei
	nop
	lda irq_flag
	cmp #$11
	beq @no_irq
	rts
So... I don't know how accurate Mesen is to the MMC3 timing... but this pass/fail it's getting isn't even due to an extra A12 clock. This is a 1 cycle CPU difference!

Edit:

The comments of Blargg's PPU sync code do claim that it can only synchronize to a granularity of 1/2 CPU cycles, so the randomness of 1 cycle I think should be expected here, at least according to its comments/documentation.

Comparing Nintendulator, which is the only emulator I've found that consistently passes all these tests, it says sync_vbl_even returns at dot 37 always. No apparent implementation of CPU-PPU alignment randomization, but it also seems to be claiming 1 dot earlier? (I dunno which, if either, should be considered correct, but it at least demonstrates that a "passing" emulator could also be relying on a specific PPU-CPU alignment.)
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: PowerPak MMC3 jitter fix for loopy's mapper

Post by rainwarrior »

So, after analyzing the tests more closely, I don't think this even attempts to tests the $2000=$10 pre-render extra clock.

Assuming these tests are designed to have a 2-CPU-cycle margin of error, accounting for both possible sync_vbl_even alignments. If a test fails some of the time, you're just on the edge of that window. If it fails all the time you're further away.

So, Nintendulator, Mesen, Bucketmouse's test, my PowerPak mapper, these are all showing to be in the vicinity of the window by passing at least sometimes. According to Mesen's timing, all the tests will have the same 2-cycle alignment, so if it passes the first 2 tests it should continue to pass the rest for that same reset.

So, what's the difference? My mapper is "too late". Is A12 getting delayed just a little too much by the CLK20 filter? What about Mesen. It's "too early"? Is it faster than a real MMC3? Are some MMC3 boards "faster" than others? Is this a capacitor on Crystalis' A12, and would that make enough of a difference to be seen here?

The frequency of failure might be somewhat diagnostic? Failing most of the time would indicate an alignment further off than expected. Failing seldom should indicate a close alignment.

All of this is assuming that Blargg's hardware tests were consistently passing. I still don't want to assume that the test always had this problem and it was just never noticed by Blargg... but how do we account for this timing difference?
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: PowerPak MMC3 jitter fix for loopy's mapper

Post by lidnariq »

All MMC3 carts appear to have a capacitor on PPU A12, and it causes very roughly 50ns of delay, as you can see in my oscilloscope capture in this post viewtopic.php?p=115993#p115993

(second picture ("IMG_0255") upper trace)

There's then another roughly 60ns of delay internal to the MMC3 (the difference between the upper trace and lower trace in that same picture)
Trirosmos
Posts: 50
Joined: Mon Aug 01, 2016 4:01 am
Location: Brinstar, Zebes
Contact:

Re: PowerPak MMC3 jitter fix for loopy's mapper

Post by Trirosmos »

rainwarrior wrote: Tue Nov 08, 2022 4:03 pm With $2000=$10 every BG CHR fetch is A12 high, and NT/AT fetches are A12 low, but since NT/AT only takes 4 dots the M2 filter is not fulfilled and we continue as if A12 remains high while in a repeating NT AT CHR CHR pattern.

At the end of a scanline we get an extra NT NT, then an idle dot that's equivalent to BG CHR, then resumes NT AT CHR CHR... so, no interruption on an even frame becuase that idle dot was A12 high

On an odd frame, the idle dot is skipped and now we have a sequence of NT NT NT AT between the end of pre-render and first-visible. This leaves A12 low for 8 dots, satisfying the filter if 3 M2 falls happen to align inside that 8-dot window.

Is that correct?

Am I also correct in believing that this only affects $2000=$10, because with $2000=$08 the BG CHR A12 matches NT/AT A12 (0) and with A12 not oscillating the avoided?
That seems to match my understanding, yeah.
rainwarrior wrote: Tue Nov 08, 2022 4:03 pm (Incidentally, does this being an alignment-dependent behaviour also confirm that the filter has to be 3 M2 falls, because with only 2 M2 falls the extra clock would happen regardless of alignment?)
That confirms that it can't be two M2 edges, but it could be more than three, I suppose.
Sour actually commented on this when the whole investigation started. Seemed like he was using a PPU cycle-based cooldown instead, since following the wiki description of 2 M2 cycles would break things in Wario's Woods.

What does confirm that it's exactly three is the decap and probing the MMC3 directly.
rainwarrior wrote: Tue Nov 08, 2022 4:03 pm Though looking at the source code for the test, I don't think I understand what should have been expected... why #2?

So... shouldn't tests 2-7 work on all alignments, and then, depending on which alignment the tests were tuned against, it should sometimes fail 8,9,12 or 9,11,13?

I'm assuming the extra clock should happen on 2/3 of alignments. If that's what's common, I'd expect to fail the "sooner" tests 9,11,13 when a lack of extra clock makes the IRQ later. If the other way around, I'd expect to fail the "later" tests 8,10,12.

So... my assumption was that the "sooner" test was the one that was supposed to fail, and test 3 made sense to me, before I realized $2000=08 shouldn't be subject to the problem. So that's mystery #1.
Hmm, I guess I'm still confused about what these tests are doing in the first place.

When $2000=$08, the counter should always be clocked around dot 260.
When $2000=$10:
  • The counter will be clocked at dot ~324 on all visible scanlines of even frames
  • The counter will be clocked at dots 5 and 324 of scanline 0 on odd frames, but only on some alignments, Otherwise, it will be just one clock at 324.
What do "Scanline 0 IRQ should occur later when $2000=$08" and "Scanline 0 IRQ should occur sooner when $2000=$08" mean in this context? Sooner than what?
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: PowerPak MMC3 jitter fix for loopy's mapper

Post by rainwarrior »

Trirosmos wrote: Tue Nov 08, 2022 6:31 pmWhat do "Scanline 0 IRQ should occur later when $2000=$08" and "Scanline 0 IRQ should occur sooner when $2000=$08" mean in this context? Sooner than what?
It means the IRQ should have occurred sooner within the frame. The test is synchronized to $2001.7 with 2-CPU-cycle accuracy, so it's relative to that sync.

Doing a little bit of frequency testing:

Over 80 reset tests, my mapper passed 60 of them, and failed 20. I stopped counting after that. It always fails with "should occur sooner". Interestingly, some of the failures manage to pass #3 and fail on a later test instead. I think it gets to #5 on maybe 25% of the failures. I saw #7 at least once, but after I stopped counting. I guess this means that even on the failing alignment it's close enough to be subject to noise?

Mesen fails 3/4 of the time as too late (#2).
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: PowerPak MMC3 jitter fix for loopy's mapper

Post by rainwarrior »

lidnariq wrote: Tue Nov 08, 2022 6:18 pmAll MMC3 carts appear to have a capacitor on PPU A12, and it causes very roughly 50ns of delay, as you can see in my oscilloscope capture... There's then another roughly 60ns of delay internal to the MMC3
Thanks, that definitely gives a good picture.


So, I made two quick experiments to see what I get by adjusting the A12 pre-filter:
loopy_mmc3_fix10a.zip
(25.71 KiB) Downloaded 22 times
loopy_mmc3_fix10b.zip
(25.9 KiB) Downloaded 28 times
10a A12 is too fast 1/4 of the time: (fails #2, #4, #6...)

Code: Select all

    reg a12_pre_filtered;
    reg a12_pre_last_clk20;
    always @(posedge clk20) begin
        if (a12_pre_last_clk20 == chrain[12])
            a12_pre_filtered <=a12_pre_last_clk20;
    end
    always @(negedge clk20) begin
        a12_pre_last_clk20 <= chrain[12];
    end
10b A12 is too slow 1/4 of the time: (fails #3, #5, #7...)

Code: Select all

    reg a12_pre_filtered;
    reg [1:0] a12_pre_delay_line;
    always @(posedge clk20) begin
        if(a12_pre_delay_line == 3) a12_pre_filtered <= 1;
        if(a12_pre_delay_line == 0) a12_pre_filtered <= 0;
    end
    always @(negedge clk20) begin
        a12_pre_delay_line <= {a12_pre_delay_line[0],chrain[12]};
    end
10b especially seems to get to a 2nd or 3rd test more frequently. Testing 10b I got a lot of #7 and once an #11.

For reference, this was the pre-filter used in attempt 9:

Code: Select all

    reg a12_pre_filtered;
    reg [1:0] a12_pre_delay_line;
    always @(posedge clk20) begin
        a12_pre_delay_line <= {a12_pre_delay_line[0],chrain[12]};
        if(a12_pre_delay_line == 3) a12_pre_filtered <= 1;
        if(a12_pre_delay_line == 0) a12_pre_filtered <= 0;
    end
All that changed between 9 and 10b was that I made the delay line shift on clk20 fall which I thought might avoid a timing ambiguity between the line shift and the filtered assignment, and it did make a tangible difference on the test.

So... the difference in games between 9, 10a, and 10b for games is invisible to me, though I haven't had time to do much testing with either of them yet. The only thing that I can tell the difference with is Blargg's scanline test.

I guess it suggests that the exact A12 delay that the test is tuned for is somewhere in between these two? I dunno if there's a good way to produce an in-between in verilog. The 10b delay definitely appears to be closer, at least. However, it feels like this is getting to a point a little too fine for the hardware involved... the report of Bucketmouse's test seems to suggest that there might be enough variation in real world MMC3 boards that the test should fail for at least some?
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: PowerPak MMC3 jitter fix for loopy's mapper

Post by rainwarrior »

So I was playing with N-K's MMC3 IRQ test ROM and it seemed like it might be a good demonstration of the alignments vs $2000=$10. It had some kind of interesting behaviour for me.

mmc3irqtest_alignments.mp4 (9MB)

So, this is mapper version 10b, captured from my PowerPak + NES and slowed to 20hz. I basically just hit reset and then pressed B a bunch of times. There seemed to be at least 3 distinct patterns. I kept these 4 segments which were distinct from each other.
  • alternating pattern 1
  • stable pattern
  • jittery pattern: seems to not get the extra clock once every 12-14 frames?
  • alternating pattern 2
The alternating patterns are probably the same, just with a different timing as a byproduct of when I pressed B to switch. The jittery pattern I'm really curious about... I don't have a good idea for why it would do that... I think I was seeing the same occasionally in Wario's Woods. Another thing I want to test on a real MMC3 at some point so see if it's just my implementation or not. I wonder how much WW goes for these days...
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: PowerPak MMC3 jitter fix for loopy's mapper

Post by rainwarrior »

rainwarrior wrote: Tue Nov 08, 2022 9:35 pmjittery pattern: seems to not get the extra clock once every 12-14 frames?
After thinking about it, I would bet this does not happen on the real thing. (Am currently acquiring a Wario No Mori cart to check.)

I believe this sporadic (but almost regular) flicker is due to having to replicate the analog A12 filter with the PowerPak's 20MHz clock. It's probably close enough to a multiple of M2 that its timing alignment slips against it in a period of ~13 frames.

So... my guess is the real Wario will be stable on 2 of 4 alignments, and alternating on the other 2.

For the PowerPak, I guess I'm getting stable on 1, alternating on 2, and 1 more that's not quite stable because of the timing slip. :S

Not sure if there's a better alternative to using clk20 to simulate the filter, but this might be the best I can do if not.

Edit: The Spartan 2's DLL says it can do 2x or 4x clock multipler... but seems to require at least a 25 MHz clock. :(

.

Finally, someone brought up this other known MMC3 bug that had affected N-K's test ROM:
Blargg's mmc3_test_2 readme.txt wrote:- I uncovered some pathological behavior that isn't covered by the test
ROMs. If $C001 is written, the counter clocked, then $C001 written
again, on the next counter clock the counter will be ORed with $80
(revision B)/frozen (revision A) and neither decremented nor reloaded.
If $C001 is written again at this point, on the next counter clock it
will be reloaded normally. I put a check in my emulator and none of the
several games I tested ever caused this situation to occur, so it's
probably not a good idea to implement this.
Was any theory about this derived from the decap study?
Last edited by rainwarrior on Sun Nov 13, 2022 11:40 pm, edited 1 time in total.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: PowerPak MMC3 jitter fix for loopy's mapper

Post by lidnariq »

I did spend a little time looking into that but saw no reason why the various bits of the counter should behave differently from each other, so it's got to be analog mess.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: PowerPak MMC3 jitter fix for loopy's mapper

Post by rainwarrior »

lidnariq wrote: Sun Nov 13, 2022 8:50 pmI did spend a little time looking into that but saw no reason why the various bits of the counter should behave differently from each other, so it's got to be analog mess.
Thanks. I was curious why it didn't seem to be a feature of Trirosmos' proposed verilog in any obvious way.

It could probably be duplicated in verlog in some logical way, but until I make myself an MMC3 test board I wouldn't be confident trying to get an accurate behaviour out of it... at least it seems like it's not relevant to any existing games. Might be useful for developers though to know to avoid it.

.

NES Wario's Woods carts are expensive, but I found a Famicom Wario no Moro for fairly cheap. Did some testing just restarting a few hundred times and going to the first board to check for the jittery corner.

1. From power-on, there seems to be a 50/50 chance of alternating frames jitter.
2. From reset, it seems like there's an affinity determined at power-on. Some runs either stable or alternating-jitter dominates (maybe 80%). Some runs they seem to be 50/50.
3. As expected there is no 1 in ~13 jitter like is seen in my PowerPak mapper.

So I guess those match the theories I had, though #2 seems to indicate something about Famicom reset alignment behaviour that I don't see on the NES. I don't really have much to go on besides blargg's notes. I know the PPU doesn't reset on the Famicom, but don't know a way that would affect the alignment probability. If anything I'd expect the NES to have tendencies due to both resetting at the same time, and the Famicom to be free combinations.

.

Anyway, that was the last thing I wanted to check. Either mapper 10a or 10b seem very viable, but I'm not sure which one to choose. A summary of the nitpicks:
  • They both have the "1/13 jitter" behaviour on 1/4 alignments for Wario's Woods, I'm assuming due to the 20MHz clock. (This alignment should be stable instead.)
  • blargg's 4-scanline_timing test: 10a fails too early in 1/4 aligments, 10b fails too late in 1/4 alignments (but gets further). Still not sure which is "better", or if there exists some goldilocks delay that always passes. A secondhand report from Bucketmouse suggested that too-early might be the more "correct" of the two?
  • The $C001-on-every-line bug is not duplicated. Has to be avoided by games anyway, but maybe would be useful to have as a caution for developers.
  • 10b is slightly more delayed, increasing the strength of the A12 filter. Both seem stable to me, but knowing that 10b is slightly more tolerant of in this way makes me think I should favour it.
So, unless there's a way to implement/investigate a finer range of A12 filter delays, I guess I'd side with 10b. The Spartan 2 has DLLs which apparently could be used as clock multiplier, except their minimum input rate is 25MHz. Maybe there's some other feature I missed, as my experience level is low.

The 25% chance of sparse jitter doesn't seem like a big problem, since the $2000=$10 is already inconsistent on regular hardware (was Wario's Woods the only game to try it?)... it's just inconsistent in a slightly different way. :P I'd be nice to get 50/50 stable/alternating, but stable/sparse/alt/alt seems closer to the truth than all stable.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: PowerPak MMC3 jitter fix for loopy's mapper

Post by rainwarrior »

Okay, this is probably my final revision of the MMC3 mapper. Just put MAP04.MAP in your POWERPAK folder.
loopy_mmc3_fix11.zip
(29.61 KiB) Downloaded 15 times
This is the same FPGA program as 10b but I've written a new loader stub for it.

The stub provides a simple loading progress bar, allows iNES 2 CHR-RAM size, as well as iNES 2 PRG-RAM size. It also wipes most of RAM to $FF before boot (leaving 15 bytes at the top of the stack for the wiping program).

MMC3 doesn't have PRG-RAM banking, but this stub could be used for a mapper that does. (I made it so that it could be a drop-in replacement for most of the existing mapper stubs.)

This allows Haunted Halloween '86 to run, which requires MMC3 + 32k CHR-RAM. I don't know any other current use cases, except the holy mapperel test ROMs. (Thanks, tepples!)
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: PowerPak MMC3 jitter fix for loopy's mapper

Post by rainwarrior »

Okay one more. Maybe this is the last last one. ;)
loopy_mmc3_fix12.zip
(30.22 KiB) Downloaded 19 times
I thought I might as well test the PRG-RAM enable capability, since we had a known example of Low G Man that needs open bus to run correctly. (It now works without having to patch the ROM, just have to use an iNES 2 header with 0 PRG-RAM. If you wanna test: put in HNRY, wait a few seconds, without this the boss music will crash the game or go weird.)

While I was in there I spotted some weird code in powerpak.v with a comment by Loopy:

Code: Select all

    //needed for Dirty Harry (MMC3) and Paperboy (CNROM)
    //D7,D5 low during 4016/7 read fixes controller input problems
    wire readpad=(prgain[15:1]=='b0100_0000_0001_011) & nesprg_we & ~m2;
    wire [7:0] openbus={!readpad, 1'b1, !readpad, 5'b11111};
    
    //IOBUF b06[7:0](.I(1'b0),.O(nesprgdin),.T(nesprgdout | {8{~nesprg_oe}}),.IO(NES_PRG_D));
    IOBUF b06[7:0](.I(1'b0),.O(nesprgdin),.T(openbus & (nesprgdout | {8{~nesprg_oe}})),.IO(NES_PRG_D));
The commented lines were reversed in the version of powerpak.v. So... testing the previous version I could not start Dirty Harry. Just stuck on the title screen. With this line swapped in, it works. I dunno if it has any other effects... I dunno if this should apply to all games or is just something weird to do with MMC3 and/or Dirty Harry? Anyway, so far so good after turning it on.

I've come this far... maybe do I need to think about MMC3 submappers...? I guess this is fully compatible, except for the acclaim one... maybe I should take a look at what emulators have to do to get Mickey's Safari in Letterland right.

Edit: sounds like it's: clock on an unfiltered falling edge of A12, then ignore then next 7 edges, also $C001 resets the ignore. I'll try this out soon... (Basically it's going off the 8 sprite fetches per line, and is trying to reduce that to 1 clock?)
Post Reply