It is currently Thu Dec 13, 2018 6:16 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Mon Jul 23, 2018 12:32 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 709
If the goal for the VRC2 and VRC4 submappers was that emulators should not respond to address lines to which the original hardware did not respond, then there need to be at least two more submappers for consistency:

Mapper 85.0: Konami VRC7a/b: ASIC An pin connected to both CPU A3 and CPU A4 (0x18), in other words, "unknown", the default behavior
Mapper 85.1: Konami VRC7b: ASIC An connected to CPU A3 (0x08)
Mapper 85.2: Konami VRC7a: ASIC An connected to CPU A4 (0x10)

Mapper 16.0: Bandai FCG-1/2 or LZ93D50: Mapper responds in the $6000-$FFFF range, may or may not support 256 byte EPROM (denoted by NES 2.0 PRG-NVRAM field), IRQ counter may or may not be latched.
Mapper 16.4: Bandai FCG-1/2: Mapper responds only in the $6000-$7FFF range, no EPROM support, IRQ counter is not latched.
Mapper 16.5: Bandai LZ93D50: Mapper responds only in the $8000-$FFFF range, support for 256 byte EPROM (denoted by NES 2.0 PRG-NVRAM field), IRQ counter is latched.
Note that these are different from kevtris' old proposal that merely disambiguated the save data size and is rightfully deprecated, but did not distinguish the ASIC type.

