CHR RAM bank switching in mapper 28 (Action 53)

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
tepples
Posts: 21841
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

CHR RAM bank switching in mapper 28 (Action 53)

Post by tepples » Mon Feb 27, 2017 4:54 pm

For $#!+s and giggles, I added CNROM support to the Action 53 menu in case we get more CNROM entries next year. The logic I used was that if the mapping mode specifies $00 as the initial value of $5000, it'll decode two CHR banks instead of one. (That'll be improved if there are 32K/32K entries.) But after half an hour of banging my head against it, I'm getting the sinking feeling that FCEUX 2.2.3's Action 53 mapper lacks support for CHR bank control.

Expected behavior: Writing the value $00 to $5000 should cause the next write to $8000-$FFFF to change which 8 KiB bank of CHR RAM is visible in PPU $0000-$1FFF.
Actual behavior: Not in FCEUX 2.2.3.

I made an Action 53 compilation consisting only of calima's Sinking Feeling and opened it in FCEUX for Windows. In Help > Message Log, I saw "Total VRAM size: 32768", which means the recognized the NES 2.0 header, and the program should be able to change the CHR RAM bank. But when I closed the PPU Viewer, stepped past the mapper writes, and reopened the PPU Viewer, nothing changed. I tried the same ROM on my PowerPak using the 32K version of MAP1C.MAP, and it worked fine.

I couldn't immediately find the deficiency in the source code of FCEUX's Action 53 mapper. Until I get an MCVE made and submitted to the emulator's issue tracker on SourceForge, here's Sinking Feeling. What does your emulator of choice do with it? (Disregard that soft reset doesn't work; that's a different bug.)
Attachments
sinking-028.zip
(27.58 KiB) Downloaded 325 times

tepples
Posts: 21841
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: CHR RAM bank switching in mapper 28 (Action 53)

Post by tepples » Mon Feb 27, 2017 5:47 pm

As promised, a minimal, complete, and verifiable example so that I can link it from my bug report. The brown square blinks on my PowerPak but not on FCEUX.


EDIT: And the bug report.
Attachments
a53bigchrram-0.01.zip
(10.68 KiB) Downloaded 318 times

lidnariq
Posts: 9025
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: CHR RAM bank switching in mapper 28 (Action 53)

Post by lidnariq » Mon Feb 27, 2017 6:01 pm

tepples wrote:I couldn't immediately find the deficiency in the source code of FCEUX's Action 53 mapper.
Found it:

Code: Select all

	case 0x00:
		chr = value & 3;
		Mirror(value);
---> Notice missing Sync or setchr8 call <---
		break;
	case 0x01:
		prg = value & 15;
		Mirror(value);
		Sync();
		break;
	case 0x80:
		mode = value & 63;
		SyncMirror();
		Sync();
		break;
	case 0x81:
		outer = value & 63;
		Sync();
		break;
Depending on things, it might be better design to have the only call to setchr8 in WritePRG rather than via Sync

tepples
Posts: 21841
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: CHR RAM bank switching in mapper 28 (Action 53)

Post by tepples » Mon Feb 27, 2017 7:53 pm

...and fixed already by Zero Mouse.

calima
Posts: 1056
Joined: Tue Oct 06, 2015 10:16 am

Re: CHR RAM bank switching in mapper 28 (Action 53)

Post by calima » Tue Feb 28, 2017 2:37 am

My next game would be 32k/32k, FWIW.

tepples
Posts: 21841
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: CHR RAM bank switching in mapper 28 (Action 53)

Post by tepples » Tue Feb 28, 2017 11:17 am

The actual misbehavior fixed in r3339 was that the effect of writes to reg $00 was delayed until the next write to reg $01, $80, or $81. CNROM games not working in the latest official FCEUX release might make things confusing for users. Possible mitigations:
  • Add an automated test for this particular mistaken order dependency, and warn the user.
  • Wait for a Windows build of r3339 or later to reach EmuCR.
  • Mirror this build so that users don't have to suffer through EmuCR and its fake download buttons and CAPTCHAs that I saw last time I tried to download FCEUX from EmuCR.

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

Re: CHR RAM bank switching in mapper 28 (Action 53)

Post by rainwarrior » Tue Feb 28, 2017 11:37 am

tepples wrote:
  • Wait for a Windows build of r3339 or later to reach EmuCR.
  • Mirror this build so that users don't have to suffer through EmuCR and its fake download buttons and CAPTCHAs that I saw last time I tried to download FCEUX from EmuCR.
FCEUX now has an "interim build" link on its download page:
http://www.fceux.com/web/download.html

It's not up to 3339 just yet (still on 3338), but it seems to be somewhat regularly rebuilt.

tepples
Posts: 21841
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: CHR RAM bank switching in mapper 28 (Action 53)

Post by tepples » Fri Mar 10, 2017 2:48 pm

Today I learned that EmuCR has made a Windows build of FCEUX r3340 available. I plan to mirror it at least until the interim build on FCEUX.com is updated.
Windows executable | source snapshot

I've also remade the test ROM to more clearly show passing in FCEUX SDL r3339 and failure in FCEUX Windows 2.2.3. We can use this when supporting people who complain that one of the games in a collection displays corrupt graphics.
Attachments
a53bigchrram-0.02.zip
(20.25 KiB) Downloaded 504 times

tepples
Posts: 21841
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: CHR RAM bank switching in mapper 28 (Action 53)

Post by tepples » Mon Nov 13, 2017 2:21 pm

Epilogue: Now that a Windows executable of FCEUX is on AppVeyor, there's not quite as much of a need to work around EmuCR's deliberate annoyances. As of 17 days ago, AppVeyor is up to r3377.

Post Reply