CTRLTEST generic input test ROMs

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

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

CTRLTEST generic input test ROMs

Post by rainwarrior » Fri Feb 07, 2020 3:06 pm

Cause I wanted something to verify input with, I made a simple generic test ROM that just reads 16 bits from all 5 data lines and displays it on the screen, logging each frame row by row.
example display
example display
ctrltest4016.png (1.9 KiB) Viewed 495 times

Code: Select all

CTRLTEST
Brad Smith, 2020

ctrltest4106.nes
ctrltest4017.nes

This is a simple test ROM to check the controller input lines on NES/Famicom.

Each frame strobes $4016, then reads 16 bits from each of the 5 data lines
on either $4016 or $4017.

The bits are displayed left to right in a big-endian hexadecimal manner:
 8000 = first bit
 4000 = second bit
 2000 = third bit
 1000 = fourth bit
 0800 = fifth bit
 ...
 0080 = ninth bit
 0008 = thirteenth bit
 0001 = sixteenth bit

This is suitable for reading controllers that report up to 16 bits on any of
the data lines. Standard controllers, SNES or Virtual Boy, Zapper, or the
Famicom microphone, for example. Devices that need longer reports, such as
the SNES mouse are less suitable for these test ROMs, though you still get
the first 16 bits of their report.
Related: MSET test ROM for SNES mouse: post
Attachments
ctrltest4017.nes
(32.02 KiB) Downloaded 14 times
ctrltest4016.nes
(32.02 KiB) Downloaded 15 times
ctrltest.zip
source code
(51.4 KiB) Downloaded 11 times
Last edited by rainwarrior on Fri Feb 07, 2020 5:07 pm, edited 1 time in total.

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

Re: CTRLTEST generic input test ROMs

Post by lidnariq » Fri Feb 07, 2020 3:27 pm

I wrote a very rudimentary test that did something similar some years ago:
viewtopic.php?p=106954#p106954

The NMI is constant-timed and uses extended blanking so that it can fit in 32 reads from both $4016 and $4017 and update 352 bytes of nametable each vblank.

krzysiobal
Posts: 651
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland

Re: CTRLTEST generic input test ROMs

Post by krzysiobal » Fri Feb 07, 2020 3:44 pm

Me too! It was useful especially for testing:
* Zapper,
* 4 player adapter,
* checking if all bits in both famiclone ports wok.

But I did not care about vblank so it is blinking as crazy.
Attachments
joypad_test.nes
(16.02 KiB) Downloaded 13 times
joypad_test-0.png
joypad_test-0.png (1.57 KiB) Viewed 517 times

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

Re: CTRLTEST generic input test ROMs

Post by rainwarrior » Fri Feb 07, 2020 5:27 pm

I like lidnariq's alternative. I was kinda struggling to think about how to reasonably display all this data on the screen at once, which is why I split it into two ROMs, one for each port, and also why I kept it to 16 bits. I also wanted logs instead of immediate, just cause I've dealt with transient events that are easier to spot if you have a rolling record like this, but it's a cool alternative to just be able to look at the immediate result.

Pokun
Posts: 1324
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: CTRLTEST generic input test ROMs

Post by Pokun » Mon Feb 10, 2020 2:49 am

I have been thinking of making something to easily test raw inputs, but I didn't know everyone had done it so many times already.
I like all three solutions!

Post Reply