Enhancement Proposal: Implementing Amiibo Integration for Launching ROM Files with Flexible Path Handling

Overview:

This proposal suggests enhancing the current functionality to enable the scanning of type (example Toon Link) of Amiibo figure to initiate the launch of ROM files without requiring the full file path.

Current Functionality:

Scanning an Amiibo provides the option to match it using the UID/Serial number, which is unique to each Amiibo. For example, two Toon Link Amiibo figures will each possess their own distinct UID and appear as separate tokens in Tapto.

Current Functionality:

you have to supply the full path of a game, not give a partial match to a game path.

Proposed Change:

Allowing the user to either "match" on the UID like now, or "match" using a kind of Amiibo, if possible match any character from a franchise, or any Amiibo that is the same character (example any Link character), or any character from a specific game (example any Amiibo from a Zelda game).

Proposed Change:

Allow supplying partial file path.

Needed Changes:

[x] When scanning an Amiibo add page 21 and 22 the text field
[x] When scanning an Amiibo print page 21 and 22 to socket
[x] Allow match_text to match parts or in full page 21 and 22
[ ] Fuzzy file path when launching a ROM
[x] Changes to TAPTUI to allow user to add specific parts of page 21 and page 22 to the mappings database

Optional Changes:

[ ] Add the ability to have a directory of files that are counting towards the mappings database
[ ] Add the ability to launch a random game matching regex
[ ] Add the ability to launch a multigame menu
[x] Add the ability to match a regex string, as some game series has a range of values
[x] UI: Add identifying information for over 851 amiibo's
[x] UI: Add the ability to look up amiibo's via an online service like amiiboapi.com

Notes:

The big current unknown for me is how do we know it is an Amiibo at all? If it is an Amiibo, it is a small matter of programming to alter function pollDevice in pkg/daemon/reader.go add an if statment, if it is an amiibo, instead of preforming tagText := tokens.ParseRecordText(record) format and put into tagText page 21 and 22 of the token, which will be cut out of the record variable. tagText is used for logic later. At that point basic Amiibo matching logic should "just work" and, other features can optionally be added to improve features not just for Amiibos but in general
Fuzzy path matching is implemented in another mrext project
Fuzzy path matching might need to be limited to a specific or a list of specific consoles to be more quicker when using for NFC tokens
page 21 of an amiibo looks like it might start at 0x00000054 in an amiibo binary dump. And end at 0x00000057
page 22 I believe starts at 0x00000058 and ends at 0x0000005B
Anatomy of page 21 and 22 can be found here https://docs.google.com/spreadsheets/d/19E7pMhKN6x583uB6bWVBeaTMyBPtEAC-Bk59Y6cfgxA/edit#gid=2077491727
Having multiple files count towards the mapping database will allow users (or us) to share files of pre-mapped amiibos to games
Some Game series has a range of bits (3 first bits starting at page 21), Mario 000-002, Mario Sports 09C-09D, Animal Crossing 018-051, Animal Crossing New Horizons 0A0-0A1, Pokemon 190-1D4, so matching a range or regex might be something that is really useful
Page 2 ends with 480FE0 and Page 3 equals F110FFEE for all Amiibo's except the Nintendo World bracelets
PowerUpBands (Nintendo World Bracelets) page 2 ends with 0FE0, page 3 equals F110FFee and page 4 equals A5000000

Would this enable something like: "launch a random zelda game when i put a zelda franchise amibo"? or things like that?

@asturur launching random game from a list is something we have talked about before, this would not inherently do that, but I will add it to the list of optional changes.

Including launching a menu to pick from a set list of games, like a multigamecart

Here is the output of the command jq -r '.amiibo | group_by(.head)[] | select(length > 1) | .[] | .name + " has the same page 21: " + .head' < <(!!) jq -r '.amiibo | group_by(.head)[] | select(length > 1) | .[] | .name + " has the same page 21: " + .head' < <(curl -s "https://www.amiiboapi.com/api/amiibo/") This shows example that you can match multiple mario figurines to a mario game, if you match the first 8 hex bits.

