It is currently Mon Oct 23, 2017 5:33 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 62 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
PostPosted: Sun Nov 11, 2012 10:26 am 
Offline

Joined: Fri Oct 26, 2012 5:27 pm
Posts: 76
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).


Top
 Profile  
 
PostPosted: Sun Nov 11, 2012 12:55 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1905
Location: WhereverIparkIt, USA
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


Top
 Profile  
 
PostPosted: Sun Nov 11, 2012 7:22 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1390
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.


Top
 Profile  
 
PostPosted: Fri Nov 23, 2012 9:54 am 
Offline

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


Top
 Profile  
 
PostPosted: Sat Nov 24, 2012 12:22 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1905
Location: WhereverIparkIt, USA
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


Top
 Profile  
 
PostPosted: Mon Jan 21, 2013 1:28 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1905
Location: WhereverIparkIt, USA
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


Top
 Profile  
 
PostPosted: Mon Mar 04, 2013 1:06 am 
Offline

Joined: Wed May 04, 2011 2:41 pm
Posts: 421
Location: Montréal, Canada
Any plan to bring this mapper to the Everdrive N8?


Top
 Profile  
 
PostPosted: Mon Mar 04, 2013 1:25 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1905
Location: WhereverIparkIt, USA
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


Top
 Profile  
 
PostPosted: Mon Mar 04, 2013 2:05 am 
Offline

Joined: Wed May 04, 2011 2:41 pm
Posts: 421
Location: Montréal, Canada
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 :)


Top
 Profile  
 
PostPosted: Tue Jan 31, 2017 8:38 am 
Offline
User avatar

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

Top
 Profile  
 
PostPosted: Tue Jan 31, 2017 8:57 am 
Offline

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


Top
 Profile  
 
PostPosted: Tue Jan 31, 2017 10:20 am 
Offline
User avatar

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


Top
 Profile  
 
PostPosted: Tue Jan 31, 2017 10:33 am 
Offline

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


Top
 Profile  
 
PostPosted: Tue Jan 31, 2017 10:52 am 
Offline
User avatar

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


Top
 Profile  
 
PostPosted: Tue Jan 31, 2017 2:39 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19122
Location: NE Indiana, USA (NTSC)
Is the new description any better?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 62 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Memblers 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