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).tepples wrote:I've attached the new test ROM. Push Start torichbegin 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
Multi-discrete mapper
Moderator: Moderators
Re: Multi-discrete mapper
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
Re: Multi-discrete mapper
CPLD with my verilog: Passtepples wrote:I've attached the new test ROM. Push Start torichbegin the automatic test.
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
Re: Multi-discrete mapper
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.
P.S. If you don't get this note, let me know and I'll write you another.
Re: Multi-discrete mapper
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.
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
Re: Multi-discrete mapper
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.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.
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
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
Re: Multi-discrete mapper
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.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.
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
Re: Multi-discrete mapper
Any plan to bring this mapper to the Everdrive N8?
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
Re: Multi-discrete mapper
It's fully defined on the wiki including two forms of the source code.SkinnyV wrote:Any plan to bring this mapper to the Everdrive N8?
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
Re: Multi-discrete mapper
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
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Multi-discrete mapper
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.
Re: Multi-discrete mapper
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.
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Multi-discrete mapper
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...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.
(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.)
Re: Multi-discrete mapper
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.
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.
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Multi-discrete mapper
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?
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?