JP1 Remotes

johnsfine wrote:1) When you select "upgrades", we would really prefer to get just the USED portion of the upgrade area (as I described earlier). Now it is making a much larger WAV including all the upgrade area.

There are 3 options. Entire image, Upgrades or General, Keymoves. The area it creates is based on the values shown in the RDF. IR already stores those values as the loAddr and HiAddr for the variuos areas. Those are the values passed to the conversion.

2) It was far from obvious to me where the upgrade.wav file had been created. I looked in the directory that had been current when I started IR. I looked in the directory that contained the IR EXE. I looked in the directory that contained my eeprom image. Finally I had Windows search the hard drive and the file was in the directory containing the IRToWav.class file.

IRToWav does not currently have an option to define the name or destination of the WAV file. By defualt it places it in the same directory where the .class file is.

3) I reran it and again it asked for the location of IRToWav.class. There should be some registry setting so it only needs to ask the first time.

Good idea.

4) The "Information" message after it creates the wav file is confusing.

Same message the IRToWav creates if you run it by itself.

fyi - My programming buddy (now a JP1 convert) is creating a DLL for the WAV conversion. The DLL will have the ability to take in a new name and location for the ouput file.

e34m5 wrote: The area it creates is based on the values shown in the RDF. IR already stores those values as the loAddr and HiAddr for the variuos areas. Those are the values passed to the conversion.

I understood what is was doing. I am asking for it to do something else.

IR gets from the RDF the Lo and Hi address of the area that CAN BE USED for upgrades. It then uses part of that area for upgrades, however much is required by the upgrades actually installed.

In the example I tested, IR displays the status line at the bottom of the screen showing the upgrade area has "544 free". As I look at my raw data, I think IR is exactly correct: The used portion of the upgrade area is exactly 544 bytes less than the entire upgrade area.

When I use the nor IR to invoke IRToWav the WAV file contains one byte less than the entire upgrade area. There was an off_by_one bug in some version of IRToWav, and I might still have an old version, so I'm not sure if that explains the missing byte or if your way of specifying the end address is off by one from what IRToWav understands.

Ignoring the off_by_one issue, I'd like the WAV file for upgrades to just include the USED portion of the area, so IR must subtract the free upgrade length (what it displays as 544 decimal in my test case) from the end address.

In theory, the same thing applies to KeyMoves/Macros. IR.EXE computes the free portion of that exactly right, and reducing the end address by that amount would produce a smaller .wav file which contains all the requested content.

I tried running the Settings,KeyMoves,Macros option from IR and it seems to give the same result as the full image.

John:

1 - I made the change for the registry entry.

2 - The problem with the ranges was about one quarter dumb programmer and three quarters not being familiar with the raw data values. I think I have it now....still have a lot to learn about the raw workings of the remotes so I can relate to whar the code is doing..

Try it now

I think it would be wise to add a setting to the RDF's (something like WAVUpgrade=Yes should do it) so that the WAV conversion is ONLY available with one of those remotes selected within IR.

Otherwise, we may have users trying to convert 1994 upgrades, etc.

I was thinking that as well. Currently the only way for me to do that would be to hard code a list of remotes. So the RDF entry is a great idea.

Who owns those RDF's.....

I think Nils is in the process of making other modifications to them as we speak.

e34m5 wrote: 2 - The problem with the ranges was about one quarter dumb programmer and three quarters not being familiar with the raw data values.

You need to reserve a quarter for my having an obsolete version of IRToWav.

e34m5 wrote: Try it now

I did. Your changes eliminated all problems except the off_by_one, which was then eliminated by getting the right version of IRToWav.class

Mark Pierson wrote:I think it would be wise to add a setting to the RDF's (something like WAVUpgrade=Yes should do it) so that the WAV conversion is ONLY available with one of those remotes selected within IR.

Otherwise, we may have users trying to convert 1994 upgrades, etc.

If I understand you correctly, you are really asking for an indicator that states whether the remote has a modem installed, is that correct? If so, maybe Modem=Yes would be a better setting.

A "Modem" is a modulator/demodulator and the remotes only include the demodulator, so that would be a "dem"

I think WAVUpgrade=Yes is a bit clearer, but I don't really care (just typing while I wait for a compile to finish).

The Robman wrote:Modem=Yes

That works, too! I was merely planting the seed...

johnsfine wrote:A "Modem" is a modulator/demodulator and the remotes only include the demodulator, so that would be a "dem"

Ah yes, the "it's not really a modem" line, it sure gets better with age doesn't it. Bottom line, UEI calls it a modem and most (non-techie) people are happy enough to hang with that, so it's OK with me to call it a modem (even though we know it isn't really).

I contacted Nils and he is already making the modifications to the RDF's using WavUpgrade.

As soon as he is done I will release accordingly.

John: Just leave your quarter on the way out...

It's amazing how easy something is when the light bulb goes on

If that can help, I can produce a new version of IRToWav :

• - With a more relevant or no information message
  - Where the location and name of the resulting .wav file can be passed as parameters.
  - Any other improvement you think might make the integration in IR more convenient.

BTW, the structure of the .wav upgrade would allow having several non contiguous memory areas in a single upgrade. All the upgrade I have seen from UIEC contained a single area, so I do not know whether that feature is actually implemented in the 'dem upgradable remotes. If you think that such a feature could be useful, I could try to experiment it.

Alain


P.S. Sorry for the off-by-one bug. I did not expect it to haunt me so long . (I work as a manager in a software company but haven't had the opportunity to code for years. I really hope none of my subordinate engineers knows about this forum ).

Hey Alain,
Can you write in any other languages than Java? One of the goals here is to re-write your wav app as a DLL, is that something you could help with?