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

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: Wed Nov 02, 2022 11:08 am So, it isn't quite the filter you suggested in your first post on this thread. I did try it like that, but never found a successful result with it.
The implementation I had suggested at first is a fairly literal interpretation of the RE'd MMC3C schematic that Furrtek did by tracing decapped images of the chip (the IRQ stuff is in the last page).
So, it should be pretty much how the A12 filter is supposed to work.

But, yeah, that doesn't account for external factors such as the FPGA having different logic levels or extra noise that isn't present on a standalone MMC3 board. Using a faster clock for the pre-filter should get rid of really fast transients while keeping behavior such as the pre-render scanline causing jitter in Wario's Woods in some CPU-PPU alignments.
rainwarrior wrote: Wed Nov 02, 2022 11:08 am The main thing the filter should be affecting is the specific onset timing. Unfortunately I don't know if anyone has made a test ROM that can measure MMC3 IRQ timing directly (Blargg's tests seem agnostic to a little bit of delay), but the real MMC3 carts I have on hand vs. this implementation look visually identical to me in terms of horizontal positioning.
I seem to remember that lidnariq had measured some kind of delay between when the MMC3 registers an IRQ internally and when it actually asserts the IRQ line... or something to that end. Not sure how relevant that'd be here.
rainwarrior wrote: Wed Nov 02, 2022 1:42 pm Attempt #7. I've found zero issues testing with many games.
:D
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: PowerPak MMC3 jitter fix for loopy's mapper

Post by lidnariq »

Trirosmos wrote: Thu Nov 03, 2022 4:37 pm I seem to remember that lidnariq had measured some kind of delay between when the MMC3 registers an IRQ internally and when it actually asserts the IRQ line... or something to that end. Not sure how relevant that'd be here.
viewtopic.php?p=115993#p115993
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 »

Alright, upon studying the schematic further, I realized my filter logic wasn't quite right, lol.
It generated positive edges at the same points as the real deal, I think, but turns out a lot of the IRQ logic is triggered by the negative edges of the filtered A12 instead.

This is almost verbatim what is in the schematic:

Code: Select all

reg [2:0] a12_delay_line;
wire a12 = !a12_delay_line[2];
wire not_a12 = a12_delay_line[2];

