IR suggestion: extender version control

[unclemiltie]

Gee, I was thinking about this yesterday.....


as an extender writer, I'd love to have a couple of enhancement that allowed me to sync up the extender software.

First, have IR check extender versions and RDF mismatches. This would require two new lines in the RDF and the extender would have to include a version.

For example, the OCAP extender has its version number stored at $7FE (2 bytes)

The RDF could say something like:

ExtenderVersion = $0204
ExtenderVersionLocation = $1FE


Now when IR fires up on an extended remote it could check the value in the ExtenderVersionLocation and compare it to the ExtenderVersion and tell the user if they are not using the right RDF for the extender version that they have.

It woudl be even more cool if that version number could be used to select the right extender RDF from the ones in the RDF folder (this would require that the RDF's for the extender have version numbers in the file names)


Second, read some of the extender data from the extender itself:

When writing extenders, one of the things that I have to keep track of is where things are and make sure that the extender and the RDF match. If there was an option in the RDF that allowed me to put info on things like where the Shift/Xshift key, start of the advance code area, etc into the hex file and not in the RDF, that would make keeping the two in sync. much easier.

For example, the line in the RDF that says


XShiftKey = $683.7.8.2.0 says that the value for the Xshift key is at $683 in the IR file so if you want to change the key, put the change there.

If we changed this to say

XShiftKey = $F70.7.8.2.0:Indirect

This would say to IR. value of the Xshift key is found at the address that is in $F70. Then during the extender build, I load that value into $F70 and if it moves around since I shifted some code, I don't ever have to go back and fix the RDF.



Both of these features could be optional and the tools would work as they do today. But with the changes, it would make my life a bit easier.


-bill

[The Robman]

For example, the OCAP extender has its version number stored at $7FE (2 bytes)

The RDF could say something like:

ExtenderVersion = $0204
ExtenderVersionLocation = $1FE


Now when IR fires up on an extended remote it could check the value in the ExtenderVersionLocation and compare it to the ExtenderVersion and tell the user if they are not using the right RDF for the extender version that they have.

It would be even more cool if that version number could be used to select the right extender RDF from the ones in the RDF folder (this would require that the RDF's for the extender have version numbers in the file names)

No it wouldn't and you can actually do this today, just declare the data at $01FE as fixed data, then IR will use it to differentiate between RDFs with the same sig.

[unclemiltie]

For example, the OCAP extender has its version number stored at $7FE (2 bytes)

The RDF could say something like:

ExtenderVersion = $0204
ExtenderVersionLocation = $1FE


Now when IR fires up on an extended remote it could check the value in the ExtenderVersionLocation and compare it to the ExtenderVersion and tell the user if they are not using the right RDF for the extender version that they have.

It would be even more cool if that version number could be used to select the right extender RDF from the ones in the RDF folder (this would require that the RDF's for the extender have version numbers in the file names)

No it wouldn't and you can actually do this today, just declare the date at $01FE as fixed data, then IR will use it to differentiate between RDFs with the same sig.

I took this discussion off line so that I could pull a few experiments and see if I could understand what Rob was proposing here.

Rob and I exchanged a few PM's and emails about this yesterday and although his suggestion would solve the last part of my question, in that it could differentiate between RDF's with the same signature, it also introduces a new problem and would not solve the first part.

Details:

If you put fixed data into the RDF for each version, then IR complains every time you start it since the IR file AND the RDF are trying to define data for the same spot. (i.e. the extender has its version built into it an the RDF thinks that it has to overwrite that) Even though this does work to differentiate between two same-name RDF's, I'm not sure that this would be a good user experience.

It also does not help with the version checking that I had talked about in the beginning. What I'm really thinking about here is that you have two pieces of data (1) built into the extender at the location specified in the RDF that is the version of the extender and (2) specified in the RDF as the version of the RDF. IR would then compare these and then make the relevant decision of either reporting that they don't match or trying to find the right version by someother means.

It would also be helpful if there were a way to display the extender version, perhaps under the signature on the raw data tab.


-bill

[The Robman]

I guess I don't know enough about extenders to understand what you're describing. When you say "the IR file AND the RDF are trying to define data for the same spot" what does that mean? Better yet, can you post the test files that you're working with so I can see it in action.

From my POV, an IR file either has data in it or it doesn't. The RDF states that certain addresses contain fixed data. If the data in the IR file matches the fixed data, there's no issue. If it's different, IR will complain and overwrite it.

When you do a download from your remote (or open an IR file), IR will grab the signature and look for matching RDFs. It it finds multiple RDFs with matching signatures, it will try to use the fixed data to differentiate between them.

Take a look at the following zip file:
https://www.hifi-remote.com/forums/dload ... le_id=6115

It contains two copies of the 15-1994 RDF, one that requires fixed data "01" at address $07FE and another that requires fixed data "02" at the same address. It also contains two copies of the FromRob.IR file, each with the correct fixed data at that address.

If you save the RDFs in your RDF folder and temporarily rename the sig portion of the regular RSL6RSL0 RDF, then open either of the new FromRob files, you will see that IR will automatically select the correct RDF.

Isn't that what you were looking for?

[vickyg2003]

I've always changed my extender signature if I needed a new RDF. It may not be practical when in BETA, but it sure would make things a lot easier when an extender goes mainstream. I tried to load someone's IR the other day, and there were 2 different RDF's listed for that extender signature, and NEITHER of them were the right one. Both having different key definitions. I would have thought it would make things a lot easier to have a signature for the OCAP and a signature for the regular Atlas, and when you need to restructure the keys, then it needs a new signature.

Understanding what needs to be in an RDF is already really complicated. A year ago I took a serious look at the RDF's. I wrote a routine for Nils, which checked all the RDF's and image maps looking for conflicts. It turned up a boat load of problems that already exist from the complexity of the RDF's. Making the rules more complex doesn't sound like the best course of action.

[unclemiltie]

OK, so I went back and looked at my experiment and found that I had outsmarted myself.

I put something in to the RDF to allow me to see the version number by using it as a setting, but the way that works is that you specify a default value and that wasn't the same as the fixed data that I had put in.

Rob's suggestion now works and I'll implement it in the Atlas, 15-13x, Comcast DVR JP1.3 and 15-100 extender as I roll out new versions.

This will allow you to have multiple RDF's for the different versions in your RDF directory and IR will pick the right one based on the version number that is built into the extender at build time. It will also complain when the version numbers don't match although the error isn't anything like "version mismatch" but comlains of fixed data mismatch. I can deal with that as part of the Readme.

Thanks Rob!