It is currently Sat Oct 21, 2017 8:04 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 46 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Wed Mar 30, 2016 1:46 pm 
Offline
User avatar

Joined: Thu Oct 30, 2008 8:11 pm
Posts: 37
Location: Nashville, TN
I have plethora of VRC2/VRC4 carts, I can test anything. :D


Top
 Profile  
 
PostPosted: Wed Mar 30, 2016 2:04 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6293
Location: Seattle
Are any of them already set up to take an EEPROM in lieu of PRG? I was originally intending on creating a set of 8 ROMs to make a set of NES 2.0 validation ROMs that would exhaustively test all 6* VRC4 variants and all three VRC2 variants. Rewriting the tests to work via hot-swapping would be more difficult if we don't have things to suspect are wrong.

* Including the pirate VRC4f variant


Top
 Profile  
 
PostPosted: Wed Mar 30, 2016 2:08 pm 
Offline
User avatar

Joined: Thu Oct 30, 2008 8:11 pm
Posts: 37
Location: Nashville, TN
None of them are, currently. But...with my Irwin Quick-Grip and Hakko-808 I am positive I can produce one in under 15 minutes.


Top
 Profile  
 
PostPosted: Wed Mar 30, 2016 6:10 pm 
Offline

Joined: Fri May 21, 2010 4:10 pm
Posts: 260
koitsu wrote:
Makes sense. Thanks everyone! I'll file a bug report/Issue with the NestopiaUE guy to have this rectified. I'll also see about updating the nesdev wiki (for VRC2).

As for FCEUX and its weird V != 0xff quirk: if the code there is purely for VRC2 and not VRC4, then I don't know why they don't just mask off bits 7-1 and only honour bit 0. In other words, something like this would be clearer:

Code:
/* Per official Konami documentation, VRC2 only implements horizontal (0) and
 * vertical (1) mirroring; only bit 0 is used.  nesdev thread confirming this fact:
 * http://forums.nesdev.com/viewtopic.php?f=3&t=13473
 */
case 0x9000:
case 0x9001: mirr = V & 0x01; Sync(); break;

Though the case statement isn't accurate -- the docs state clearly $9000-9FFF is mapped to the H/V toggle.

If the same code is used for VRC4, then I don't know what makes the V != 0xff quirk necessary; possibly there's some justification for it (maybe someone has official VRC4 documentation), but my gut feeling is there's probably a weird game that does something unexpected and it worked around whatever the oddity was. Too bad the commit history doesn't go back to when it was written -- thanks for digging into that, rainwarrior!

Edit: you summarise the situation beautifully well, lidnariq. Thanks for that. *thumbs up* :-)

P.S. -- I've run into my neighbour twice in the past 2 days, and he was supposed to come by last night to give me the translated results but didn't. I'll poke him tomorrow. He did say the Japanese wasn't hard and he more or less understood/got it all.


Hey Koitsu, So is this working in nestopia correctly? I thought lidnariq said that it was correct? I guess the C++ goo is too much to parse? :shock: It gives me fits hahaha.

EDIT** I see where he said it is incorrect with nestopia, i read it wrong.


Top
 Profile  
 
PostPosted: Wed Mar 30, 2016 6:16 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3064
Location: Brazil
Please, answer me ok? ^_^;;; This is iNES mapper 22, correct? The address mask should be AND F003, correct?


Top
 Profile  
 
PostPosted: Wed Mar 30, 2016 6:22 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6293
Location: Seattle
The bug is only exposed in one mapper 23 game. The only way to solve this without submappers or hashes is something similar to what FCEUX's source has, where it special-cases the value of 0xFF.

It's true that VRC2 was also used in mapper 22 (and one game on mapper 25), but all of those games apparently never tickle this problem.


Top
 Profile  
 