always @(posedge m2, posedge a12_pre_filtered) begin
    if(a12_pre_filtered) a12_delay_line <= 0; 
    else a12_delay_line <= {a12_delay_line[1:0],1'b1};
end
As for the rest of the IRQ logic... well, it's a bit convoluted, but I tried to follow the schematic as closely as possible.
I might have committed some dumb mistake, haven't actually tried to synthesize this, but I'd be pretty interested to know how well it does.

Code: Select all

wire write_c001 = nesprg_we & m2_n & {prgain[15:13],prgain[0]}==4'b1101;
wire write_e000 = nesprg_we & m2_n & {prgain[15:13],prgain[0]}==4'b1110;

reg [7:0] count;
reg reload_req;
reg delayed_reload_req;
wire count_zero = count == 0;
wire reload = delayed_reload_req | count_zero;

always @(posedge not_a12) delayed_reload_req <= reload_req;

always @(posedge write_c001, posedge delayed_reload_req) begin
    if(delayed_reload_req) reload_req <= 0; 
    else reload_req <= 1;
end

always @(posedge count_zero, posedge write_e000) begin
    if(write_e000) irq <= 0;
    else irq <= irqen;
end

always @(posedge reload, posedge a12) begin
    if(reload) count <= irqlatch;
    else count <= count - 1;
end
Attachments
powerpak_mmc3_furrtek_schematic.zip
(5.8 KiB) Downloaded 23 times
Last edited by Trirosmos on Fri Nov 04, 2022 3:55 am, edited 1 time in total.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: PowerPak MMC3 jitter fix for loopy's mapper

Post by rainwarrior »

If MAP04.MAP wasn't rebuilt maybe it should be removed from that zip, just so nobody's confused about the contents if they download it.

Anyway, I did try building it but the IRQ never seems to fire at all. :S Not sure what the problem was.

However, this led me to Attempt #8, which now passes more of blargg's tests, but not quite all.

Download:
loopy_mmc3_fix8.zip
(26 KiB) Downloaded 18 times
.

So, the change in the filter seemed to make a difference for 4-scanline, though I'm not sure why. I did find that the results of 4-scanline change from reset to reset, though, and it will occasionally report a failed #3. I'm wondering if it's sensitive to PPU alignment in a weird way. It passes now, most of the time, but not every reset.

Otherwise the way you had set a delayed clear for the reload flag helped me to understand an appropriate timing for clearing it. Incorporating that idea, I tried to rewrite the IRQ logic, starting from what you'd provided and adding my logical understanding of MMC3 until it started to work.

Code: Select all

    wire write_c001 = nesprg_we & m2_n & {prgain[15:13],prgain[0]}==4'b1101;
    wire write_e000 = nesprg_we & m2_n & {prgain[15:13],prgain[0]}==4'b1110;

    reg [7:0] count;
    reg countdown_zero;
    reg reload;
    reg clear_reload;
    reg clear_reload_delay;

    // clear reload request on falling edge of a12
    always @(posedge not_a12) clear_reload <= clear_reload_delay;

    always @(posedge write_c001, posedge clear_reload) begin
        if(clear_reload) reload <= 0; 
        else reload <= 1;
    end

    always @(posedge write_e000, posedge a12) begin
        if(write_e000)
            irq <= 0;
        else begin
            if(reload) begin
                irq <= irqen & (irqlatch == 0);
                count <= irqlatch;
                clear_reload_delay <= 1;
                countdown_zero <= 0;
            end else if (count == 0) begin
                irq <= irqen & (irqlatch == 0) & !countdown_zero;
                count <= irqlatch;
                clear_reload_delay <= 0;
            end else if (count == 1) begin
                irq <= irqen;
                count <= 0;
                countdown_zero <= 1;
                clear_reload_delay <= 0;
            end else begin
                count <= count - 1;
                clear_reload_delay <= 0;
            end
        end
    end
The Blargg test still not passing is:
  • 1-clocking: #4 Writing to $C000 shouldn't cause reload
I have no idea why it fails this, though. I can't think of a logical reason this should have that problem.

This is the code of that test (my annotations starting with >):

Code: Select all

	set_test 4,"Writing to $C000 shouldn't cause reload"
	ldx #2
	jsr begin_counter_test ; > clock twice, C000=2, write C001, write E000, write E001
	jsr clock_counter       ; counter = 2
	lda #100
	jsr set_reload ; > C000=100
	ldx #8
	jsr clock_counter_x     ; should reach 0 before reloading with 100
	jsr should_be_set       ; and thus IRQ flag should be set by now
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: PowerPak MMC3 jitter fix for loopy's mapper

Post by rainwarrior »

Attempt #9 now passes all of Blargg's tests.

Download:
loopy_mmc3_fix9.zip
(26.25 KiB) Downloaded 26 times
.

The test failure was caused because I forgot to ensure that irq can only be raised, and never lowered except by $E000. Just needed to add "irq |" to all the places it was being potentially set:

Code: Select all

    always @(posedge write_e000, posedge a12) begin
        if(write_e000)
            irq <= 0;
        else begin
            if(reload) begin
                irq <= irq | (irqen & (irqlatch == 0));
                count <= irqlatch;
                clear_reload_delay <= 1;
                countdown_zero <= 0;
            end else if (count == 0) begin
                irq <= irq | (irqen & (irqlatch == 0) & !countdown_zero);
                count <= irqlatch;
                clear_reload_delay <= 0;
            end else if (count == 1) begin
                irq <= irq | irqen;
                count <= 0;
                countdown_zero <= 1;
                clear_reload_delay <= 0;
            end else begin
                count <= count - 1;
                clear_reload_delay <= 0;
            end
        end
    end
Anyway... I guess I have nothing left to add to this one now.

If I reset many times, I can sometimes get this failure (maybe 1 in 10 resets):
  • 4-scanline_timing: #3 Scanline 0 IRQ should occur sooner when $2000=$08
However, I'm not certain if this is the mapper's fault, or if this test always had some PPU-alignment edge case or something. :S Or could even be some PowerPak reset timing issue? I'm noticing that Mesen usually fails 4-scanline_timing at #2 but not all resets!
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: Thu Nov 03, 2022 11:58 pm If MAP04.MAP wasn't rebuilt maybe it should be removed from that zip, just so nobody's confused about the contents if they download it.
Done!
rainwarrior wrote: Thu Nov 03, 2022 11:58 pm
Anyway, I did try building it but the IRQ never seems to fire at all. :S Not sure what the problem was.

Ah, that's unfortunate :/
Wish I had a PowerPak so I could debug it... although I suppose this bit of the logic should be cartridge-agnostic, so I guess I could try it on my EverDrive.
rainwarrior wrote: Thu Nov 03, 2022 11:58 pm
So, the change in the filter seemed to make a difference for 4-scanline, though I'm not sure why. I did find that the results of 4-scanline change from reset to reset, though, and it will occasionally report a failed #3. I'm wondering if it's sensitive to PPU alignment in a weird way. It passes now, most of the time, but not every reset.
Indeed. We had looong discussion sessions about this on Discord, but the gist of it is:

The scanline counter partially works when the BG uses the right pattern table ($1000) and the sprites use the left pattern table ($0000), but the missing dot on the 2C02 causes the very first scanline to sometimes count twice.

That is only possible on some alignments. You could check Wario's Woods out. A " correct " implementation should have the split at the bottom of the screen jitter but only on some boots.
rainwarrior wrote: Fri Nov 04, 2022 12:21 am Attempt #9 now passes all of Blargg's tests.
Yay! :D
The IRQ logic really is kinda weird... I'll have to look into this in more detail later, now I'm really curious why that thing I wrote didn't work xD
But, hey, if it works and passes the tests, I guess we're golden right?
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 »

Trirosmos wrote: Fri Nov 04, 2022 4:05 am The IRQ logic really is kinda weird... I'll have to look into this in more detail later, now I'm really curious why that thing I wrote didn't work xD
Oh, duh! I had misunderstood the counter's /reload signal as being asynchronous, but that wouldn't make much sense as it transitioning to 0 would immediately trigger a reload, which could cause problems and be kinda unstable.

So, it should actually be:

Code: Select all

always @(posedge a12) begin
    if(reload) count <= irqlatch;
    else count <= count - 1;
end
Just removing reload from the sensitivity list.
User avatar
rainwarrior
Posts: 8732
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: Fri Nov 04, 2022 4:05 am
rainwarrior wrote: Thu Nov 03, 2022 11:58 pmSo, the change in the filter seemed to make a difference for 4-scanline, though I'm not sure why. I did find that the results of 4-scanline change from reset to reset, though, and it will occasionally report a failed #3. I'm wondering if it's sensitive to PPU alignment in a weird way. It passes now, most of the time, but not every reset.
Indeed. We had looong discussion sessions about this on Discord, but the gist of it is:

The scanline counter partially works when the BG uses the right pattern table ($1000) and the sprites use the left pattern table ($0000), but the missing dot on the 2C02 causes the very first scanline to sometimes count twice.

That is only possible on some alignments. You could check Wario's Woods out. A " correct " implementation should have the split at the bottom of the screen jitter but only on some boots.
So, what I'm seeing in attempt #9 is that in Wario's Woods, the bottom scanline of the green grass will turn black about ~48 pixels before the end of the line, but only on some resets. That's the behaviour we're looking for, right? I don't have a real Wario's Woods cart to compare.

My main question is whether 4-scanline_timing should fail on some resets, as it is doing. I don't have an MMC3 socketed cart to compare... but even if I did I'm not sure whether PowerPak's reset sequence would be sufficiently identical for the test to be valid.

.
Trirosmos wrote: Fri Nov 04, 2022 4:52 amSo, it should actually be:

Code: Select all

always @(posedge a12) begin
    if(reload) count <= irqlatch;
    else count <= count - 1;
end
So, trying your version above + only this change, it now does get an IRQ, but I quickly found other issues:
  • SMB3 looks fine.
  • StarTropics is mistimed, with the status bar beginning half a line too late and also displaying a blinking dot about 16px form the right, 8px below the start of the status bar.
  • Crystalis has bad seams and on some vertical positions in the field gets the second IRQ too high starting the status bar mid-screen.
  • 1-clocking fails at #2: Counter/IRQ/A12 clocking isn't working at all
  • 2-details fails at #2: Counter isn't working when reloaded with 255
  • 3-A12_clocking fails at #3: Souldn't be clocked when A12 changes to 0
  • 4-scanline-timing fails #14: IRQ never occurred (my modified version indicates it failed during #3)
  • 6-MMC3_alt fails #2: IRQ shouldn't be set when reloading to 0 due to counter naturally reaching 0 previously
So... I would need more debugging to work, but with the back and forth for testing it'd probably take a long time to figure out and understand the problem. :S

When I started looking at your code, the delayed reload did look fishy to me, and I tried a few small changes to it at first (but not this one of removing posedge reload), but it didn't start working for me until it was closer to what you see in the final version. (Can't remember what things I tried specifically, though.)
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: Fri Nov 04, 2022 12:47 pm So, what I'm seeing in attempt #9 is that in Wario's Woods, the bottom scanline of the green grass will turn black about ~48 pixels before the end of the line, but only on some resets. That's the behaviour we're looking for, right? I don't have a real Wario's Woods cart to compare.
I believe that should be correct. On some alignments, the IRQ triggers a scanline earlier on even frames, but presumably the IRQ there takes a little while to turn rendering off.
rainwarrior wrote: Fri Nov 04, 2022 12:47 pm My main question is whether 4-scanline_timing should fail on some resets, as it is doing. I don't have an MMC3 socketed cart to compare... but even if I did I'm not sure whether PowerPak's reset sequence would be sufficiently identical for the test to be valid.
Is how these tests work documented somewhere? I'm not sure what that failure would mean.
I think this effect should only be dependent on the CPU-PPU alignment, so the PowerPak messing with the power-up state shouldn't matter.
rainwarrior wrote: Fri Nov 04, 2022 12:47 pm When I started looking at your code, the delayed reload did look fishy to me, and I tried a few small changes to it at first (but not this one of removing posedge reload), but it didn't start working for me until it was closer to what you see in the final version. (Can't remember what things I tried specifically, though.)
Hmmm, what I can say is that writing to $C001 sets a latch, but the value from it isn't what actually reloads the counter.
Instead, that signal is delayed until the next falling edge of the filtered A12. And I'm fairly certain the reload signal on the counter cells is synchronous, so it'd then take until the next rising edge of A12 for the reload to happen.
User avatar
rainwarrior
Posts: 8732
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: Fri Nov 04, 2022 6:46 pm
rainwarrior wrote: Fri Nov 04, 2022 12:47 pm So, what I'm seeing in attempt #9 is that in Wario's Woods, the bottom scanline of the green grass will turn black about ~48 pixels before the end of the line, but only on some resets. That's the behaviour we're looking for, right? I don't have a real Wario's Woods cart to compare.
I believe that should be correct. On some alignments, the IRQ triggers a scanline earlier on even frames, but presumably the IRQ there takes a little while to turn rendering off.
I often look to speedrunners for hardware recordings, though these days I can't tell if someone is using a flash cart either... I did find a run that looks exactly what I was seeing in the #9 mapper: speedrun
Trirosmos wrote: Fri Nov 04, 2022 6:46 pmIs how these tests work documented somewhere? I'm not sure what that failure would mean.
Blargg provided a readme: readme.txt

