Comcast XMP question for 6131(extender)

[ElizabethD]

Second try of the day, related to above.
I don't know what to make of this.
See another file in diagnosis which might help something in timing perhaps, since keymove lookup takes longer:
https://www.hifi-remote.com/forums/dload ... le_id=8836

Macro results in 6131 are slightly different, and similar to 8910, when instead of sending base upgrade codes I sent keymoves from another device.

In case this is clear as mud:
6776 group: When CBL device is selected, I send CBL codes for channel numbers.
2334 group: When TV device is selected, all unshifted numbers go the CBL (TV/2=CBL/2)
2334 group: When TV device is selected, all shifted numbers got to the TV (TV/shift-2=TV.2)
I wonder if the difference between the first two groups tells something.

[The Robman]

Rob,
I experimented a little, see ICT file
https://www.hifi-remote.com/forums/dload ... le_id=8835
In it you'll see:
6131 standard, Sony12 was just a sanity check for me since I don't know how to do unestended 6131.
6131 standard, unextended works fine. Distinct signal rows for macro sequence 1221.
8910 extender, not ok, similar but not identical structure to 6131 extender. 8910 standard - not tested, I suspect will be fine
6131 extender, not ok, as described above.

If you're saying what I *think* you're saying, the XMP executor works find in a non-extended remote, but doesn't work in an extended remote, is that right?

[ElizabethD]

Yes.
I haven't worked the real gear with unextended, but IRscope shows unextended will be fine and extended is a problem.
Am I right? Who knows. Somebody skilled in reading widget file might know.

[ElizabethD]

Well, I came back to the change I made yesterday. Just inserted 3 bytes up front.
In a 6131ext macro, it repeats single signals, always 3 times just fine, as reported by IRscope.

Upgrade protocol 0 = 01 6C (S3C8+) xmp-with-reps (PB v4.02)
43 8B 71 8B 05 00 00 69 01 67 E6 0D 03 08 0A F0
C0 04 0A C0 60 C0 0E 04 07 C0 88 C0 B6 C8 08 CF
10 09 6B 05 E4 0A 09 B0 0A C0 C5 F6 FF 53 6C 08
E4 0D 0C C6 F8 13 D7 F6 01 58 E4 0C 0D F6 01 0A
FB 02 6A EF 46 08 80 08 C8 7B E0 37 5E 3F 46 08
10 00 C0 56 C0 0F 56 07 F0 44 C0 07 6C 03 F6 FF
68 C6 F8 17 F1 F6 01 58 3C 04 F6 FF 78 F6 FF 78
6E 3A F7 1C 12 8D 01 4C F6 FF 73 F1 C6 C7 26 56
C2 0F 6B 09 C6 F8 00 3E F6 01 58 2A F7 AF
End

So the only remaining issue is to recognize repeated sequences such as "22". In extender I just added a tiny pause between the digits. File:
https://www.hifi-remote.com/forums/dload ... le_id=8837

[mr_d_p_gumby]

If you're saying what I *think* you're saying, the XMP executor works find in a non-extended remote, but doesn't work in an extended remote, is that right?

https://www.hifi-remote.com/forums/viewt ... 3366#p83366
I did warn that the executor aborted the leadout, and that this might be a problem with an extender. However, please note that the JP1 executor behaves the same as the official UEI executor in this respect, so it will have the same problem.

[ElizabethD]

Good news:
The kludge I made worked the equipment perfectly

Mike, I see in the thread you quoted a relevant item for me:
"If the command is in an extender macro where another command follows, it might be necessary to add a short pause after the XMP command. This applies to both the official version and my version."

[The Robman]

If you're saying what I *think* you're saying, the XMP executor works find in a non-extended remote, but doesn't work in an extended remote, is that right?

https://www.hifi-remote.com/forums/viewt ... 3366#p83366
I did warn that the executor aborted the leadout, and that this might be a problem with an extender. However, please note that the JP1 executor behaves the same as the official UEI executor in this respect, so it will have the same problem.

Is the R0D register still populated when the executor is about to stop? If so, could we add some logic in front of the final RET statement that checks whether R0D is set to 2 and if it is, send a PAUSE?

[mr_d_p_gumby]

No, R0D is counted down during execution, so it won't be 2 at the end. The problem is that the leadout is broken up into small chunks making multiple calls to $010A, so as soon as there are no more repeats and no key is down, the executor exits, making the final leadout too short.

[The Robman]

I understand that the normal leadout is broken up (presumably to give a better response time to the user, so they don't have to wait for a long leadout to finish), but once the code is in the final frame section, if we know that it's being used in a macro, we could send a long leadout right there.

Maybe we could store R0D somewhere on the way in and then test the stored value on the way out.

[mr_d_p_gumby]

It might be possible to do that, but it's going to be a fair chunk of code because the structure of the executor is highly optimized for the existing logic. I'm on vacation until after Labor Day, and I don't have my JP1 stuff with me, so I'm just going by memory here. I'm only using bit 7 of W5, so maybe another bit could store the result of the test for initial repeat count being 2. Register R0B is available as well.