JP1 Remotes

I was exploring the way RM handles variants and I'd like to see something different.

In KM, if I choose PID (01 1A) Nec 2Dev Combo in a remote that has Nec PID (01 1A:2) 4Dev Combo, built in KM warns me of a potential problem and allows me to provide an alternate PID.

In RMIR is a little buggy in this scenerio, but when the bug is fixed, I was wondering if you can allow us to change the PID if we want to over ride the built in executor.

Now when I say that its buggy, if I choose 011A when the remote has 011A:2 built in, it adds the 011A protocol, and won't let me to access 011A:2 even if I delete the device that had 011A: I keep getting an error message saying "This remote contains a protocol that is not consisten with the selected protocol and would caus it to malfunction. Please choose a different protocol, and then closes the new device window.

I have uploaded RM/RMIR v2.02 Alpha 11. This incorporates all the suggestions made by Rob in this post. The Protocol Data panel doesn't pop out, but there is a button to Hide/Show the upper panel so that Protocol Data and the other new tabs expand to the full height of the window.

When compared with Alpha 9, on which Rob made his suggestions, there are now three new tabs in Manual Settings, namely Functions, PF Details and PD Details. The latter two are only available when an S3C80 or HCS8 protocol is selected. Functions gives information about the registers and functions (subroutine) used in the protocol. The PF and PD Details tabs give a full breakdown of the significance of the PFn and PDnn values set by the protocol. There are also disassembler buttons to select whether or not to use predefined constants, separately for register and function addresses, and to select how S3C80 work registers are displayed. These options are saved in the Properties file and so are preserved between invocations of RM/RMIR.

The Manual Settings window is re-sizeable, and in addition the vertical divider between the data and disassembler panels is moveable. The individual columns in the disassembler display can also be re-sized. These all return to their defaults on each invocation. These features are not new but haven't been explicitly mentioned earlier.

vickyg2003 wrote:Another question. What is the difference between the Edit Protocol and the New Manual Protocol on the Advanced Menu? I'm unsure and kind of frightened about what to do when an official protocol shows up in the screen. I want to know if I might get myself in trouble with the new option.

Edit protocol enables you to modify an existing Manual Protocol or to create/modify custom code for a built-in protocol. The PID cannot be changed, as it is the identifier for the protocol and the protocol is only being edited, not created. New Manual Protocol creates a new protocol and so you can specify the PID.

If you want to change the PID for an existing protocol, use Copy/Paste to copy the code from Edit Protocol for the processor concerned and then paste it into New Manual Protocol for that same processor. You can then specify your new PID. If you wish, you can then delete the original protocol.

I know this is more complicated than it is in IR.exe, but RM/RMIR ties protocols and device upgrades tightly together in ways that make it impracticable to allow the PID to be changed for existing protocols.

vickyg2003 wrote:I can't find a way to change the PID for an upgrade using a custom protocol. It used to be that we could change the PID on the manual settings page. Now if I open an upgrade with a custom protocol, there is no way to change the PID before pasting it into IR.

Most of the upgrades with a custom protocol have a PID of 01 FF. If a user needs two of these upgrades, they need to be able to change the PID before pasting it into IR.

See my previous reply as to why the PID cannot be changed. There is no need, however, to change the PID before pasting to IR, as it can easily be changed in IR after pasting.

vickyg2003 wrote:I've been checking out the PRIMACY and found that the setting is being saved from one instance to the next. I'd like to submit a request that this default to OBC each time a new instance of RM or RMIR is started.

Preserving the OBC is what you want it to do most of the time. Its only when you are doing protocol development that you want to preserve the HEX/EFC.

Is this a big issue? It's easy enough to restore the default each time RM/RMIR is started - the effort was in preserving it - but on the whole I thought users liked their options preserved. I know it's on the Advanced tab, not the Options tab, but that's because it is an advanced (with a small "A" !) option, not because it's not an option.

vickyg2003 wrote:I was exploring the way RM handles variants and I'd like to see something different.

In KM, if I choose PID (01 1A) Nec 2Dev Combo in a remote that has Nec PID (01 1A:2) 4Dev Combo, built in KM warns me of a potential problem and allows me to provide an alternate PID.

In RMIR is a little buggy in this scenerio, but when the bug is fixed, I was wondering if you can allow us to change the PID if we want to over ride the built in executor.