Mario has the same page 21: 00000000
8-Bit Mario Modern Color has the same page 21: 00000000
Mario - Wedding has the same page 21: 00000000
Mario has the same page 21: 00000000
Mario - Gold Edition has the same page 21: 00000000
Mario - Silver Edition has the same page 21: 00000000
8-Bit Mario Classic Color has the same page 21: 00000000
Golden - Power Up Band has the same page 21: 00000003
Mario - Power Up Band has the same page 21: 00000003
Luigi has the same page 21: 00010000
Luigi has the same page 21: 00010000
Peach - Wedding has the same page 21: 00020000
Peach has the same page 21: 00020000
Peach has the same page 21: 00020000
Yoshi has the same page 21: 00030000
Yoshi has the same page 21: 00030000
Mega Yarn Yoshi has the same page 21: 00030102
Light Blue Yarn Yoshi has the same page 21: 00030102
Pink Yarn Yoshi has the same page 21: 00030102
Green Yarn Yoshi has the same page 21: 00030102
Bowser - Wedding has the same page 21: 00050000
Bowser has the same page 21: 00050000
Bowser has the same page 21: 00050000
Wario has the same page 21: 00070000
Wario has the same page 21: 00070000
Donkey Kong has the same page 21: 00080000
Donkey Kong has the same page 21: 00080000
Diddy Kong has the same page 21: 00090000
Diddy Kong has the same page 21: 00090000
Daisy has the same page 21: 00130000
Daisy has the same page 21: 00130000
Link has the same page 21: 01000000
Link - Archer has the same page 21: 01000000
8-Bit Link has the same page 21: 01000000
Link - Rider has the same page 21: 01000000
Young Link has the same page 21: 01000000
Link - Twilight Princess has the same page 21: 01000000
Link - Ocarina of Time has the same page 21: 01000000
Link - Majora's Mask has the same page 21: 01000000
Link - Link's Awakening has the same page 21: 01000000
Link - Tears of the Kingdom has the same page 21: 01000000
Link - Skyward Sword has the same page 21: 01000000
Toon Link - The Wind Waker has the same page 21: 01000100
Toon Link has the same page 21: 01000100
Zelda has the same page 21: 01010000
Toon Zelda - The Wind Waker has the same page 21: 01010000
Zelda - Tears of the Kingdom has the same page 21: 01010000
Zelda has the same page 21: 01010000
Ganondorf - Tears of the Kingdom has the same page 21: 01020100
Ganondorf has the same page 21: 01020100
Isabelle - Summer Outfit has the same page 21: 01810000
Isabelle has the same page 21: 01810000
Isabelle has the same page 21: 01810001
Isabelle - Character Parfait has the same page 21: 01810001
K. K. Slider - Pikopuri has the same page 21: 01820001
K.K. Slider has the same page 21: 01820001
K.K. Slider has the same page 21: 01820001
Sable has the same page 21: 01870001
Sable has the same page 21: 01870001
Mabel has the same page 21: 01880001
Mabel has the same page 21: 01880001
Blathers has the same page 21: 01920001
Blathers has the same page 21: 01920001
Celeste has the same page 21: 01930001
Celeste has the same page 21: 01930001
Kicks has the same page 21: 01940001
Kicks has the same page 21: 01940001
Gulliver has the same page 21: 01a20001
Gulliver has the same page 21: 01a20001
Saharah has the same page 21: 01a60001
Saharah has the same page 21: 01a60001
Rosie - Amiibo Festival has the same page 21: 025f0001
Rosie has the same page 21: 025f0001
Stitches has the same page 21: 02820001
Stitches - Amiibo Festival has the same page 21: 02820001
Goldie - Amiibo Festival has the same page 21: 02ea0001
Goldie has the same page 21: 02ea0001
Samus has the same page 21: 05c00000
Samus - Metroid Dread has the same page 21: 05c00000
Samus Aran has the same page 21: 05c00000
R.O.B. - Famicom has the same page 21: 07810000
R.O.B. - NES has the same page 21: 07810000
Inkling - Yellow has the same page 21: 08000100
Inkling has the same page 21: 08000100
Inkling Girl has the same page 21: 08000100
Inkling Girl - Neon Pink has the same page 21: 08000100
Inkling Girl - Lime Green has the same page 21: 08000100
Inkling Boy has the same page 21: 08000200
Inkling Boy - Purple has the same page 21: 08000200
Inkling Boy - Neon Green has the same page 21: 08000200
Inkling Squid has the same page 21: 08000300
Inkling Squid - Orange has the same page 21: 08000300
Inkling Squid - Neon Purple has the same page 21: 08000300
Octoling Boy has the same page 21: 08050200
Octoling - Blue has the same page 21: 08050200
Kirby has the same page 21: 1f000000
Kirby has the same page 21: 1f000000
Meta Knight has the same page 21: 1f010000
Meta Knight has the same page 21: 1f010000
King Dedede has the same page 21: 1f020000
King Dedede has the same page 21: 1f020000
Chrom has the same page 21: 21080000
Chrom has the same page 21: 21080000
Mega Man has the same page 21: 34800000
Mega Man - Gold Edition has the same page 21: 34800000
Mega Man has the same page 21: 34800000
Shovel Knight - Gold Edition has the same page 21: 35c00000
Shovel Knight has the same page 21: 35c00000

