 |
JP1 Remotes
|
| View previous topic :: View next topic |
| Author |
Message |
florca
Joined: 04 Oct 2009
Posts: 3
Location: Newbury, UK
|
 Posted: Sat Oct 10, 2009 8:08 pm Post subject: Pause protocol on URC-7555 (HCS08 processor)?? |
 |
|
I'm trying to insert a Pause into a macro, but the Pause (Special) protocol isn't available in the drop-down protocol list for the URC-7555 remote in RM v1.97.
Is this a restriction of the processor type? Is there any way to incorporate a Pause into macros on this type of remote?
I'm very new to all this, have added a bunch of Device Upgrades to the remote and the basics are all working great, but I'm now trying to get a bit more adventurous.
Any pointers welcome...
Phil |
|
| Back to top |
|
 |
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Sun Oct 11, 2009 5:25 pm Post subject: |
|
|
Hi Phil
KM has a pause protocol for the HCS08.
Upgrade Code 0 = 08 00 (Cable/0000) keymap-master Device Upgrade (KM v9.18)
FB 00 01
End
Upgrade Protocol 0 = 01 FB (HCS08) Pause Protocol (Special) (KM v9.18)
20 03 00 00 01 A6 F4 AE 29 CD FF A1 3B 60 F6 81
End
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
| Back to top |
|
|
florca
Joined: 04 Oct 2009
Posts: 3
Location: Newbury, UK
|
| Posted: Mon Oct 12, 2009 5:15 pm Post subject: Pause working but Macro now shifting Modes! |
|
|
Many thanks for that - I now have inserted Pauses into the Macro and they're working fine after using KM for that specific Device / Protocol upgrade.
However...
The Macro now always leaves the Remote in the TV Device Mode, which I'm sure wasn't happening before and doesn't seem to be the case with other Macros without Pauses in them.
To clarify...
I'm trying to force the TV to Mute without a discrete Mute On key. The TV was getting choked up when sending rapid commands without Pauses, hence this thread.
I'm sending in the Macro:
TV
Vol Up
Pause
Vol down
Pause
Mute
I've assigned the Macro to Shift-Mute, and the Pause Protocol is mapped to TV/0000 (although the TV button is bound back to VCR-DVD/1497).
The Pause Key Moves appear in IR within the "Special Protocols" Tab, not in the normal "Key Moves" list - I assume this is correct?
I want the Macro to work from within any Device Mode, leaving the remote in that same mode at the end of the Macro. It now seems to be always leaving the Remote in "TV" Mode. Furthermore, the Macro itself doesn't seem to run at all when initiated from within TV Mode, although it works from all other Modes!
I'm sure I've done something dumb, but can't figure out what.
Brgds
Phil |
|
| Back to top |
|
|
mdavej
Expert
Joined: 08 Oct 2003
Posts: 4501
|
| Posted: Mon Oct 12, 2009 8:15 pm Post subject: |
|
|
Try setting your VPT device to TV on the general tab, TV VPT to On and VPT Status to On. Then delete the TV button from your macro. It should work the way you want then.
I have to admit, I don't understand your macro at all. |
|
| Back to top |
|
|
jetskier
Joined: 09 Dec 2003
Posts: 287
Location: Nevada
|
| Posted: Tue Oct 13, 2009 2:18 pm Post subject: |
|
|
| mdavej wrote: | | I have to admit, I don't understand your macro at all. |
Mute is usually a toggle on 99.9% of devices. I haven't seen a discrete mute myself, but I think his intent is to force a mute on the TV. If it is muted already, it momentarily restores the volume with the quick up/down (unmutes) and the last step mutes again. If it's not muted, it raises the volume then lowers it back and then it's muted. Some devices unmute when you use the volume up/down keys. That guarantees the macro will always end muted.
I've done similar macros to simulate a discrete off for devices that don't have discretes on/offs just toggles. On my whole house A/V system, you can press a source button in a zone and it turns on always. If you immediately send a power toggle, it simulates a discrete off everytime. |
|
| Back to top |
|
|
florca
Joined: 04 Oct 2009
Posts: 3
Location: Newbury, UK
|
| Posted: Wed Oct 14, 2009 4:07 pm Post subject: |
|
|
| Quote: | | but I think his intent is to force a mute on the TV |
Yes, that's exactly what I was trying to do and the logic was as you state.
I've also (I think...) solved the puzzle of why some Macros were forcing the mode to the last Device key "pressed" within the Macro whereas others were leaving the mode at whatever it was set to on entry.
If a Macro is assigned to a shifted key then the Mode seems to stay set to the mode on entry.
If it's assigned to an unshifted key then the mode follows any device keys used within the Macro.
I haven't tested this extensively, but that's the pattern I'm seeing across a number of Macros on this remote.
To finish - I've stopped trying to force a Discrete TV Mute via a Macro. It was actually more usable to leave this as a toggle mapped via Key Moves, so I think I'll suspend trying to "improve" the layout for a while and stop annoying the rest of the family with ever changing button assignments....
Thanks for the help and pointers.
Phil |
|
| Back to top |
|
|
gfb107
Expert
Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC
|
|
| Back to top |
|
|
WagonMaster
Joined: 16 Apr 2009
Posts: 361
|
| Posted: Fri Oct 16, 2009 9:28 am Post subject: |
|
|
I've been meaning to get a 'pause' working (for macros) on my URC-10820/URC-8820 for a while now. Seeing this thread motivated me to try it.
I figured that since the Special Protocol (SP) shown here was for the HCS08 microcontroller, it should work on my URC-10820/-8820 remotes too.
It seems I don't yet understand all the finer points of using SPs, because I struggled for a bit, but I managed to get it working properly on my (extender-free) URC-10820 remote, using a 3-second pause between 2 keystrokes on a macro to prove to myself that it was really pausing.
Being curious, I decided to try another pause protocol that's listed as being specifically for an unextended URC-10820 and which I'd been meaning to test out anyway.
I kept all my working settings and simply replaced the protocol by deleting the working one from the 'IR.exe' "Protocols" page and doing a cut'n'paste of the new protocol. Both protocols share the same ID (0x01FB), of course, so I figured the replacement of one pause protocol with another would be a no-brainer, but I was wrong -- the new pause protocol doesn't pause at all in testing!
What am I missing here? This "broken" pause protocol has been around for over 3 years, so I figure it must be correct, but why won't it work for me?
Decoded, the working pause protocol looks like this:
| Code: |
FF00: 20 03 BRA $FF05
FF02: 00 00 DB $00, $00
FF04: 01 DB $01
FF05: A6 DB $A6
FF06: F4 AND ,X
FF07: AE 29 LDX #$29
FF09: CD FF A1 JSR $FFA1
FF0C: 3B 60 F6 DBNZ $60, $FF05
FF0F: 81 RTS
|
And the non-working pause protocol looks like this:
| Code: |
FF00: 20 04 BRA $FF06
FF02: 00 00 DB $00, $00
FF04: 01 DB $01
FF05: 00 DB $00
FF06: BE 60 LDX $60
FF08: CC 2D 73 JMP $2D73
|
Aside: No matter whether I use tabs or spaces in those 'code' blocks above, the columns just won't come out aligned in my preview!!! They look fine both ways in my editor, but never in the forum preview!
For completeness, I'm including the '.ir' file with the non-working pause protocol.
Ideas? I suspect I'm missing something fundamental here, but I just don't know what.
For bonus points, could someone please explain to me why the working protocol branches to what appears to be a data byte instead of to another instruction? Or is that a mis-decoding? EDIT: I figured this out myself. It's a mis-decoding. See my later post for details.
Bill
Last edited by WagonMaster on Fri Oct 16, 2009 2:39 pm; edited 1 time in total |
|
| Back to top |
|
|
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Fri Oct 16, 2009 11:32 am Post subject: |
|
|
Well this gives you a glimpse into the life of sp and extender developers.
Obviously these pause protocols work on SOME remotes, and they would not be out there at all. They just need testing to point out that there might be errors. Sometimes they 'work' because the data that 'happens' to be in the remote.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
Last edited by vickyg2003 on Fri Oct 16, 2009 8:36 pm; edited 1 time in total |
|
| Back to top |
|
|
WagonMaster
Joined: 16 Apr 2009
Posts: 361
|
| Posted: Fri Oct 16, 2009 12:31 pm Post subject: |
|
|
Vicky, I appreciate the reply, but unfortunately it's not making a lot of sense to me or helping me much. 
| vickyg2003 wrote: | Well this gives you a glimpse into the life of sp and extender developers.
Obviously these pause protocols work on SOME remotes, and they would not be out there at all. They just need testing to point out that there might be errors. Sometimes they 'work' because the data that 'happens' to be in the remote. |
Sorry, not trying to be difficult here, but this makes little sense to me. I'm using the protocol with the exact remote (URC-10820) that it says it was designed for. How could I possibly do any better than that?
Assuming (against my better judgement) that it's not just some screw-up on my part and that the protocol code is actually broken, I cannot imagine that in the over 3 years that this protocol has been out there that I'm the first person to try it, find it broken, and ask about it.  That's why I strongly suspect (naïvely?) that I'm just doing something wrong.
Now if this was some sort of extender issue, I'd definitely see your point. But this (a 'pause' protocol) is about as simple as it gets in my book, as far as Special Protocols go.
| vickyg2003 wrote: | | So the 'working protocol' is jumping to either the next protocol, or a series of nops, or, if the uppper memory was not clean, this could probably reset the remote causing a very long pause. |
Sorry, but I'm not following this at all either... What does "upper memory" have to do with this? The memory we're concerned with (the 'working' protocol shown above) is laid out in its entirety -- all 16 bytes of it.  I see what can only be a "branch" instruction at the first byte of the protocol to what appears to be a data byte, but which I assume is really an instruction, especially since there's a "DBNZ" (which I assume is a "decrement, branch not zero" instruction) near the end of the working protocol which also jumps to that location. The "broken" protocol is typical of what I'd expect -- a branch over the data bytes to the first actual instruction of the protocol.
EDIT: I grabbed the assembly manual for the HCS08 microcontroller and I think I understand the confusion. You thought I was talking about the "JSR $FFA1" (which I now understand is a "Jump to SubRoutine") and I was actually referring to the "BRA $FF05" (i.e. the "branch" instruction). Further analysis of the HCS08 assembly opcodes shows me that it's exactly as I'd assumed -- the "A6" is a mis-decode. It's not a data byte at all but, taken with the next mis-decoded byte ($F4), it appears to be a "LDA $F4" instruction.
(... Now-irrelevant paragraph deleted ...)
Of course, that brings up the issue: What is expected to be in the code at $FFA1 in an un-extended remote? It seems odd to me that this working protocol would actually work if it depends on something in memory that's not specified as part of the Special Protocol!
But really, this last issue (about the odd-looking branch in the working protocol [now solved] and the new issue of what the heck is in memory at that "JSR" address) is more of a curiosity. I'd really like to figure out why a simple pause protocol that's advertised as being for the URC-10820 doesn't seem to work on the URC-10820. I'm still assuming that it's something I've done wrong, which is why I included the '.ir' file, hoping an expert would load it and quickly see what silly thing I'd done (or not done).
Bill |
|
| Back to top |
|
|
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Fri Oct 16, 2009 3:56 pm Post subject: |
|
|
| Quote: | Sorry, not trying to be difficult here, but this makes little sense to me. I'm using the protocol with the exact remote (URC-10820) that it says it was designed for. How could I possibly do any better than that?
What am I missing here? This "broken" pause protocol has been around for over 3 years, so I figure it must be correct, but why won't it work for me?
|
Okay, this was written when IR 7 ruled. Then I came along trying to get this into my extender, and I discovered that my pause protocol was never executed. It turned out that IR was not putting enough bytes into the keymove to get it to actually be a keymove and was actually going somewhere else and doing something alltogether different than the code would indicate. I documented in my extender that the user needed to pad the special keymove. Now IR 8 was written by Graham, who wrote a JP1.2 extender and knows about the 2 byte minimum, so my guess is he fixed IR to force keymoves to be two byte, hence shining a light on the fact that the original 10820 pause was broken. I have since killed my 10820 so I can't test the 10820 to see how the new ir8 enhancements effect the 10820.
| Quote: | | But this (a 'pause' protocol) is about as simple as it gets in my book, as far as Special Protocols go. |
Nothing in this is as easy as you would think.
EDITED FOR BAD COMMENTS ABOUT THE km CODE.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
Last edited by vickyg2003 on Fri Oct 16, 2009 8:20 pm; edited 1 time in total |
|
| Back to top |
|
|
WagonMaster
Joined: 16 Apr 2009
Posts: 361
|
| Posted: Fri Oct 16, 2009 6:32 pm Post subject: |
|
|
OK, that helps clear things up somewhat. Thanks, Vicky. However, I'm still rather confused.
If I interpreted what you said correctly, this means that the old, non-working protocol should be working fine for any 'IR.exe' v8.x user, right? But as we know, it's not working for me. But I need to resolve if it's a mistake on my part, a mistake in the protocol code itself (or the device upgrade associated with it), or a mistake in the utility encoding it ('IR.exe'). Ignoring how the JP1 utilities process/encode the special protocol stuff for a minute, is that old HCS08 protocol code (the one that does "JMP $2D73") to perform a pause even correct? Did it ever work anywhere, for anyone, at any time? I have to assume it did, but I'm puzzled why it wouldn't also work now.
The next quesions concern the pause protocol you posted earlier in the thread, the one that seems to be working correctly for me and Phil....
With one exception (when I was doing some 'IR.exe' tests on Graham's behalf), I've never run KM. Did you get this pause protocol code for KM from a forum file or somehow generate it yourself? Or does KM have some of these protocols "built in"?
And are you saying that this working pause protocol (the one that does "JSR $FFA1") is only working by accident, because of what happens to be at address $FFA1 in my remote and Phil's ("florca's") remote? If so, then I certainly don't think that's a protocol that Greg should be adding to RM's 'protocol.ini' file (which is what I assume he meant he was planning).
An even broader question based on what you've said: if 'IR.exe' v7.x wasn't putting enough bytes into the keymove definition that's associated with invocation of a Special Protocol (SP), then how could anything that used the SP capability (i.e. not just 'pause' SPs) have ever worked back then?
Sorry if I'm missing something here, but I just don't see the light. Should I dump that old non-working pause protocol? If it's broken, can it be fixed and updated? If not, then let's get Binky (the submitter) to delete that file.
I guess what I need to know really boils down to this: Which protocol should I use? It seems like neither of them is ideal -- 1 doesn't work (for reasons that I still am not sure of) and the other works by accident -- is that true?
Do I need to start writing my own pause protocol? I'd really rather not, because (A) I've never done that before and (B) I'm having a hard time believing that someone hasn't dealt with this in an unextended HCS08-based remote long before I came along.
Thanks for your help. Despite the fact that I'm still very confused, I appreciate your inputs.
Bill |
|
| Back to top |
|
|
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Fri Oct 16, 2009 7:32 pm Post subject: |
|
|
| Quote: | | If I interpreted what you said correctly, this means that the old, non-working protocol should be working fine for any 'IR.exe' v8.x user, right? |
No it would SEEM to work for an IR 7 user. In fact it would never execute the code you see. It would be executing some totally different code.
| Quote: | | Ignoring how the JP1 utilities process/encode the special protocol stuff for a minute, is that old HCS08 protocol code (the one that does "JMP $2D73") to perform a pause even correct? |
You CAN'T ignore the jp1 utilities process because its the KEY!!!!! You ARE executing the code now. It jumps to a built in delaying routine, the problem being the delay isn't long enough. When it was tested, the developer 'Thought' it was delaying long enough, but had no clue that their code was never executing and the remote was actually executing some unknown code that gave a nice delay. Now that it is executing you KNOW its not giving you a long enough delay. Hence IT DOESN'T WORK!!!!
| Quote: | | An even broader question based on what you've said: if 'IR.exe' v7.x wasn't putting enough bytes into the keymove definition that's associated with invocation of a Special Protocol (SP), then how could anything that used the SP capability (i.e. not just 'pause' SPs) have ever worked back then? |
This only effected the Pause because this would be the only situation where a special protocol wouldn't have had enough data to qualify as a keymove and jump into protocol execution. (although it could have happened with a 1 key dsm or a 1 key lkp, but who would write one. )
EDIT BRAIN FREEZE. FFA1 IS INFACT THE PROPER JMP. THE KM PROTOCOL IS CORRECT.
| Quote: | | What is expected to be in the code at $FFA1 in an un-extended remote? |
That is the standard delay.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
| Back to top |
|
|
WagonMaster
Joined: 16 Apr 2009
Posts: 361
|
| Posted: Fri Oct 16, 2009 11:21 pm Post subject: |
|
|
OK, let me make sure I understand what you've said....
You're saying that the protocol you posted earlier in this thread is the one to use. It's not working "by accident" at all because the subroutine at $FFA1 is a "standard delay" routine. It's working correctly by design. And Greg should be able to safely use it in the 'protocols.ini' file for RM. Right so far?
As for the old protocol in Binky's file, you're saying it never really worked properly at all, correct? It didn't work in the past because of the bug in 'IR.exe' v7.x keymove generation which inadvertently caused the wrong code to be executed instead of the pause protocol code and, by accident (on account of the execution duration of the erroneous code that was executing), it fooled one into thinking that it was actually working correctly. And it doesn't work even now with 'IR.exe' v8.x because, even though the correct pause protocol code is indeed now executing, it's jumping to a routine at $2D73, which is a delay routine, but one that's too short (duration-wise). If that's all true, then I'd really like to see that file fixed or removed (something I'll bring up with Binky once you confirm my interpretation), since it's clearly causing confusion. It also means that, contrary to my suspicions, I wasn't doing anything wrong all along.  I should have more faith in myself, it seems.
Now, if you'd be so kind, an unanswered repeat from my previous post, merely to satisfy my curiosity: Did you get this KM HCS08-based pause protocol code from a forum file or somehow generate it yourself? Or does KM have some of these protocols "built in" somehow?
Bill |
|
| Back to top |
|
|
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Fri Oct 16, 2009 11:39 pm Post subject: |
|
|
| WagonMaster wrote: | OK, let me make sure I understand what you've said....
You're saying that the protocol you posted earlier in this thread is the one to use. It's not working "by accident" at all because the subroutine at $FFA1 is a "standard delay" routine. It's working correctly by design. And Greg should be able to safely use it in the 'protocols.ini' file for RM. Right so far?
|
Yes
| Quote: |
As for the old protocol in Binky's file, you're saying it never really worked properly at all, correct? It didn't work in the past because of the bug in 'IR.exe' v7.x keymove generation which inadvertently caused the wrong code to be executed instead of the pause protocol code and, by accident (on account of the execution duration of the erroneous code that was executing), it fooled one into thinking that it was actually working correctly. And it doesn't work even now with 'IR.exe' v8.x because, even though the correct pause protocol code is indeed now executing, it's jumping to a routine at $2D73, which is a delay routine, but one that's too short (duration-wise). If that's all true, then I'd really like to see that file fixed or removed (something I'll bring up with Binky once you confirm my interpretation), since it's clearly causing confusion. It also means that, contrary to my suspicions, I wasn't doing anything wrong all along. I should have more faith in myself, it seems. |
The old pause routine creates a much smaller pause than the KM file and its too short to be of much use.
| Quote: | Now, if you'd be so kind, an unanswered repeat from my previous post, merely to satisfy my curiosity: Did you get this KM HCS08-based pause protocol code from a forum file or somehow generate it yourself? Or does KM have some of these protocols "built in" somehow?
Bill |
I opened KM, picked a known JP1.2 remote from the list and then pulled up the Pause protocol from the list.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