Otherwise they are open source, which Blargg suggested checking if the error message isn't enough: source

It looks like the scanline tests sync to an even vblank with CPU cycle precision, then they run with the counter starting with values that should either have fired or not fired an IRQ by the end of the test.

So... I think if an extra clock can apply to this case it should fail this test? Is this an "even frame" effect? The Wiki doesn't mention PPU alignment it just says with 8x8 sprites and BG $1000 / $0000 this happens. Should it say that it only happens with certain PPU-CPU alignments?

However, I could find no mention at all of this in the readme for the tests or anywhere else.
Trirosmos wrote: Fri Nov 04, 2022 6:46 pmHmmm, what I can say is that writing to $C001 sets a latch, but the value from it isn't what actually reloads the counter.
Not sure which implementation you're referring to? I don't think any of the proposed versions were making use of the data value written for $C001.
Trirosmos wrote: Fri Nov 04, 2022 6:46 pmInstead, that signal is delayed until the next falling edge of the filtered A12. And I'm fairly certain the reload signal on the counter cells is synchronous, so it'd then take until the next rising edge of A12 for the reload to happen.
Yeah, the reload has to take effect on the first rising A12 for any of these tests to work. I guess that explains why there was a 1-line "seam" in Crystalis when testing with your version, if the reload was delayed by a scanline it should produce exactly 1 line of gap there. I'd guess that SMB3 which I said was "fine" was 1 line late too.

