JP1 Remotes

jon_armstrong wrote:KM actually tweaks a couple of bytes in the Protocol itself and I don't think we can do that in protocols.ini

Sounds like we need to add another translator type parameter. Maybe we'll call it ProtocolTranslator? It will translate device parms and store them in the protocol hex.

gfb107 wrote:Sounds like we need to add another translator type parameter. Maybe we'll call it ProtocolTranslator? It will translate device parms and store them in the protocol hex.

That would probably give us some greater flexibility. Some thoughts for your consideration and hopefully, John will comment too.

The index should probably be set to something like:

0=Code.S3C80
1=Code.740
2=Code.6805-C9
3=Code.6805-RC16/18

That way if we add an additional protocol the index isn't based on the order that they occur in the file but the protocol variant.

Otherwise use the same concept that whatever is in the protocol is the default and if something is changed from the default, then to set it to show a protocol upgrade required.

Also should we change to the term "repeats" rather than duration?

Finally, I assume (and will no doubt show my ignorance) that the reason that the Device Combiner can set this for the various protocols, is that the duration/repeats is usually in the same place in the hex sequence. If so, should we make that a regular feature on the setup page (and read the default value) and explain in the notes that if you change it you will need to add a protocol upgrade.

Or should we add an advanced tab to allow the user to set repeats and adjust the gap between frames. Those seem to be the most common tweaks. I know there are all sorts of exceptions in complex protocols, but I'm trying to think ahead.

I can't think of a good way to deal with this issue cleanly across CPU types. I'm very uncomfortable with the idea I think you're suggesting of multiplying protocol varients in cases where there may be no difference in other behavior between two CPU implementations of what we have been calling the same protocol varient.

It sounds like you think the Device combiner modifies the target protocol as it gets loaded. Even if there were a simple generic modificication that would act as duration control, the device combiner can't work that way because it can't coexist with the target protocol in ram.

I don't fully understand repeat behavior, but mostly it is controlled by the value of a specific register. Normally that register is controlled by built-in behavior of the remote invoked before what it thinks is the protocol gets loaded. For typical extenders, that is after the extender releases control (so it's tricky for an extender to manage that register value).

The last piece of code to change that register wins and earlier changes are overwritten.

Some protocols include an instruction to change that register and they're necessarily last so they win.

The device combiner includes an instruction to change that same register and it happens after the built-in code and before the real protocol, so it wins for all common protocols that don't try to set that register value.

One of the PB repeat options adds the instruction to a protocol to set that register. Once the instruction is in the protocol, it would be easy to patch the hex to change the value. It would be a harder patch to add thatinstruction to a protocol that didn't already have it.

John is correct that it would be difficult to deal with all CPU types. The S3C80 and 6805-RC16/18 both share the same techniques for handling repeats, and will work by modifying the appropriate register. But the 740 & 6805-C9 have no such register to manipulate. If you look at what PB does for these, you'll see it adds code to make repeated calls to the IR engine for repeats. This would mean inserting a 2-byte or 3-byte hex sequence for each repeat required (in the simplest case).

That aside, I think your idea would be a really nice feature. I think that you'd have to have some way of enabling it for specific protocols only, and within a given protocol, to enable it for specific CPU types. The actual modification to the protocol hex would have to be detailed for each CPU type. For example, the S3C80 & 6805-RC16/18 would both work by changing the value of one byte, but the location of the byte in the hex code would be different. For the other CPU types, it would need to know where to insert the extra bytes, and what the value of those bytes should be. Since these bytes might refer to a vector location, the modification to the protocol hex would have to be done before the vector translation process.

John, I understand your concern about generalizing the concept as a feature (ignoring the dubious feasibility). So who had the stupid idea to try that

What about Greg's initial suggestion of adding a Protocol Translator? $0143 in KM has a field on the setup tab for duration and changing that field adjusts two hex bytes in the protocol directly.

That way we could create the RCA Combo (w/Duration) and call it $0143 like KM Master?

The thing about this protocol is that it is unusual in the way the device parameter is handled. All other protocols store device parameters in either the fixed data or the command data.

The question is this: Does it even make sense to add a generic way of handling this since it is not normal? Maybe we should just treat this as a special case, and not enhance the protocols.ini format to handle it.

Having said that, maybe this is something I am going to have to deal with anyway when I add some of the other missing features (e.g. FAV/SCAN support?).

gfb107 wrote:The thing about this protocol is that it is unusual in the way the device parameter is handled.

This shouldn't make any difference to a truly generic technique. It would simply change a byte or two, and won't really care where that byte is located or why.

gfb107 wrote:All other protocols store device parameters in either the fixed data or the command data.

I would revise that statement to say that most other simple protocols do it that way, where a simple protocol is defined as one where the executor is composed of only a parameter list and a call to the IR engine.

gfb107 wrote:The question is this: Does it even make sense to add a generic way of handling this since it is not normal? Maybe we should just treat this as a special case, and not enhance the protocols.ini format to handle it.

I think it's "normal" in enough cases that it would be worthwhile to explore.

gfb107 wrote:Having said that, maybe this is something I am going to have to deal with anyway when I add some of the other missing features (e.g. FAV/SCAN support?).

That's possible. I think the basic approach might lend itself to any sort of patch that needed to be applied to a protocol. The trick, of course, is to make the technique generic enough.

If you created the Protocol Translator, I think this would be the protocols.ini entry. I think you will need a translator for each processor type.

In the case of $0143 the 30th byte varies between 0 to 7F (I'm not sure you an actually get 127 repeats but that's the range of values you can get from KM). So 8*30=240 would be the offset to the top bit of the 30th byte and 241 would be the first bit in that byte that varies:

[RCA Combo (w/Duration)]
PID=01 43
CmdTranslator=Translator(0,4,0) Translator(1,8,8)
CmdParms=Device=0:4,OBC=0
Notes=S3C8 hacked combo
DevParms=Duration:7:5
S3C80 Protocol Translator=TranslatorFromDev(0,7,241)
DefaultCmd=0f 00
CmdIndex=1
Code.S3C80=28 60 02 8B 12 95 45 04 08 00 FA 03 D4 00 FA 01 E0 0F 8C 07 D0 07 BC 20 10 00 11 E6 0D 00 8D 01 46

Now having said all that, it seems like we really should modify $0143 to pick off the bottom 4-bits of the first variable byte and allow a variable duration by command between 0-15.

I've been promising Rob I would try to improve my meager assembly language skills and that seems like a project even I could do, if that makes sense.

How about This would work just like the DeviceTranslator, except it would use the code as the target instead of the fixed data.

Sounds like an even better idea to me.