It is currently Wed Nov 22, 2017 12:37 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 9 posts ] 
Author Message
PostPosted: Mon Feb 27, 2017 4:54 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19239
Location: NE Indiana, USA (NTSC)
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 42 times
Top
 Profile  
 
PostPosted: Mon Feb 27, 2017 5:47 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19239
Location: NE Indiana, USA (NTSC)
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 44 times
Top
 Profile  
 
PostPosted: Mon Feb 27, 2017 6:01 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6447
Location: UK (temporarily)
tepples wrote:
I couldn't immediately find the deficiency in the source code of FCEUX's Action 53 mapper.
Found it:
Code:
   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


Top
 Profile  
 
PostPosted: Mon Feb 27, 2017 7:53 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19239
Location: NE Indiana, USA (NTSC)
...and fixed already by Zero Mouse.


Top
 Profile  
 
PostPosted: Tue Feb 28, 2017 2:37 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 582
My next game would be 32k/32k, FWIW.


Top
 Profile  
 
PostPosted: Tue Feb 28, 2017 11:17 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19239
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Tue Feb 28, 2017 11:37 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5825
Location: Canada
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.


Top
 Profile  
 
PostPosted: Fri Mar 10, 2017 2:48 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19239
Location: NE Indiana, USA (NTSC)
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 42 times
Top
 Profile  
 
PostPosted: Mon Nov 13, 2017 2:21 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19239
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: babai and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group