Now when I say that its buggy, if I choose 011A when the remote has 011A:2 built in, it adds the 011A protocol, and won't let me to access 011A:2 even if I delete the device that had 011A: I keep getting an error message saying "This remote contains a protocol that is not consisten with the selected protocol and would caus it to malfunction. Please choose a different protocol, and then closes the new device window.

I'll look into this.

mathdon wrote:

vickyg2003 wrote:I've been checking out the PRIMACY and found that the setting is being saved from one instance to the next. I'd like to submit a request that this default to OBC each time a new instance of RM or RMIR is started.

Preserving the OBC is what you want it to do most of the time. Its only when you are doing protocol development that you want to preserve the HEX/EFC.

Is this a big issue? It's easy enough to restore the default each time RM/RMIR is started - the effort was in preserving it - but on the whole I thought users liked their options preserved. I know it's on the Advanced tab, not the Options tab, but that's because it is an advanced (with a small "A" !) option, not because it's not an option.

Well I don't think users would want this option preserved because it can lead the normal user into trouble that would be hard to diagnose, but that's the point of posting in the public forum to so that we can hear from other interested parties.

Setting things to preserve HEX is kind of an advanced issue. As far as I know, there are only two reasons to purposely set RM to preserve Hex. 1) To determine after the protocol was written 2) To fix an upgrade that was corrupted.

Most users shouldn't be touching this and if they were exploring, might have set it, and then not encounter any situation that will be effected by this option for months. This settings also changes the calculations when you change from one protocol to another. Normally you want the OBC's to be preserved if you are changing from one protocol to another, not the hex.

Most of the time I want the OBC's preserved, but when doing protocol development I want the HEX preserved. I'm aware enough to know if I have the wrong settings, but I could see this being a problem for the average or new user.

mathdon wrote:I have uploaded RM/RMIR v2.02 Alpha 11. This incorporates all the suggestions made by Rob in this post. The Protocol Data panel doesn't pop out, but there is a button to Hide/Show the upper panel so that Protocol Data and the other new tabs expand to the full height of the window.

Wow, you can't fault the service around here, thanks Graham. I've just started playing with it and it looks great. Here's some feedback...

1) I think the "Hide Upper" button might be better labeled "Expand" and then "Collapse". I didn't know what it meant until I tried it.
2) In "New Manual Protocol" mode, I clicked on "Import Protocol Upgrade" and nothing happened, so I guessed that this was one of those "put it in the clipboard first" buttons, so I cut&pasted a protocol and it worked. As I mentioned to Greg before on some of the other import type buttons in RM, I don't think this style of UI in very intuitive, I think it would be better to give the user a UI to paste the code into. Greg re-used the "Import Raw Upgrade" panel in other places and I think that would be a good idea here too.
3) Could I suggest a different UI for the new "PF Details" tab. I think a UI similar to the "Protocol Data" tab would work better here, where the options are presented as drop-down menus, with the appropriate option pre-selected. I know you're hoping to truly make this an editor in the future, and I think this UI would work better with editor functionality.
4) When you enter the "Manual Settings" panel, I think it would be a good idea to have the first populated processor type pre-selected, so the additional info appears without the user first needing to click the protocol code.

This really is some great stuff that you've added, I really appreciate it.

OK, slightly different topic (and this one might be for Greg). On the Functions tab in RM, I think it would be a good idea to have the Primacy thing be a button at the bottom which toggles between OBC and Hex. It might also be cool to have a blob appear in the column heading of the selected option. I think Vicky uses this feature the most, so maybe she could weigh in on this idea.

Oh yeah, one more thing. Currently, if you want to delete a function from an upgrade, you first have to go to the Buttons tab and find all the buttons that it might be assigned to, delete them, and then return to the Functions tab to delete it. Would it be possible to just let the user delete the function and have RM automatically delete any button assignments? That would really reduce the amount of clicking required to delete a function.

mathdon wrote:

vickyg2003 wrote:I was exploring the way RM handles variants and I'd like to see something different.

In KM, if I choose PID (01 1A) Nec 2Dev Combo in a remote that has Nec PID (01 1A:2) 4Dev Combo, built in KM warns me of a potential problem and allows me to provide an alternate PID.

In RMIR is a little buggy in this scenerio, but when the bug is fixed, I was wondering if you can allow us to change the PID if we want to over ride the built in executor.

Now when I say that its buggy, if I choose 011A when the remote has 011A:2 built in, it adds the 011A protocol, and won't let me to access 011A:2 even if I delete the device that had 011A: I keep getting an error message saying "This remote contains a protocol that is not consisten with the selected protocol and would caus it to malfunction. Please choose a different protocol, and then closes the new device window.

