mathdon wrote:A few points for use of IRToWav with HCS08 remotes that are not covered in the ReadMe.
If you use the command line interface of IRToExe with HCS08 remotes, you need to put a "+" sign at the end of the Signature. If you are creating a WAV file from the Upgrade Area, you also need to include the preceding checksum. As an example, to create a WAV file of the whole upgrade area of the URC-7781 Digital 12 (area is F402-F7FF) from an image file MyDigital12.txt you would need
IR2W MyDigital12.txt 1131+ F400 F7FF
Note that the image file must be saved from IR.exe as a .txt file, not a .ir file. The signature of the remote is 11311131 and the two bytes at F400, F401 contain the checksum for the upgrade area.
When you use IRToWav from IR.exe, versions of IR.exe prior to (the forthcoming) version 8.00 do not include the checksum when you create a WAV file for an HCS08 remote from the upgrade area and so they will not load into the remote. This is corrected in version 8.00.
A note for users of IRToWav with MS Vista, learned by bitter experience!
Do NOT put the IRToWav files into a folder that requires Administrator privileges for copying into or creating files. If you do so, the command line version will work but if you use it from IR.exe you will get an error message saying that it cannot create the WAV file - even though you may be creating the WAV file in a normal folder. The file that IR.exe cannot create is a temporary file in the same folder as your IRToWav program files, but it can take some time to sort out what is happening!
To be tidy, I have a folder "JP1" in "C:\Program Files" and each JP1 application in a subfolder of this one. They all worked fine - except IRToWav.
A clarification.
My earlier comment referred to HCS08 remotes as if all HCS08 remotes had a checksum before the upgrade area. Not so, it's only certain ones - the URC-7780 and URC-7781 being two of them. IR.exe 8.00 "and"s the start address of the upgrade area with $FFFC, so converting the start area of $F002 to $F000 for the URC-7780 to include the checksum, but leaving $F000 unchanged for the URC-8820, say, which has no checksum for this area.
Last edited by The Robman on Tue Mar 03, 2009 1:19 pm, edited 1 time in total.
Rob www.hifi-remote.com Please don't PM me with remote questions, post them in the forums so all the experts can help!
The URC-7780 and URC-7781 certainly are, but I can't speak personally for any others. The latest Chart of Remotes also lists various versions of the OFA Kameleon as being HCS08 and modem upgradable. But all of these seems to be Europe only.
The more I hear, the more I think the 7780 and 7781 are among the most versatile JP1 remotes around!
A word of advice that I've just learned by experience. As described above, an upgrade WAV file for an HCS08 remote needs to include the checksum for the upgrade area. IR 8.00 Beta 5 and later does do this, but it is still easy to get the checksum wrong. The WAV file only includes the valid data from the upgrade area but IR calculates the checksum for the entire upgrade area. So if there is any junk data after the valid data, the checksum will be wrong.
To ensure this does not happen, use Advanced/Clean Upper Memory from the menu bar before you export the WAV file.
________________
Rob, I've thought about that and am a bit concerned about putting a value into the WAV file that is different from that the user can see in Raw Data. I think it better that the user can see what goes into the file. I would prefer to make the WAV export process (for HCS08 remotes only) display a confirmation message that tells the user to use Advanced/Clean Upper Memory before exporting. Is that OK?
________________
I dunno, I think that's making the process un-necessarily confusing. Most people who are going to be using the WAV export feature are not even going to be complete JP1 users as in all likelyhood, they probably don't even have a JP1 cable. And they're not going to care what the hex code data looks like. They just want to create a WAV file that works.
And if you already have all the info you need to create a working WAV file, why would you want to create one that you know won't work, as it'll just lead to questions here on the forum.
Therefore, my recommendation is still to have IR put the correct checksum in the WAV file, even if it's a different value than the checksum that's in the IR file.
Alternatively, if you really want to keep them in sync, you could clean up the garbage data yourself in IR.
Rob www.hifi-remote.com Please don't PM me with remote questions, post them in the forums so all the experts can help!
Point taken. It is far easier to clean up the garbage data than to insert a checksum in the WAV file different from that in the Raw Data buffer, so I've made the export process clean the upgrade data area (but not other areas).
When you exit IR you will then get a message that says "The data has changed. Do you want to save the changes?" To prevent the user being puzzled as to what has changed, I've put a confirmation message into the export process that says "To make sure that the WAV file will load successfully, the data in the upgrade area will first be cleaned to remove any garbage data that follows the valid upgrades. Proceed?"
Question, can't the WAV files send out an extender? I've completely destroyed several extenders when I tried to do a clean upper memory when using a jP1 cable, so I'm a little leery about having automatic clear upper memory commands. I'm clueless about these wav upgrades. I should breakout my 8910's and try out this feature in my quest to be come well versed in all things JP1, but there is just too much to learn and too little time!
Hi, Vicky. I too have discovered that Clean Upper Memory destroys extenders, and have wondered (but not yet found out) whether I can do anything to stop that. That's why the WAV upgrade export only cleans out the Upgrade area. I don't think extenders live in the upgrade area (if an extender is being used, this is of course the upgrade area of the extender, even if different from that of the unextended remote). But your issue is one of the reasons for my first reply to Rob, to inform rather than actually take action. I think by cleaning only the upgrade area I am avoiding such problems.
Incidentally, this only happens if you select "Export to WAV - Upgrades". No other HCS08 area that can be exported has its own checksum, and if you export the entire E2 area then all checksums will be included in any case.
Do please say if your experience suggests otherwise.
_________________
I wasn't thinking about extenders. I've long been a proponent of have the extender code be "fixed data" in the RDFs, but that's a different story.
Let's get back to the question of different checksums. Is the issue a psycological one (ie, you don't like the idea of having different checksums) or it a physical one (ie, you don't know how to create different checksums)? Because if it's the former, I don't have a problem with it, so if you know how to do it, I think you should. If it's the later, maybe if you post why you think it's difficult, someone here might have a suggestion.
Rob www.hifi-remote.com Please don't PM me with remote questions, post them in the forums so all the experts can help!
(1) I think the user should be able to see what goes into the WAV file if he/she wishes. Suppose UEI changes things again. It would be much harder to find if you can't see what has gone into the file. Those who don't wish to see the data will not look at the Raw Data page. Those who do should be able to see it on that page.
(2) I do know how to put a different checksum into the WAV file than that in the Raw Data, but it is a lot more trouble than cleaning the data in the way I have done and I think it is the wrong thing to do.
(3) You wrote
Alternatively, if you really want to keep them in sync, you could clean up the garbage data yourself in IR.
I do so wish, and I have done that. The user gets to confirm that they are happy with that. You want it done without confirmation, or what?
I know I said that, but after giving it more thought I've changed my mind. The data in the WAV file and the data in the IR file are totally separate entities in my view, so I don't see any need to change the data in IR in order to conform to the requirements of the WAV file. I certainly wouldn't want IR changing the data without the user's consent, and asking for consent gives them one more step to click it away.
So my vote is 100% against having IR change the data. I think IR should calculate a separate checksum for the WAV file.
Rob www.hifi-remote.com Please don't PM me with remote questions, post them in the forums so all the experts can help!
As it is today, IRToWAV is a relatively stupid program. It takes a chunk of upgrade memory and converts it to the wav protocol. It has no knowledge whether the chunk is from the upgrade, the settings, the key move/macro areas or for an entire image. All this knowledge is in IR.
The wav file itself is made of smaller blocks, each having its own checksum that IRToWAV knows how to and does compute, but this is a protocol level checksum, not an application level checksum, as the one we are discussing here.
Possible solutions :
1) IR is modified to pass its knowledge of the checksum to IRToWAV as parameter.
2) IRToWav is made more clever in order to analyse the signature and memory range to find out whether some special action, like computing a checksum, is required. This would imply adding a RDF file parser and duplicating some of the logic already present in IR.
1) Would be possible without to much effort, but as IR would have to be modified anyway, it would be as well to have IR directly generating a "legal" chunk.
2) Would imply a lot of work and code duplication from IR to solve a specific problem.
I would agree with Rob as not to silently change the data in IR, and computing and outputing the correct checksum on the fly during wav file generation. Possibly, the data change in IR could be made as an advanced option, but I am not sure what the default for this option should be.