My assumption was that $C001 write sets the reload latch, rising A12 clocks the counter and does a reload if requested, and then falling A12 releases the reload latch after the clock is finished.

At least, that was something I was struggling to implement before you showed me that delayed reload idea. I couldn't figure out how to get C001 to set the reload flag asynchronously, but then clear the reload flag inside the procedural counter block triggered by rising A12. Instead having the clear delayed until falling A12 gave a perfect timing to do so that doesn't interfere with the counter procedure.
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: Fri Nov 04, 2022 7:15 pm Otherwise they are open source, which Blargg suggested checking if the error message isn't enough: source
Ah, neat! I'll take a look at these.
rainwarrior wrote: Fri Nov 04, 2022 7:15 pm It looks like the scanline tests sync to an even vblank with CPU cycle precision, then they run with the counter starting with values that should either have fired or not fired an IRQ by the end of the test.

So... I think if an extra clock can apply to this case it should fail this test? Is this an "even frame" effect? However, I could find no mention at all of this in the readme or anywhere else.
That... sounds sensible. I doubt that the mechanism that makes this happen was known when these ROMs were written. The MMC3 was only decapped in 2020, so these are all fairly recent discoveries.

On most scanlines, cycle 0 is one half of a pattern fetch and the address bus points to a background pattern location, so if background patterns are at $1000 this resets the A12 filter and prevents the counter from being decremented until after sprites are fetched (the counter should only be decremented on cycle 325).
But, yeah, on some alignments there's enough time for there to be three M2 falling edges between when the dummy nametable fetches happen on the pre-render line (cycles 337-340) and when the first background pattern fetch of scanline 0 happens (cycle 5). Since the half pattern fetch on cycle 0 is skipped for scanline 0 on even frames, this will cause the counter to be decremented on cycle 5 instead and then it's double decremented on dot 325.
rainwarrior wrote: Fri Nov 04, 2022 7:15 pm
Trirosmos wrote: Fri Nov 04, 2022 6:46 pmHmmm, what I can say is that writing to $C001 sets a latch, but the value from it isn't what actually reloads the counter.
Not sure which implementation you're referring to? I don't think any of the proposed versions were making use of the data value written for $C001.
Yeah, I'm not talking about the value being written by the CPU but rather the value coming out of the reload latch.

