VRC2/4 test program WIP

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

AWJ
Posts: 433
Joined: Mon Nov 10, 2008 3:09 pm

VRC2/4 test program WIP

Post by AWJ » Wed May 31, 2017 4:14 pm

The following are WIP screenshots of a VRC2/4 test program. All three screenshots are the exact same ROM with different iNES headers, running in FCEUX current SVN (r3372).
Test ROM with mapper 21 header
Test ROM with mapper 21 header
vrctest21-0.png (4.55 KiB) Viewed 14806 times
Test ROM with mapper 22 header
Test ROM with mapper 22 header
vrctest22-0.png (4.47 KiB) Viewed 14806 times
Test ROM with mapper 4 header (not VRC2/4; probing fails)
Test ROM with mapper 4 header (not VRC2/4; probing fails)
vrctest4-0.png (1.91 KiB) Viewed 14806 times
Briefly, the test program probes the connections of pins 3, 4 and 21 by writing values to $B0xx and then reading from CHR ROM via $2007 to see which CHR banks got switched in. Once it has determined the pin connections (and therefore what addresses to use to write to each mapper register) it tests the VRC4-specific capabilities: one-screen mirroring, swapping PRG $C000 instead of $8000, and IRQs (I'm currently working on the IRQ tests). After it has tested everything, it will display the ASIC type (VRC2 or VRC4), the PCB name that matches the results if one can be found (or "LEGACY EMU" if the results match an iNES mapper but not a specific PCB), and the iNES mapper number and NES 2.0 submapper number if any. Results are colour-coded: green for PCB-accurate behaviour, amber for legacy emulation behaviour (e.g. multiple address lines ORed together), and red for errors. However, the colour-coding is intended to be non-essential to interpreting the results.

I'd just like to make sure I'm on the right track here. Are there any suggestions for improvement?

User avatar
infiniteneslives
Posts: 2097
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: VRC2/4 test program WIP

Post by infiniteneslives » Wed May 31, 2017 4:45 pm

Nice work, looks to be quite a nice test rom!

Does it check CHR-ROM bank size of 2KB with VRCIIa compared to 1KB of VRCIIb/c? Is that what the CHR A10 test is denoting?
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

AWJ
Posts: 433
Joined: Mon Nov 10, 2008 3:09 pm

Re: VRC2/4 test program WIP

Post by AWJ » Wed May 31, 2017 4:57 pm

infiniteneslives wrote:Nice work, looks to be quite a nice test rom!

Does it check CHR-ROM bank size of 2KB with VRCIIa compared to 1KB of VRCIIb/c? Is that what the CHR A10 test is denoting?
The bank size is the same (eight banks of 1KB) but the bank numbers are effectively right-shifted 1 place, so you have to write n << 1 to the register to select bank n. As a result, that PCB only supports 128KB of CHR ROM even though the VRC2 itself supports 256KB. But yes, that's what the CHR A10 line means.

User avatar
infiniteneslives
Posts: 2097
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: VRC2/4 test program WIP

Post by infiniteneslives » Wed May 31, 2017 5:14 pm

Ahh I see, guess I misunderstood that looking back at my notes. Thanks for clearing that up.

Something that might be of interest is to add detection of what's seen at $6000-7FFF. Whether it's VRC2 $6000-6FFF latch on bit 0, VRC4 2KByte RAM mirrored $6000-6FFF, or 8KB of PRG-RAM.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

lidnariq
Posts: 8785
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: VRC2/4 test program WIP

Post by lidnariq » Wed May 31, 2017 5:27 pm

or VRC2 without the latch and instead some random (hopefully) fixed value.

e.g. the PCB corresponding to mapper 22 should always return 0 in the lsbit.

AWJ
Posts: 433
Joined: Mon Nov 10, 2008 3:09 pm

Re: VRC2/4 test program WIP

Post by AWJ » Wed May 31, 2017 5:27 pm

infiniteneslives wrote:Ahh I see, guess I misunderstood that looking back at my notes. Thanks for clearing that up.

Something that might be of interest is to add detection of what's seen at $6000-7FFF. Whether it's VRC2 $6000-6FFF latch on bit 0, VRC4 2KByte RAM mirrored $6000-6FFF, or 8KB of PRG-RAM.
I considered including some kind of RAM test, but the presence of RAM is semi-independent of the PCB type, both in NES 2.0 (where it's a separate field from the mapper and submapper) and in original Konami hardware. For example, out of the four games on PCB 352396, two have RAM mounted, while the other two leave the space unpopulated.

lidnariq
Posts: 8785
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: VRC2/4 test program WIP

Post by lidnariq » Wed May 31, 2017 5:36 pm

Yeah, but distinguishing between VRC4 (regardless of amount of RAM) and VRC2 (with the varying bit behaviors) seems to me like it should be in scope...

AWJ
Posts: 433
Joined: Mon Nov 10, 2008 3:09 pm

Re: VRC2/4 test program WIP

Post by AWJ » Thu Jun 08, 2017 5:47 am

I would greatly appreciate it if someone could test the attached WIP on a real VRC4 board (any will do, but it must be VRC4 and not VRC2--the IRQs are what I'm interested in) I'm getting inconsistent IRQ timing between emulators. I think I know what the main cause is (accurately checking IRQs on the last cycle of each 6502 instruction vs. conveniently checking them between instructions), but I believe Nintendulator additionally has an off-by-one error in its VRC pseudo-scanline IRQ implementation.

The zip includes one burnable CHR image (chr.bin) and three different burnable PRG images (prg*.bin), in addition to ca65 source code. If my calculations and the information on the wiki are correct, on hardware, prgearly.bin and prgmedium.bin should both display "YES" on both IRQ timing lines, while prglate.bin should display "LATE". On less-accurate emulators like FCEU that check IRQs between instructions, prglate.bin and prgmedium.bin display "YES" and prgearly.bin displays "EARLY".

(EDIT: deleted outdated attachment)
Last edited by AWJ on Sat Sep 16, 2017 10:11 am, edited 1 time in total.

User avatar
infiniteneslives
Posts: 2097
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: VRC2/4 test program WIP

Post by infiniteneslives » Thu Jun 08, 2017 10:51 am

I don't have a socketed original VRC4 board to test with. But I could test on one of my flash boards with the my replica VRC4 if that's of value. FWIW, it's logically equivalent to my knowledge displaying scanline counter artifacts identically to an original kid dracula cart.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

AWJ
Posts: 433
Joined: Mon Nov 10, 2008 3:09 pm

Re: VRC2/4 test program WIP

Post by AWJ » Thu Jun 08, 2017 3:19 pm

infiniteneslives wrote:I don't have a socketed original VRC4 board to test with. But I could test on one of my flash boards with the my replica VRC4 if that's of value. FWIW, it's logically equivalent to my knowledge displaying scanline counter artifacts identically to an original kid dracula cart.
Sure, that's better than nothing. Can the register addressing on your flash boards be configured, or is it fixed per board? If you can test all the different VRC4 board types and verify that they're identified correctly that'd be even better.

User avatar
infiniteneslives
Posts: 2097
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: VRC2/4 test program WIP

Post by infiniteneslives » Thu Jun 08, 2017 3:54 pm

I tried to test it out quick before this afternoon as I'm on my way out of town. But ran into some issue getting things with my board configured properly. I should be able to test things out after next week. My boards can be configured for each flavor of VRC2/4 so I should be able to test each one out for you and report back results.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

NewRisingSun
Posts: 1062
Joined: Thu May 19, 2005 11:30 am

Re: VRC2/4 test program WIP

Post by NewRisingSun » Fri Sep 01, 2017 8:59 am

Code: Select all

    .byte $02, $01, Result::yes, Result::vrc4 ; mapper 23 sub 3
That should be Result::vrc2.

AWJ
Posts: 433
Joined: Mon Nov 10, 2008 3:09 pm

Re: VRC2/4 test program WIP

Post by AWJ » Sat Sep 02, 2017 8:14 am

NewRisingSun wrote:

Code: Select all

    .byte $02, $01, Result::yes, Result::vrc4 ; mapper 23 sub 3
That should be Result::vrc2.
Thanks a lot for bumping this thread; I'm embarrassed to admit I'd totally forgotten about this little project :oops:

Checking my local copy of the source against the attached WIP, it seems I'd already fixed that submapper 3 mistake... and done almost nothing else. Apparently I never got around to testing RAM presence/size (though I still think that's more a generic NES 2.0 compliance thing than something that belongs in a mapper-specific test ROM)

Attached is an updated version with the error fixed, and this time with .nes images for every mapper and submapper. IRQ timing (and everything else) is still untested on hardware.
Attachments
vrctest.zip
(36.16 KiB) Downloaded 935 times

User avatar
rainwarrior
Posts: 7677
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: VRC2/4 test program WIP

Post by rainwarrior » Sat Sep 02, 2017 12:20 pm

Thanks for making this! It's been on my to-do list for a long while. Looks nicer than what I would have done. ;)

NewRisingSun
Posts: 1062
Joined: Thu May 19, 2005 11:30 am

Re: VRC2/4 test program WIP

Post by NewRisingSun » Sat Sep 02, 2017 12:24 pm

I had actually finished my own set of test ROMs and posted them here, but deleted them after I saw that AWJ had already completed his and that his were nicer to look at and had more features.
AWJ wrote:Apparently I never got around to testing RAM presence/size (though I still think that's more a generic NES 2.0 compliance thing than something that belongs in a mapper-specific test ROM)
I agree. Something else that might be interesting to add is to check for the Wai Wai World 1 single-screen mirroring prevention hack. Basically, the hack is there if single-screen-mirroring is not supported when writing $FF to the mirroring register, but is supported when the single-screen bit is set but the value written isn't $FF.

Post Reply