Help with adding FAV/SCAN support to RM

[gfb107]

Well, it finally happened. Someone actually tried to use RM to program the FAV/SCAN button, and discovered that RM doesn't support it. See this post.
That means it is now time to add that support. How does the FAV/SCAN support in KM work?

[The Robman]

I don't remember the exact details (and I'm the one that added it to KM) but basically all we did was adapt the fav/scan special protocol.

The fav/scan special protocol only works with built in protocols and only works with protocols that have 1-byte of variable data. I manually added the logic to many of the hacked protocols that KM supports, plus I added logic in KM that will use a slightly different version of the code depending on the number of bytes of variable data.

In KM, unhide the p-hacked sheet, then look at the S3C8 exec code, you'll find the fav/scan logic buried in there. Then unhide the work sheet, the actual protocol code is generated is cells D28 thru D31.

[johnsfine]

I was hoping for a clear enough answer from Rob that my partial and distorted understanding wouldn't be needed at all. I don't think Rob gave us that much. But Greg, if you understand what Rob said well enough, ignore what I'm about to say:

1) I think Fav/Scan support would be limited to specific models that handle Fav/Scan the usual way. I think the 15-1994 is the generic example. I'm not sure if something in the RDF makes that clear.

2) I think it SHOULD be based on an extra varient of each protocol that supports it. I don't have any good answer (better than documentation warning the user) to avoid the case that a user creates one upgrade using Fav/Scan and one not using it for the same protocol.

3) RM knows which RDF was selected, so RM should be able to do something important that I assume KM can't: If the upgrade is for use with an extender, don't do any of the Fav/Scan special stuff because that special stuff won't work and a KeyMove will. I think we put something in the RDF to say whether a KeyMove will work on the Fav key. If that data is available then that should control the decision. If a KeyMove will work then a KeyMove is the best choice.

4) Assuming the right varient is selected and Fav is used. I think it boils down to putting the hex command for Fav into a specific place in the fixed data rather than into usual place. RM also should know that external functions can only be KeyMoves so when Fav special support is used it would be nice if the Fav position in the buttons sheet could accept internal functions and reject external.

I expect this would be simpler in RM if a single entry in Protocols.ini could have S3C80 code and fixed data layout twice: With and Without the Fav feature.

But it would be more flexible and simplest for both user and protocols.ini coder if it were two seperate entries in protocols.ini that RM would select between after the normal selection, based on whether the user filled in a function in the Fav position.

But2, it would be simplest for Greg (maybe zero work) and harder for end user and protocols.ini entry writer, if it were two totally unrelated protocols.ini entries with different names. One with fav support and one without. The Fav key OBC would be a special field on the setup sheet and the user must do all the work of changing to a different protocol name and finding and copying that OBC, rather than having it follow as complex automation from assigning a function to the Fav key.

[The Robman]

1) You can tell if a remote has a FAV/SCAN button by the presence of the FavKey item in the [General] section of the RDF.
2) That's the right way to do it in protocol.ini
3) Agreed.
4) Adding the FAV code to the fixed data will break any previously created upgrades, which is why KM hard codes it into the exec code. The drawback of doing it the KM way is that if this happens to be a protocol that used by many different upgrades, the same EFC will be sent whenever the FAV/SCAN button is pressed.

[The Robman]

Another idea would be to just limit the FAV/SCAN support to the device combiner, and make it a fixed data entry. Given that users need to re-copy the generated protocol when they make changes to the DC, this should be somewhat backward compatible.

If you wanted to add broader support for FAV/SCAN, RM could use the existing fav/scan special protocol so that ROM based protocols are also supported.

[Mark Pierson]

The fav/scan special protocol only works with built in protocols and only works with protocols that have 1-byte of variable data. I manually added the logic to many of the hacked protocols that KM supports, plus I added logic in KM that will use a slightly different version of the code depending on the number of bytes of variable data.

Another idea would be to just limit the FAV/SCAN support to the device combiner, and make it a fixed data entry.

This points out a potential problem in KM. The current S3 version of the DC allows upgraded protocols to be specified. Does that come into play regarding the "must be built-in" requirement of the Fav/Scan support?

[The Robman]

This points out a potential problem in KM. The current S3 version of the DC allows upgraded protocols to be specified. Does that come into play regarding the "must be built-in" requirement of the Fav/Scan support?

I don't think this is a problem.

[mtakahar]

This points out a potential problem in KM. The current S3 version of the DC allows upgraded protocols to be specified. Does that come into play regarding the "must be built-in" requirement of the Fav/Scan support?

I don't think this is a problem.

The Fav/Scan support in the DC is just sharing the same mechanism that the DC invokes combined protocols, so 1 byte upgraded protocols should work fine. I think it actually worked when I tested it after making the change.


Hal

[mr_d_p_gumby]

1) You can tell if a remote has a FAV/SCAN button by the presence of the FavKey item in the [General] section of the RDF.

Also, the first parameter in the DevComb item is the register used by the fav/scan process in the remote. If this parameter is blank, then you can't create a fav/scan patch.