It is currently Sun Dec 10, 2017 8:54 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 9 posts ] 
Author Message
 Post subject: Mapper 4 as MMC3+MMC6
PostPosted: Sat Nov 29, 2014 7:08 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5885
Location: Canada
I can find documentation on the MMC3 or MMC6 separately, but I think the wiki could use a bit of information/recommendation on how to implement mapper 4.

I've noticed that FCEUX, and loopy's PowerPak mapper 4 both seem to support StarTropics just fine without a CRC. Does this mean there is a "safe" way to implement both MMC3 and MMC6 as mapper 4 without negative consequences from any of the old games? Are there drawbacks/incompatibilities to this approach that I haven't noticed? If there is no drawback, what justifies Nestopia's CRC requirement for MMC6?

Obviously, if you want to homebrew for MMC3 or MMC6 it's important to have an emulator that supports all relevant features of the chip, not just the stuff needed to play old games, but at least homebrewers have a lot of options available for this (e.g. iNES 2 headers).

Anyhow, what I'm suggesting is that if there's a "good practice" version of mapper 4 that covers normal use cases and doesn't seem to have drawbacks for non-developers, we should probably have a recommendation on how to do this on the wiki.


Top
 Profile  
 
PostPosted: Sat Nov 29, 2014 7:26 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6503
Location: Seattle
As I understand it, it was discovered that simply failing to implement the protection register doesn't seem to trip up any games, and because of how emulators and the powerpak handle saving the emulated NVRAM, they won't have any memory corruption (unlike on actual hardware, which has to deal with glitchy writes during brownout).

q.v. viewtopic.php?t=10535


Top
 Profile  
 
PostPosted: Sat Nov 29, 2014 7:54 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19322
Location: NE Indiana, USA (NTSC)
There are four strategies to support both MMC3 and MMC6:

  • NES 2.0-ignorant: Don't emulate the PRG RAM protect bits. This breaks Low G Man, which expects $6000-$7FFF to be open bus.
  • Hash: Emulate the PRG RAM protect bits. Use a hash function to detect when a good dump of StarTropics or Zoda's Revenge: StarTropics 2 (a game-length Tetris commercial) is being played. Hacks of the StarTropics game will fail.
  • Heuristic: Emulate the PRG RAM protect bits. Use heuristics to determine whether a StarTropics game or a hack thereof is being played.
  • NES 2.0: Emulate the PRG RAM protect bits. If the size of battery-backed PRG RAM is 1024 bytes, emulate them for MMC6.

A combination of NES 2.0 and Hash is probably the best way forward for new implementations of iNES mapper 4.


Top
 Profile  
 
PostPosted: Sat Nov 29, 2014 8:02 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5885
Location: Canada
So, from what I am hearing, the "solution" is to not implement write-protection and give the mapper 8k of RAM regardless. It sounds like the viability of this relies on two premises:

1. Extant MMC3 and MMC6 games do not use write protect to block writes from software, it was only used to prevent data corruption during power-off / reset etc.

2. Extant MMC6 only use their 1k of RAM as a strict subset of 8k of RAM, and don't rely on aliased read/write operations.


The next question is: are any games known to break these premises?

EDIT: Tepples has suggested Low-G Man. How does it rely on an open bus?


Top
 Profile  
 
PostPosted: Sat Nov 29, 2014 8:18 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19322
Location: NE Indiana, USA (NTSC)
The music engine in Low G Man reads from $6000-$7FFF and expects the value to equal the previous byte on the data bus, which is the high byte of the address.* For example, lda $6543 will produce AD 43 65 on the data bus, after which $65 is held through bus capacitance. Google "low g man" open bus site:nesdev.com for more.

* For indexed modes that cross pages (a,X, a,Y, and (d),Y), the high byte of the base address is used, not the final address after X or Y is added.


Top
 Profile  
 
PostPosted: Sat Nov 29, 2014 8:42 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5885
Location: Canada
Good lord, that's bizarre!


Top
 Profile  
 
PostPosted: Sat Nov 29, 2014 9:04 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6503
Location: Seattle
(obvious split point, if desired)
Do we know when/where Low G Man does this? Looking for '[\xAD\xBD\xA9\xB9].[\x41-\x7f]' only finds one thing when neither surrounded by invalid opcodes nor frameshifted...

PRG offset 0x17D31: lda $7FA5,x

Obviously it could be using indirect addressing, or something copied to RAM... but I briefly ran it in nintendulator and fceux with a breakpoint set to read/writes from $4020-$7fff and never got that to trip.


Top
 Profile  
 
PostPosted: Sat Nov 29, 2014 9:22 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5885
Location: Canada
It's through an indirect, lidnariq, info here: http://forums.nesdev.com/viewtopic.php?p=4895#p4895


Top
 Profile  
 
PostPosted: Mon Dec 08, 2014 7:54 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5885
Location: Canada
I created a note about this on the wiki. Please advise if I've missed something:
http://wiki.nesdev.com/w/index.php/INES_Mapper_004


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: TmEE and 7 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