PostPosted: Sun Apr 03, 2016 10:41 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
Neighbour dropped by tonight with translated bits from the official VRC2 docs. Plain and simple: there's really nothing in there we don't already know (in fact, I'd say the wiki is way more thorough, albeit a bit confusing). I even asked him about the serial/EEPROM capability, but there's nothing helpful/useful in the Japanese docs there either (i.e. nothing that would explain the bugs or wiring choices).

Still on my to-do list is to file an Issue with the NestopiaUE guy -- I'll get to it, don't worry, it's on my whiteboard. ;)


Top
 Profile  
 
PostPosted: Sun Apr 03, 2016 10:51 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6293
Location: Seattle
Given the VRC2 clone that we found with a functioning microwire interface, I find myself wondering if it actually works. Perhaps Konami just decided that they were releasing no games where the additional cost of the EEPROM was worth only being able to save the game?


Top
 Profile  
 
PostPosted: Mon Apr 04, 2016 12:10 am 
Offline

Joined: Sat Jul 20, 2013 10:14 pm
Posts: 38
koitsu wrote:
Still on my to-do list is to file an Issue with the NestopiaUE guy -- I'll get to it, don't worry, it's on my whiteboard. ;)


koitsu, you probably already got this issue in Nestopia covered and documented but if you don't I figured I'd make things easier for you and prepared this:

Image

Image

I have also attached a zip file containing 2 sates, 1 with the flying shooter part demo and 1 with Konami man in the hangar ready to take off.

Again, you may already have it covered and this is made using the Nestopia core in RetroArch.


Attachments:
Wai Wai World (Japan) states.zip [3.41 KiB]
Downloaded 36 times
Top
 Profile  
 
PostPosted: Mon Apr 04, 2016 4:16 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
Thanks for the save states -- I already have these though (specifically one before hangar take-off, and one at the very end of the game before the timer runs out). The .state files *do* work in NestopiaUE (just rename the extension from .state to .nsX appropriately).

I'll include these for rdanbrook as they'll help in verification.

The screenshots aren't all that useful, as I already demonstrated in my stream/YT videos (see links in first post) what the issues are. :-)


Top
 Profile  
 
PostPosted: Mon Apr 04, 2016 4:28 am 
Offline

Joined: Sat Jul 20, 2013 10:14 pm
Posts: 38
koitsu wrote:
Thanks for the save states -- I already have these though (specifically one before hangar take-off, and one at the very end of the game before the timer runs out). The .state files *do* work in NestopiaUE (just rename the extension from .state to .nsX appropriately).

I'll include these for rdanbrook as they'll help in verification.

The screenshots aren't all that useful, as I already demonstrated in my stream/YT videos (see links in first post) what the issues are. :-)


No problem! I didn't know what you had so I took and made what I thought might be useful enable to solve this once and for all.
I'm just glad that this is gonna be solved and it works great in puNES now :-)

Image

Image


Top
 Profile  
 
PostPosted: Mon Apr 04, 2016 4:42 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
NestopiaUE issue 172 filed: https://github.com/rdanbrook/nestopia/issues/172


Top
 Profile  
 
PostPosted: Mon Apr 04, 2016 4:48 am 
Offline

Joined: Sat Jul 20, 2013 10:14 pm
Posts: 38
koitsu wrote:


Nice report :D :thumbs up:


Top
 Profile  
 
PostPosted: Tue Apr 12, 2016 11:06 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
Looks like BizHawk (NesHawk) picked up the change as well: https://github.com/TASVideos/BizHawk/co ... 46edf9fdd1 -- type there refers to an integer they set, where for VRC2 type=2 and for VRC4 type=4. So they up using this variable as the mask for which bits to honour on mirroring writes (when previously it was always set to honour bits 1-0), rather than using an if/else or case statement to differentiate.

There's been positive response to this matter from lots of mainstream emulators. Thumbs up; good community involvement. Thanks everyone!

The only "flack" I've seen, which is still ongoing, is in the NestopiaUE ticket where a single individual is hellbent on trying to keep this from being fixed properly. First they advocated the same 0xFF comparison kludge as FCEUX. Now they're arguing that 4-screen (don't ask me why 4-screen is being brought up, I think they might mean 1-screen) support can't be removed because "unofficial VRC2 games use the feature" (I've asked for a list of those games because that would be helpful). If anyone here has insights or comments to make on that, I politely ask they comment in the ticket.

I've only two "intuitions" about Wai Wai world: either the $FF write is an unexpected bug (programmer error but it works by chance), or it's intentional in the sense that Konami knew they could write $FF to the mirroring register because only D0 is honoured, hence saving themselves an lda #$01. Either way, since the hardware only looks at D0, there's absolutely nothing wrong with a non-0 or non-1 write. *shrug*

Just remember one thing: mapper 23 has historically been used for 3 separate chips: VRC2b, VRC4e, and VRC4f. VRC4 supports more than just H/V-only. It's a bummer because had VRC2b not been lumped in with the VRC4e/4f variants in this manner, we wouldn't be dealing with this today.


Top
 Profile  
 
PostPosted: Wed Apr 13, 2016 12:16 am 
Offline

Joined: Mon Dec 12, 2011 8:15 pm
Posts: 304
Attachment:
2016-04-13_15-12-51.png
2016-04-13_15-12-51.png [ 16.46 KiB | Viewed 1125 times ]


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 6 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