Page 1 of 2

VRC2/4 test program WIP

Posted: Wed May 31, 2017 4:14 pm
by AWJ
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 17345 times
Test ROM with mapper 22 header
Test ROM with mapper 22 header
vrctest22-0.png (4.47 KiB) Viewed 17345 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 17345 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?

Re: VRC2/4 test program WIP

Posted: Wed May 31, 2017 4:45 pm
by infiniteneslives
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?

Re: VRC2/4 test program WIP

Posted: Wed May 31, 2017 4:57 pm
by AWJ
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.

Re: VRC2/4 test program WIP

Posted: Wed May 31, 2017 5:14 pm
by infiniteneslives
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.

Re: VRC2/4 test program WIP

Posted: Wed May 31, 2017 5:27 pm
by lidnariq
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.

Re: VRC2/4 test program WIP

Posted: Wed May 31, 2017 5:27 pm
by AWJ
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.

Re: VRC2/4 test program WIP

Posted: Wed May 31, 2017 5:36 pm
by lidnariq
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...

Re: VRC2/4 test program WIP

Posted: Thu Jun 08, 2017 5:47 am
by AWJ
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)

Re: VRC2/4 test program WIP

Posted: Thu Jun 08, 2017 10:51 am
by infiniteneslives
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.

Re: VRC2/4 test program WIP

Posted: Thu Jun 08, 2017 3:19 pm
by AWJ
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.

Re: VRC2/4 test program WIP

Posted: Thu Jun 08, 2017 3:54 pm
by infiniteneslives
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.

Re: VRC2/4 test program WIP

Posted: Fri Sep 01, 2017 8:59 am
by NewRisingSun

Code: Select all

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

Re: VRC2/4 test program WIP

Posted: Sat Sep 02, 2017 8:14 am
by AWJ
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.

Re: VRC2/4 test program WIP

Posted: Sat Sep 02, 2017 12:20 pm
by rainwarrior
Thanks for making this! It's been on my to-do list for a long while. Looks nicer than what I would have done. ;)

Re: VRC2/4 test program WIP

Posted: Sat Sep 02, 2017 12:24 pm
by NewRisingSun
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.