Also, I noticed that among the discrete mappers, ANROM, UxROM and CNROM have bus-conflict-disambiguating submappers, but not MHROM/GNROM. Was this an oversight, or on purpose because there are supposed to have been bus-conflict-avoiding UxROM and CNROM boards (though I don't know any) but no bus-conflict-avoiding MHROM/GNROM board?

Edit: Mapper 16 proposal modified to not collide with previous deprecated proposal.


Last edited by NewRisingSun on Thu Aug 09, 2018 11:18 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Jul 23, 2018 1:09 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7820
Location: Seattle
Yes, discrete logic mappers were only allocated variations as we found they existed.

Submappers were allocated for VRC2/4 because the conflation actually exposed bugs in the lumped emulation (such as Wai Wai World relying on not have 1-screen mirroring, or ... whatever the game is that incorrectly starts writing to the wrong register set during the credits).

But as far as we know, there's no emulation failures due to lumping the two PCB layouts for VRC7.

On the other hand, the difference in IRQ behavior on the Bandai FCG series definitely does warrant something. Unfortunately, kevtris already allocated some redundancy here and has separately made it clear that he's not interested in being told his allocations were redundant.


Top
 Profile  
 
PostPosted: Mon Jul 23, 2018 1:17 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 709
lidnariq wrote:
Yes, discrete logic mappers were only allocated variations as we found they existed.
I wonder which games used UxROM/CNROM without bus conflicts. The wiki previously mentioned Colorful Dragon as CNROM without bus conflicts, but that one turned out to be a mapper hack, as confirmed by redumps of the original Sachen cartridge and of a Game Doctor FDS disk that matched the Mapper 3 ROM in its PRG/overdumped CHR data. Camerica games are basically UNROM without bus conflicts, but those go as Mapper 71 anyway.
lidnariq wrote:
But as far as we know, there's no emulation failures due to lumping the two PCB layouts for VRC7.
I'd still like to allocate it for consistency as well as neatness and exactness of emulation.
lidnariq wrote:
Unfortunately, kevtris already allocated some redundancy here and has separately made it clear that he's not interested in being told his allocations were redundant.
Do we need to take that older proposal into account? Has any emulator implemented it? I suppose I could change the new submapper numbers to ones not used by that older proposal.


Top
 Profile  
 
PostPosted: Mon Jul 23, 2018 9:27 pm 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 713
The only games we have confirmed that have issues with bus conflict are Cybernoid and Donkey Kong Official Edition. The former requires bitwise AND of CPU value and ROM value to function properly after changing from music to sound effects or vice versa, the latter requires the absence of bus conflicts to work without graphics glitches. Both ROMs can be patched to avoid these issues. Officially both games use Mapper 3/CNROM, which canonically does not have bus conflict prevention hardware. Other games either account for bus conflicts or use hardware which accounts for them.

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog


Top
 Profile  
 
PostPosted: Thu Aug 09, 2018 11:17 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 709
Here are test ROMs for the proposed submappers to mappers 16 and 85. The mapper 16 test ROM only tests the address range of the CHR register; it does not test whether the IRQ counter is latched or not, and does not test the EPROM size (i.e. not the deprecated submappers).


Attachments:
TEST016.7z [1.25 KiB]
Downloaded 128 times
TEST085.7z [1.26 KiB]
Downloaded 130 times
Top
 Profile  
 
PostPosted: Sun Aug 19, 2018 12:22 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 709
As I am preparing my edits for the Bandai FCG submappers, I noticed that the submapper proposal page lists:
  • 0: iNES Mapper 153 (SRAM)
  • 1: iNES Mapper 157 (Datach)
  • 2: iNES Mapper 159 (128B EEPROM)
  • 3: "Normal" iNES Mapper 016 behavior. (256B or no EEPROM)
while the linked submapper.txt file lists:
Code:
Mapper 16.0
-----------
default Bandai mapper.
Can use EEPROM type #1, generally 512 bytes

Mapper 16.1
-----------
EEPROM type #2, 128 bytes only

Mapper 16.2
-----------


Mapper 16.3
-----------
If the submapper table is to include the deprecated submappers, I need to know which version of the deprecated submapper proposal to use. The one on the submapper proposal page seems to get it backwards by putting the default behavior not on submapper #0, but on #3. Which means that deprecating the proposed submapper #0 becomes a bit awkward, because I will of course put the default behavior (combined FCG-1/2 and LZ93D50) at submapper #0.


Top
 Profile  
 
PostPosted: Sun Aug 19, 2018 9:57 am 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7820
Location: Seattle
The version that had submappers for mappers 153/157/159 is also from kevtris. I assume he deprecated and replaced the duplicate assignments.


Top
 Profile  
 
PostPosted: Sun Aug 19, 2018 12:13 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 709
I meant the reverse order on the wiki. What is listed as submapper #3 should be #0, #2 should be #1, #1 should be #2, and #0 should be #3, for it to make sense.


Top
 Profile  
 
PostPosted: Sun Aug 19, 2018 1:33 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7820
Location: Seattle
I swear that when I edited that onto the wiki, the copy of kevtris's submapper definitions defined submapper 0 as equivalent mapper 153, unlike what it says now.

Since I foolishly didn't record at the time whatever reference I was using... <shrug of defeat>

Nevermind that his comment about "512 bytes" is nonsense :/


Top
 Profile  
 
PostPosted: Sun Aug 19, 2018 11:43 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 709
Still makes no sense, because submapper 0 is supposed to denote standard mapper 016 behavior.

I have implemented my changes in the wiki, both for mapper 16/153/157/159 and 085. I duplicated the register information that is common among16/153/157/159, because having to mentally disambiguate four mappers and two submappers in a single entry would make the article unreadable.

Separating the two VRC7 configurations is still the right thing to do, to be congruent with the other VRCs, to describe the hardware more accurately, to provide a valid homebrew testing environment, and to not assume that one of the games might not, as one of the Goemon games does, set the other address line at some late point in the game.


Top
 Profile  
 
PostPosted: Sun Aug 19, 2018 11:45 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 709
Oh, and in my emulation of mapper 157, I have to OR the outputs of both EEPROMs, not AND, for Battle Rush to successfully read the external EEPROM's data.


Top
 Profile  
 
PostPosted: Mon Aug 20, 2018 9:40 am 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7820
Location: Seattle
The game has active I²C communication going on between both EEPROMs at the same time?


Top
 Profile  
 
PostPosted: Mon Aug 20, 2018 9:54 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 709
No, the I²C EEPROM implementation from stock Nintendulator just doesn't implement the open drain characteristic right, setting the line to 0 instead of 1 outside of transfer. That should be easy enough to modify.


Last edited by NewRisingSun on Mon Aug 20, 2018 9:56 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Aug 20, 2018 9:56 am 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7820
Location: Seattle
Ah! Well, that would do it.


Top
 Profile  
 
PostPosted: Mon Aug 20, 2018 10:19 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 709
I was going to ask why the Datach would implement two EEPROM I²C communication with two clock lines instead of setting up each EEPROM with different A0-A2 pin settings, until I saw that the 24C01 has no A0-A2 pins. :P


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


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