IR.exe v8.00 Beta now posted

[The Robman]

So what we need is the ability to specify the default setup codes for each device button in the RDF, right?

[mr_d_p_gumby]

They REALLY don't like it when the setup codes aren't present in the remote (in the ROM area or as an upgrade) and will do all kind of bad things (depending on remote, erasing the advance code area, erasing the upgrades, and other mean stuff)

Even the older EEPROM based remotes could sometimes be rather picky of some areas of the EEPROM. However, their response to not liking something was generally to ignore the entire EEPROM. It sounds as if UEI took a different approach with the flash based remotes.

[The Robman]

As I think we're headed towards making the RDFs create a "new" image that almost exactly replicates a virgin image, I think it might be a good idea to sneak in something so that we can tell when an IR file was created this way, just to help us diagnose possible problems.

I'm thinking that whenever someone uses the New > Select method of creating an IR file, IR could put a little signature of sorts near the end of the IR file, like maybe a couple of bytes with the value $1234.

[unclemiltie]

So what we need is the ability to specify the default setup codes for each device button in the RDF, right?

The setup codes are not the only thing, there is some other stuff. For example, the Comcast DVR has some things in there that I don't quite understand but if one of them is not $0F the remote uses the value in there for the device for all macros. Then if the device is greater than $03 the remote goes to never-never land.

[unclemiltie]

As I think we're headed towards making the RDFs create a "new" image that almost exactly replicates a virgin image, I think it might be a good idea to sneak in something so that we can tell when an IR file was created this way, just to help us diagnose possible problems.

I'm thinking that whenever someone uses the New > Select method of creating an IR file, IR could put a little signature of sorts near the end of the IR file, like maybe a couple of bytes with the value $1234.

I agree that we should do some kind of marking of the file, good idea. Maybe it could be kept in the [notes] section and viewed with an advanced pulldown like view->details or something like that.

Another thought: Could we keep the data for an new->remote in a separate file that is a "hex" file like what we extender writers do for extinstall. The RDF could have an entry that gives the file name or some way to identify that a new->remote can be done.

[mathdon]

Mike wrote:

Even the older EEPROM based remotes could sometimes be rather picky of some areas of the EEPROM. However, their response to not liking something was generally to ignore the entire EEPROM. It sounds as if UEI took a different approach with the flash based remotes.

It isn't the flash based remotes that are different, it's the "soft" device ones - only the URC-7780/81 at present, as far as I am aware. These too are very picky, and will do an automatic reset if a device setup code isn't found in either ROM or upgrade area. But it uses $FFFF to indicate the absence of a device in that slot - a concept not present in remotes with "hard" device selection buttons.

Bill wrote:

The setup codes are not the only thing, there is some other stuff. For example, the Comcast DVR has some things in there that I don't quite understand but if one of them is not $0F the remote uses the value in there for the device for all macros. Then if the device is greater than $03 the remote goes to never-never land.

It is this other stuff that made me introduce "read-only settings". You don't even need to know what the byte does, just what its value in a 981 reset should be. Give such settings innocuous names such as Aux1, Aux2,... - it really doesn't matter. If the user can't change the value, he/she doesn't need to know what it is for. But I think it is helpful for diagnosis, experiment, etc to have such values displayed. (I suppose I could even create "invisible" settings that are used in initialization but are not displayed, if that was felt to be better.)

I don't like Bill's idea of saving an '.ir' file created from an RDF with some prefix other than '.ir'. It defeats the point. The intention is that the RDF creates a 'real' 981 Reset image that can either be saved as such, or be the starting point for a complete setup for the remote. I much prefer some sort of marker in the file, but when would that marker be removed, if at all, as a complete setup is developed from this 981 image? Perhaps the thing to do would be to have some entry in the RDF that says whether this RDF does, or does not, create a 981 Reset image, and if it does then a marker goes into all .ir files saved when that RDF is used.

On default device setup codes, how would it be if the default was put as a further optional parameter for entries in the [DeviceButtons] section? That seems an obvious place, but would it upset RM? Or perhaps RM only reads the [DeviceTypes] section?

Graham

[The Robman]

I agree, we don't need a separate file, we need to make the RDFs able to create good virgin images. The marker that I suggested would only be added to images that were created using the New > Select option as it would tell us how the IR file was initially created. There would be no need for IR to ever get rid of the marker, and if it gets overlaid with valid data (eg, learned signals or upgrades) so be it. In fact, now that I think of it, rather than using a hard code marker, maybe we could make it a date. We could fit a date into 3 bytes (eg, $02 07 09).

If someone has problems with an IR file, the marker would tell us that it was created using IR.exe and the date would tell us how recently. So, if it's an old file, the problem is probably something else, but if it's new, then maybe there's a byte of data that should have been set but IR.exe didn't set it.

I like the idea of display only data too.

Another thing that I've been asking for earlier but I don't think ever got implemented is a different type of fixed data. IR uses the current fixed data to differentiate between similar RDFs and if there's only 1 matching RDF, it will tell the user that there's a fixed data mis-match and ask them if they want to replace the current data with the specified fixed data. There are occasions where I want to specify fixed data that isn't used to select the RDF and I don't want the user notified about any mis-matches.

Actually, now that I think about this, maybe we could also use a combination of the two items above. Maybe we can specify some display only data where we specify a range of valid values, and if the data found is different to the specified range, IR would change the data to the first data item in the range.

Maybe we could have an "advanced" setting that specifies whether the user needs to be notified when IR makes changes in either of the above two cases. Experts could opt to be notified whereas regular users would not. The problem with these fixed data notifications is that they scare many users and they don't know whether they should accept the change or not, and about 50% of the time they don't accept the change. For normal fixed data, I'm happy to keep it that way (because they tend to post here with questions about it) but we should also have the option of having data that we understand better changed without notification.