PR #51 now has is usable, but I do not recommend trying it now if you are a regular user. Currently test binaries are not provided, one can compile it them selves, or if you are an Amiibo enthusiast and is okay with possible breaking updates in the branch, I can provide binaries on request.

That being said, it's quite fun browsing the amiibo's by Game Series and stuff when picking an amiibo to add to the mappings database

Here are my thoughts about finalising this.

I don't think it's the right approach to inject the Amiibo data into the return bytes of readNtag, because readNtag isn't really returning "some random bytes" it's used to return the first text NDEF record if it exists. Both the read functions should instead return a generic type that identifies if it's a text NDEF, Amiibo, Dimension, etc.
Once this is in place, you can check in the pollDevice loop that the tag actually was an Amiibo, not just that the record was 8 bytes
This tag result with the extra nfc toy metadata should be stored in the token object of the daemon state, so it's available to the rest of the process and the API. This is just a new field on the token type
As discussed, I don't want the "**amiibo" command to be injected silently into the text field or exist period in the command definitions as a noop. I was ok with it being sent to the socket and the tmp file but now I think about it more... I dunno. What do you think about taptui graduating from these methods and using the rest api instead? Then you have full clean access to these values in it as well
I said earlier I wanted to deprecate the text field, but this change actually adds functionality to with the regex. I know it won't be necessary anymore if the changes above are made, but maybe we should keep this in and continue support for text matching with regex? Could be a cool feature

I've said a lot about this but really these changes are quite small, it won't take long the update the types and shuffle things around. The main problem is how taptui interfaces with tapto.. I feel it's outgrown this simple socket connection and needs something more robust. How much effort would it be to convert it over to using the new rest api? I think it would be ok with curl/wget and jq right?

@wizzomafizzo

The main problem is how taptui interfaces with tapto.. I feel it's outgrown this simple socket connection and needs something more robust. How much effort would it be to convert it over to using the new rest api? I think it would be ok with curl/wget and jq right?

Specifically, deprecating the use of socket in TAPTUI and switch over to curl and jq is a minimal effort task.

Today the socket gives a comma separated list, and the comma separated list gives values with unesacped commas. Using json will make things less complex

wizzomafizzo / tapto

Enhancement Proposal: Implementing Amiibo Integration for Launching ROM Files with Flexible Path Handling #48