Referring back to the schematic, writing to $C001 sets the N51/N52 latch, but what goes to the counter reload signal is the value from flip flop F48, which is the output from the latch delayed by one A12 falling edge.
rainwarrior wrote: Fri Nov 04, 2022 7:15 pm Yeah, the reload has to take effect on the first rising A12 for any of these tests to work. I guess that explains why there was a 1-line "seam" in Crystalis when testing with your version, if the reload was delayed by a scanline it should produce exactly 1 line of gap there. I'd guess that SMB3 which I said was "fine" was 1 line late too.
Hmmm, I suppose it'd depend on where the $C001 write falls. If it happens while A12 is low, then the next rising edge shouldn't reload the counter.
User avatar
rainwarrior
Posts: 8732
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: Fri Nov 04, 2022 7:55 pmHmmm, I suppose it'd depend on where the $C001 write falls. If it happens while A12 is low, then the next rising edge shouldn't reload the counter.
In Blargg's tests, the counter is clocked by using $2006 with rendering off to raise and lower PPU A12. The default state during these tests is off unless specifically inside the clock_counter routine performing a raise and lower pair.

I suspect in all of Blargg's tests $C001 is written (jsr clear_counter) while A12 is low.

So... I feel like reload has to apply at the very next A12 rise for these tests to work at all. It can't be delayed waiting for a fall then rise?

I don't think Blargg's tests verify what would happen if $C001 is written while A12 is high. I suspect some of the tested games might do this, at least it seems easy for it to happen during an IRQ handler response. My guess would be either that it should apply on the next A12 rise, or it should be cancelled by the A12 fall that happens first.

My implementation was written with the assumption that it would not be cancelled, but I have no known specific test for it. Since I don't have a socketed MMC3 cart to test, I could maybe write a hotswap test to verify... though it might be faster just to check for $C001 writes in the tested games. Finding a suitable $C001 write timing in one of those should be enough.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: PowerPak MMC3 jitter fix for loopy's mapper

Post by rainwarrior »

Interestingly, I had to look at several games before I found a suitable one, but right here in StarTropics it appears to rely on $C001 not getting cancelled if A12 is high. If I understand correctly, A12 should be high from x=~260-324? Here it is at 299.
startropics_c001_a12_high.png
Most games actually seem to use $C001 only during vblank, and otherwise just use the countdown to reload new values instead. Crystalis did do mid-screen $C001 but always with A12 low (usually around x=1 or so).
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: PowerPak MMC3 jitter fix for loopy's mapper

Post by rainwarrior »

Anyway, if anyone with a socketed MMC3 board to test with sees this...

Could you try 4-scanline_timing.nes from mmc3_test_2.zip (or github mirror), and try about 20 resets to see if it fails sometimes?

That's really the one open question I have at the moment. In theory it sounds like it should, but it would be nice to have it verified.
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 »

Hmm, seems like this test ROM doesn't properly initialize MMC3 CHR banks? It displays either a bunch of garbage or a solid white screen most of the time, if mapper state is randomized in Mesen.

Anywho, Bucketmouse tried it on his MMC3A board and, on boots where the right CHR banks happened to be loaded, it behaved as expected: passing the test sometimes, but not always.

However, seemed like on boots where random CHR was displayed, it always passed the test? That doesn't make sense to me at all.
Post Reply