nesdev.org

I figured out this would be pretty convenient way to enter passwords:
Instead of having password that consists of characters, it would consist of direction-button pairs.
To input the password, player would first hold direction and then press button to pair that direction with.
This would allow to store 4 bits of data for each pair when using 4 directions. Using 8 directions would allow storing 5 bits of data.

I made an demo rom that shows how this works in practice.
It works just like I previously explained. First hold some direction using d-pad and it will show you the direction. Then while holding the direction, press a, b, select or start.
The demo will display the pair that you entered and also an hexadecimal value that corresponds to the entered pair.
After entering 14 pairs you can reset the demo by pressing start.

So it's essentially a special case of Valve's "flower" input method for hex nibbles.

Do you have to write down the little arrows and symbols? How do you type them? It seems to trade efficiency in entry for tedium in recording and representation.

Also, do the entries have to be chords? Since it requires that the directional component be entered first, it seems it could just have you press them in sequence. Since you impose that odd entries are directional and even ones buttons, this bit of information is lost so it still only has 2 bits per press as with the chords.

Direction(s) + button is certainly a chord.

I think it is a nice idea, and recording-wise it is not too bad, there were worst examples. Like passwords made of pictures, even a lot of them.

I imagine that in a polished implementation, a guide to what key does what would appear on the screen, and pressing a direction without a button would move the cursor. Hold Up on the Control Pad, and the [ 7 6 5 4 ] is highlighted in light gray ($10). 7 and 6 are drawn in black to represent Select and Start, and 5 and 4 are drawn in red ($16) to represent B and A. Let go of Up, and the highlight disappears.

EDIT: I drew an illustration.

So in the illustration for up, select would be 7, start 8, B 9, and A A (i.e. laid out as the buttons are on the controller).

My point was that the chords don't increase number of bits per button press (2 bits per press). I take it that the chording is used so that a simple visual mapping can be used and the password presented as numbers and letters, rather than the chord sequences themselves.

tepples wrote:So it's essentially a special case of Valve's "flower" input method for hex nibbles.

Yes, and no. Input method is the same, usage is different.
Password works as an instructions for what you'll have to press in order to enter the password. You don't have to know what value each direction-button combination represent.

blargg wrote:It seems to trade efficiency in entry for tedium in recording and representation.

It would, if we were in the 80's or 90's. These days people just tend to take photos of the password using camera.
Even if player would decide to write password down on paper, I think this would improve the overrall efficiency of using the password system when compared to string passwords, since when writing down or entering the password player would have to look only in one place. The most tedious part when entering a string password is that you'll have to look at the password and the screen at the same time.

blargg wrote:Also, do the entries have to be chords? Since it requires that the directional component be entered first, it seems it could just have you press them in sequence. Since you impose that odd entries are directional and even ones buttons, this bit of information is lost so it still only has 2 bits per press as with the chords.

Entering in chords is necessary for the user interface to be simple. In this way you can use A and B for moving the cursor, and start and select for accepting and returning to the previous menu.
If password would be entered in a sequence instead of chrods, you couldn't move the cursor when entering even entries. Unless you would in that case use d-pad for moving the cursor, but that would be just silly.

This seems like a neat idea but in reality it makes things a little more complicated... why not just have the password itself be directions or buttons? 8 possible inputs not counting combinations.

In what you replied to, because it would prevent meta-functions while entering the password:

ε-δ wrote:If password would be entered in a sequence instead of chrods, you couldn't move the cursor when entering even entries. Unless you would in that case use d-pad for moving the cursor, but that would be just silly.

blargg wrote:In what you replied to, because it would prevent meta-functions while entering the password:

ε-δ wrote:If password would be entered in a sequence instead of chrods, you couldn't move the cursor when entering even entries. Unless you would in that case use d-pad for moving the cursor, but that would be just silly.

True, but if it's just eight characters (24 bits of data) it could be re-done so quickly that it might not be much of an issue.