PowerPak MMC3 fixes: accurate IRQ, MC-ACC submapper, iNES 2 CHR-RAM
Moderator: Moderators
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: PowerPak MMC3 jitter fix for loopy's mapper
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.)
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.)
Re: PowerPak MMC3 jitter fix for loopy's mapper
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.
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.
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: PowerPak MMC3 jitter fix for loopy's mapper
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
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.
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.
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: PowerPak MMC3 jitter fix for loopy's mapper
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.
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.)
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
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.)
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: PowerPak MMC3 jitter fix for loopy's mapper
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?
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?
Re: PowerPak MMC3 jitter fix for loopy's mapper
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)
(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)
Re: PowerPak MMC3 jitter fix for loopy's mapper
That seems to match my understanding, yeah.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 confirms that it can't be two M2 edges, but it could be more than three, I suppose.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?)
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.
Hmm, I guess I'm still confused about what these tests are doing in the first place.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.
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.
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: PowerPak MMC3 jitter fix for loopy's mapper
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).
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: PowerPak MMC3 jitter fix for loopy's mapper
Thanks, that definitely gives a good picture.
So, I made two quick experiments to see what I get by adjusting the A12 pre-filter: 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
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
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
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?
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: PowerPak MMC3 jitter fix for loopy's mapper
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.
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
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: PowerPak MMC3 jitter fix for loopy's mapper
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.)rainwarrior wrote: ↑Tue Nov 08, 2022 9:35 pmjittery pattern: seems to not get the extra clock once every 12-14 frames?
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:
Was any theory about this derived from the decap study?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.
Last edited by rainwarrior on Sun Nov 13, 2022 11:40 pm, edited 1 time in total.
Re: PowerPak MMC3 jitter fix for loopy's mapper
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.
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: PowerPak MMC3 jitter fix for loopy's mapper
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.
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. I'd be nice to get 50/50 stable/alternating, but stable/sparse/alt/alt seems closer to the truth than all stable.
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: PowerPak MMC3 jitter fix for loopy's mapper
Okay, this is probably my final revision of the MMC3 mapper. Just put MAP04.MAP in your POWERPAK folder.
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!)
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!)
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: PowerPak MMC3 jitter fix for loopy's mapper
Okay one more. Maybe this is the last last one.
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:
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?)
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));
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?)