Multi-discrete mapper

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderator: Moderators

natt
Posts: 76
Joined: Fri Oct 26, 2012 5:27 pm

Re: Multi-discrete mapper

Post by natt »

tepples wrote:I've attached the new test ROM. Push Start to rich begin the automatic test.

PowerPak mapper based on kev's Verilog: Pass
NESICIDE: Pass until reset phase; emulator does not support soft reset
FCEUX SVN: Pass until reset phase; soft reset changes to last bank
Thanks for the automatic test rom, it's easier to work with. Bizhawk starting with r3757 appears to pass all tests (including the soft reset and hard reset ones).
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Multi-discrete mapper

Post by infiniteneslives »

tepples wrote:I've attached the new test ROM. Push Start to rich begin the automatic test.
CPLD with my verilog: Pass


Nice work Tepples, and everyone else involved! Sounds like we've got all the pieces and verification needed now to support Tepples' Action 53 menu system. :)
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Multi-discrete mapper

Post by Quietust »

Nintendulator r1278 appears to pass all tests with this ROM.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Multi-discrete mapper

Post by tepples »

I just realized something. I may need to add a test of writing to $D000-$DFFF to make sure that writes to $D000-$DFFF go only to the register value and not to register select. Because PRG /CE changes several nanoseconds later than M2, the decoding function might confuse $5000-$5FFF with $D000-$DFFF.
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Multi-discrete mapper

Post by infiniteneslives »

tepples wrote:I just realized something. I may need to add a test of writing to $D000-$DFFF to make sure that writes to $D000-$DFFF go only to the register value and not to register select. Because PRG /CE changes several nanoseconds later than M2, the decoding function might confuse $5000-$5FFF with $D000-$DFFF.
Probably a good idea to check out. Although if the Game never writes to $D000-DFFF it shouldn't be a problem, but you can't really guarantee that from your end. I wouldn't expect it to be an issue because decoding WRAM has the same issue with $6000-7FFF vs $C000-FFFF. When writing to $C000-FFFF A13,14,/CE,&M2 are all high for the couple nanoseconds you're talking about. This could cause obvious issues especially with mappers such as MMC3. I think the think that's preventing the issue is the minimum pulse width of the WRAM. A quick look shows it's somewhere around 15nsec, which is quite a bit longer than the M2/CE decoding glitch.

I actually did see this decoding glitch propagating to the /CE pin on the WRAM at one point when I was debugging early on with this multi-discrete mapper. Probably worth going back and trying to measure the width just for reference, although my 30+yr old scope might be a little slow to accurately measure such small pulses...

I can't really figure out what the minimum pulse width is on the XC9500XL series CPLDs from datasheets... Running the low slew rate setting should help out for these things. I'd guess we're okay but can't be 100% sure without actually testing it.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Multi-discrete mapper

Post by infiniteneslives »

tepples wrote:I just realized something. I may need to add a test of writing to $D000-$DFFF to make sure that writes to $D000-$DFFF go only to the register value and not to register select. Because PRG /CE changes several nanoseconds later than M2, the decoding function might confuse $5000-$5FFF with $D000-$DFFF.
So I've confirmed that the whole /M2 to PRG /CE delay can cause issues in practice. I noticed I was having issues with loopy's mmc3 version of SMB2j with my usual decoding of A13,14,PRG/CE,M2 for $6000-$7FFF. Digging a little into the ROM I realized during start up it copies a bank of PRG ROM into WRAM and then operates from WRAM for the most part (including the potentially trouble some writes to the scanline counter) I don't know where it was getting tripped up exactly, either the coping massive block to WRAM or operating from WRAM. But either way I was getting 20nsec glitches on WRAM /CE due to the PRG/CE delay from M2.

I was able to resolve everything by placing a 1nF cap on WRAM /CE line to filter out the glitch. Kind of a hassle to resolve this problem though, because the best solution would be to delay M2 far enough to remove the glitch, I'm guessing that's what Nintendo does in it's ASIC mappers. In an asic you can just add a series of slow inverters to give a good amount of delay, but in a (simple) CPLD like the Xlinix 9500XL series you don't have tools like this available to you.

Just speculation: but this may also be part of the reason that you're able to disable writes to WRAM on the MMC3. I don't know what most games' practice is for when they disable writes to WRAM and how many games actually operate/execute from WRAM.