[unclemiltie]

my only thought about a separate file was for extender code. I'd love to have a new->remote be able to generate a new, valid, "virgin" extended remote as well as an unextended remote.

Given the amount of data that would need to go into an extender, it seems like putting all of that into the RDF would confuse things.

[The Robman]

Personally, I've always wondered why the extender code wasn't built into the RDF. After all, there's no reason why you would be using the extender RDF if you don't have the extender loaded, and the RDF has the ability to do it.

You could do it today using fixed data, but Graham could possibly provide a cleaner way to add it to the RDF.

[mr_d_p_gumby]

Another thing that I've been asking for earlier but I don't think ever got implemented is a different type of fixed data. IR uses the current fixed data to differentiate between similar RDFs and if there's only 1 matching RDF, it will tell the user that there's a fixed data mis-match and ask them if they want to replace the current data with the specified fixed data. There are occasions where I want to specify fixed data that isn't used to select the RDF and I don't want the user notified about any mis-matches.

That's exactly what the [AutoSet] section is for. It works the same as [FixedData] except it's not used in RDF matching, and it will force the values without notifying the user.

[The Robman]

thanks

[unclemiltie]

Rob/Graham

For the Samsung processor remotes, the hex file that is output from the assembler is the ideal way of doing this. There are two reasons:

First, this is the file that people who are installing the extender into their existing configurations will use so it's distributed as part of the extender distribution anyway.

Second, it's generated automatically by the assembler so there is no extra work necessary by the extender writer. (yes, I know that the HS08 assembler doesn't do this, but maybe we can fix that?)

The format addrtext like this:

Code: Select all

600:  33 41 30 30 33 41 30 30
800:  4B 4E 53 00 00 00 00
60A:  07 55 10 2F 21 F7
610:  33 FF 20 3C
810:  FF 0B 0C 0D 0E 10 37 0F 2F FF 30 06 07 18 08 22
820:  15 16 17 19 1A 1B 1C 1D 1E 1F FF 28 29 2A 2B 2C
830:  2D 2E 3F 23 24 31 32 21 13 14 FF 08 10 08 11 3D
840:  EA 08 1A 3E 0F 08 2B
61B:  2D 11 04 17 08
620:  00 00 FF
1200:  CA 11 04 17 08 01 01 09 80 06 D0 CF CE CD CC D1
1210:  01 80 06 D7 D6 D5 D4 D3 D8 0A 80 04 DE DC DA DF
1220:  11 80 04 E5 E3 E2 E6 12 80 05 EC EA E9 E8 ED FF
A02:  0A 3C 0A 56 80 00 01
A18:  00 00 01 8D 08 47

The other thing that I've done with the extender that I've written is that I've added some comments that extinstall will copy over when installing the extender that are identical to the comments kept by IR. These tell the user what the installed devices and protocols are (ToadTog, etc) It would be nice to keep those as well

What if we did this:

1: the RDF and the HEX file get put into the RDF directory that IR looks at
2: the RDF gets an entry that says something like

Code: Select all

[Extender]
Datafile = 3A33.HEX
maybe some other stuff

In reality, what IR can then do is (1) create a new empty file, using the default value that the RDF specifices, and (2) run Extinstall (which it can already do) with the file mentioned in the [extender] section. Extinstall already does the heavy lifting to determine which files have valid data in them. The amount of "new" work that IR would need to do here would be minimal.

Come to think of it, this same mechanism could be done with the default remote as well, a much smaller HEX file could be created with the data that goes in by default.

I'm not sure that our previous discussion about overlapping data applies here since we are talking about doing a "new->remote" so the user hasn't changed anything yet. Where we run into problems is when installing extenders that have overlapping data. here we need to have a mechanism for (probably Extinstall) to know that there is some data that it should install if the user hasn't already put something there. The way it works now is that if the "extender" file has a piece of data in it it uses it, regardless of the state of the users IR file.

[The Robman]

But why wouldn't you want all that to be built into the RDF as some sort of fixed data? That way, if the user's happy to start from scratch, all they have to do is select the RDF in IR.exe and load it, then they're good to go. No need to run any "install" programs or anything. I don't see the need to have separate "hex" files stored in the RDF folder.

[unclemiltie]

Rob

I didn't say that the user needed to run an install program, what I was thinking was that when they did a new-remote, IR ran it for them behind the scenes without asking.

That way (1) the extender writers don't have to distribute the extender in two places (inside the extended RDF and as the hex for the extinstall users) where we can and will introduce errors and (2) we're distributing the output of something that is generated automatically and (3) Ir doesn't have to do anything other than automatically call something that it already knows how to call today.

The other thing is that the hex files are reasonably large and we'll have to jam all of that into the RDF. Take a look at the HEX file for the Atlas extender, do we really want to stuff that much data into the RDF?

But I'm not the guy who has to implement all of this in IR so I can do whatever mathdon decides to do. All I ask is that if we push this into the RDF that we allow it to be the last section in the RDF so that I can bolt it on the end automatically when I build the extenders.

PS

it would also be cool if we were to put in the unextended RDF a tag that told it where to get the extender.

Code: Select all

[extender]
extenderfile = 3A33.hex

that way we could tell people to put the hex file into the same directory as the RDF and the "merge using extinstall" would go do it without having to ask for a file name. (if it doesn't find it or if that tag isn't in the RDF, it would continue to ask)

[mathdon]

I'll digest later all the posts of the last few hours. I just want to point out now that the read-only settings I mentioned are already implemented in the v8.00 beta. They just go at the end of the [Settings] section - they are not distinguished in that section from any other settings. But if you put StartReadOnlySettings=12 (say) in the [General] section then the 12th and subsequent settings become read-only. Try it and see!

Graham