I'll look into this.

Thanks, I'll send you some test files.

vickyg2003 wrote:

mathdon wrote:

vickyg2003 wrote:I was exploring the way RM handles variants and I'd like to see something different.

In KM, if I choose PID (01 1A) Nec 2Dev Combo in a remote that has Nec PID (01 1A:2) 4Dev Combo, built in KM warns me of a potential problem and allows me to provide an alternate PID.

In RMIR is a little buggy in this scenerio, but when the bug is fixed, I was wondering if you can allow us to change the PID if we want to over ride the built in executor.

Now when I say that its buggy, if I choose 011A when the remote has 011A:2 built in, it adds the 011A protocol, and won't let me to access 011A:2 even if I delete the device that had 011A: I keep getting an error message saying "This remote contains a protocol that is not consisten with the selected protocol and would caus it to malfunction. Please choose a different protocol, and then closes the new device window.

I'll look into this.

Thanks, I'll send you some test files.

I've done an initial look into this and can see only one way to handle it. That is to prevent the 011A protocol from being selected when 011A:2 is built in to the remote (generically, of course, not just for this PID). I've implemented that, though not posted it, and it works. If this is a real situation and not just a test, the solution is for 011A to have an Alternate PID specified in protocols.ini. I can see no way of asking the user for an alternate PID and making everything consistent, as unless it is in protocols.ini the protocol can't be identified when a remote containing it is downloaded to RMIR.

Vicky/Graham,
Custom protocols normally appear at the bottom of the list of all available protocols. When an upgrade that contains a custom protocol is deleted, or a custom protocol is deleted from the Protocol tab, it is removed from the raw data of the remote image, but the entry on the protocol list is not removed.

So I presume that the custom protocol is still present within the workings of RM. I speculate that the program needs to do some additional steps to remove it entirely.

ETA: I posted this before seeing Graham's last post. However, I don't understand why a custom protocol can't be deleted, even if it does have the same PID as a built in protocol.

mathdon wrote:I've done an initial look into this and can see only one way to handle it. That is to prevent the 011A protocol from being selected when 011A:2 is built in to the remote (generically, of course, not just for this PID). I've implemented that, though not posted it, and it works. If this is a real situation and not just a test, the solution is for 011A to have an Alternate PID specified in protocols.ini. I can see no way of asking the user for an alternate PID and making everything consistent, as unless it is in protocols.ini the protocol can't be identified when a remote containing it is downloaded to RMIR.

Well lots of times you want to over-ride the protocol, other times the user should be prompted that there is an existing protocol already built in. If I have a Nec 2DEV Combo built in, I might really want and need to add a NEC 4Dev protocol to a remote that has a Nec 2Dev built in.

While I think the ability to identify on download is really cool, I don't care if the protocol can't be identified on a download, It can be called a Manual Setting if it means having more control over what goes into the e2 area. However if someone is creating a device from within RMIR using a variant, couldn't the ALT PID be stored in the RMIR and used in the E2 area. But if the user saves the RDMU file, then the RDMU file could use the official PID name and be shared with the jp1 community.

. I can see no way of asking the user for an alternate PID and making everything consistent, as unless it is in protocols.ini the protocol can't be identified when a remote containing it is downloaded to RMIR.

I didn't understand what you were saying here, but I popped open protocols.ini to get a handle on how many protocols have variants and I came across entries for "AlternatePID="

I'm not sure how this is used in RM.

Is that how RM handles a variant for a remote that has a variant already built in?

vickyg2003 wrote:Is that how RM handles a variant for a remote that has a variant already built in?

yes, to see an example, select remote 15-1994 and then select the "Pioneer MIX" protocol ($007E). MIX is a variant of DVD (DVD is the version that's built into the 15-1994), so when you select MIX you get an upgrade with pid $017F. Now, change the remote to 15-2116 and the protocol upgrade goes away and the pid is $007E once again. Now change the protocol to DVD and you'll get an upgrade with pid $017E.

3FG wrote:ETA: I posted this before seeing Graham's last post. However, I don't understand why a custom protocol can't be deleted, even if it does have the same PID as a built in protocol.

Yes, whenever you delete a custom protocol, you need to restart RMIR or RM. It would be really nice if you could actually delete the entry.

~Rob, thanks for the explanation. Obviously I'm not as well informed as I should be.