The only good way to delay M2 that I could come up with is to add some external gates which is kinda a pain/expensive... I tried a few RC filters on M2 but the few combos I tried were affecting M2 on the mobo which in turn delayed PRG/CE further and never really got rid of the glitch... Or the resistor was too big and the cap would charge up but never discharge. Thinking about it now, perhaps adding a capacitor discharge resistor to ground would work out. Kinda like having a voltage divider with a filter cap in parallel with the 'bottom' resistor. One other thing I didn't consider was trying to make use of the CPLD's input capacitance by just putting a large resistor on the input.

In any event I thought I'd share my related findings thus far, perhaps writing that test wouldn't be a bad idea. And see if you can break it for register writes... :)
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
SkinnyV
Posts: 427
Joined: Wed May 04, 2011 2:41 pm
Location: Montréal, Canada
Contact:

Re: Multi-discrete mapper

Post by SkinnyV »

Any plan to bring this mapper to the Everdrive N8?
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Multi-discrete mapper

Post by infiniteneslives »

SkinnyV wrote:Any plan to bring this mapper to the Everdrive N8?
It's fully defined on the wiki including two forms of the source code.

I'm guessing there isn't anyone on here who's dabbled with making their own everdrive mappers yet. I'd suggest talking to the developer and pointing out this info to them asking for support. The availability of source code should make it fairly painless for them.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
SkinnyV
Posts: 427
Joined: Wed May 04, 2011 2:41 pm
Location: Montréal, Canada
Contact:

Re: Multi-discrete mapper

Post by SkinnyV »

I'll try to mention it to Krikzz, thanks. But I guess he'll start by fixing the MMC3 logic before taking a look at implementing homebrew mapper :)
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Multi-discrete mapper

Post by rainwarrior »

The Twin Dragons ROM from here produces a blank screen (but otherwise functional) on Nintendulator. Does the Nintendulator version of the mapper only support CHR-RAM?
https://forums.nesdev.com/viewtopic.php?f=32&t=15193


Edit: Never mind, glutock said it was a problem with the ROM.


I'm wondering what the 8k version of the PowerPak mapper is for, as well. Is that just for some historical record? Why would anyone want to use that one instead of the 32k version?
Last edited by rainwarrior on Tue Jan 31, 2017 7:32 pm, edited 1 time in total.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Multi-discrete mapper

Post by tepples »

Mostly it's about making test and production as similar as possible, ensuring that games that will eventually be distributed on a cart with 8 KiB of CHR RAM don't depend on more than that. If the PowerPak mappers supported NES 2.0's RAM size field, there would need to be only one mapper file.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Multi-discrete mapper

Post by rainwarrior »

tepples wrote:...ensuring that games that will eventually be distributed on a cart with 8 KiB of CHR RAM don't depend on more than that.
By "eventually" do you mean that no games exist that require it? Is it a forseeable eventuality? I was under the impression that 256 kbit SRAM is cheaper than 64 kbit...

(Perhaps what I'm recommending here is that you might edit the post to explain that the 32k version is the one people should normally want to use, to avoid confusion.)
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Multi-discrete mapper

Post by tepples »

Let me try again:

The 32K version corresponds to a board where A13 and A14 on the CHR memory are connected to the mapper. The 8K version corresponds to a board that grounds CHR A13 and A14 because the reduced-functionality CPLD does not output those signals in order to save two macrocells and two outputs. I seem to remember Action 53 volume 1 and 2 using the 8K version and the implementation in non-NES 2.0 emulators (such as FCEUX 2.2.2, still the latest in Ubuntu's repo) also being the 8K version.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Multi-discrete mapper

Post by rainwarrior »

Okay, well the description here specifically says 6264 and 62256, so you might understand why I would make this assumption about the implementation.


What I was trying to suggest, though, in the form of an oblique question, is that having two versions, and only explaining their difference by means of this very technical distinction is probably confusing for the majority of users. I'm talking about people that just want to download "the thing that will work" so they can play the ROM they have.

One has general purpose (compatible with all extant ROMS?), and the other is really a single purpose test for developers only, right? Wouldn't it be helpful to say this in that post?
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Multi-discrete mapper

Post by tepples »

Is the new description any better?
Post Reply