|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
Posted: Fri Sep 23, 2005 1:01 pm Post subject: |
|
|
IF the only use for MaxCombinedUpgradeLength is for binary upgrades, and we want it to include the entire binary upgrade, I think we should call it MaxBinaryUpgradeLength.
Would it be OK if RM just computes the length of the upgrade without the setup code, and we just adjust the value in the RDF to compensate for it? Or we could add another variable to the RDF to tell RM that the setup code must be included in the length. _________________ -- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) |
|
Back to top |
|
|
mr_d_p_gumby Expert
Joined: 03 Aug 2003 Posts: 1370 Location: Newbury Park, CA |
Posted: Fri Sep 23, 2005 1:44 pm Post subject: |
|
|
gfb107 wrote: | I'm not clear on whether or not the MaxLength includes the 2 bytes in the upgrade header. For a device upgrade, that's the device type, setup code and "Pid > 255", and for a protocol upgrade it's the PID. | For the existing MaxProtocolLength entries, the PID is not included in the size. It's just the actual number of bytes that are part of the protocol executor itself. _________________ Mike England |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21239 Location: Chicago, IL |
Posted: Fri Sep 23, 2005 4:54 pm Post subject: |
|
|
I would recommend keeping the MaxCombinedUpgradeLength as is, then we can use it for other purposes too when needed. For example, the device specific upgrades for the old Producer 8s use a similar format and while I don't know what limit there is to the size, I'm sure there is one. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21239 Location: Chicago, IL |
Posted: Sun Oct 09, 2005 3:21 pm Post subject: |
|
|
Greg, would you have any interest in expanding the binary capabilities of RM to also format "OBJ" files for the old 2000/3000 series ReplayTV units?
It's not as easy to add an OBJ file to your Replay as it is to add a bin file to your Slingbox, but the question just surfaced over at AVS so I thought I'd ask. If you're willing to do the RM part, I'll create the RDF.
The format of the binary file is very slightly different to the Slingbox format (probably because this is a much older UEI chip).
bytes function
0-0: offset of protocol code (zero if no protocol upgrade needed)
1-2: setup code in hex format
3+: standard JP1 device upgrade
??: optional protocol upgrade - S3C8(old)
The files have names like "S1005_OBJ" with no suffix. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
Posted: Mon Oct 10, 2005 6:10 pm Post subject: |
|
|
Seems pretty easy to do.
I assume you'll want to be able to read these files as well as write them.
I wonder what you think of this idea. Instead of having Advanced menu items for reading/writing special file formats, I thought it might be reasonable to use the standard File -> Open and File -> Save As... dialogs. If the remotes support formats other that .rmdu and .txt, I would add additional file types to the "Files of Type" drop-down.
Actually, I would always allow reading special format files, but only allow writing them if the selected RDF is compatible with them. _________________ -- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21239 Location: Chicago, IL |
Posted: Mon Oct 10, 2005 6:23 pm Post subject: |
|
|
Sure, why not. And yes, I'm totally cool with the File --> Open idea. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21239 Location: Chicago, IL |
Posted: Mon Oct 17, 2005 9:25 am Post subject: |
|
|
The Robman wrote: | There's only one hex value that doesn't work using those formulas (a JU value of "7D" converts to "4E" rather than "CE"). |
Hey Greg, my PL box finally arrived and I have soldered in a 6-pin connector and have been able to get the complete picture as far as this encryption goes.
The only other value that doesn't follow the main formula is the flipside to the exception that we already spotted. In other words...
7D converts to 4E rather than CE, and
7F converts to CE rather than 4E.
Of course, we should have thought of that one right from the beginning, duh! But I can confirm that all the other values followed the formula.
However, I have a bug report for RM v1.37, the "export binary" function isn't working. It goes through all the steps to save the bin file, it just doesn't actually do it. I had to switch back to 1.35, which just happened to be the last version that I had set up in a seperate folder, over the weekend to do my testing. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21239 Location: Chicago, IL |
Posted: Sat Nov 05, 2005 7:20 pm Post subject: |
|
|
Hey Greg,
I wonder if there's a way to improve the Import function a bit. If you take a look at this thread over in the Slingbox communnity, someone tried importing a binary upgrade and then re-saving it just to see if the process works, and with the file he happened to chose, it doesn't.
He chose to import the S0775_JU.bin file which just happens to use the 5-1 version of the Dish Network protocol, but RM substituted the 2-1 version and the resulting upgrade doesn't work.
The 5-1 version is supported by protocols.ini (it's variant 5) so I wonder if there's a way for RM to try and sync up the version being used in the upgrade file with the correct version from protocols.ini? In cases like this where the protocol code is supplied as part of the upgrade, you could compare the code to that stored in protocols.ini perhaps? _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
Posted: Sat Nov 05, 2005 9:51 pm Post subject: |
|
|
Rob,
I don't know if I'm looking at the wrong file, but my copy of S0775_ju.bin doesn't include the protocol code.
This means RM doesn't have enough information to pick the best match.
It can only pick the protocol by trying each one with a matching PID, until it finds one that generates fixed data from the device parms it imports from that fixed data.
Unfortunately, when there is no protocol code, RM doesn't even know the actual length of the fixed data, so it has to get that from the protocol it is testing. In this case it found a match that only used one byte of fixed data.
I suppose I could change it to check all variants, and choose the matching one with the longest fixed data. _________________ -- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21239 Location: Chicago, IL |
Posted: Sat Nov 05, 2005 10:18 pm Post subject: |
|
|
gfb107 wrote: | I don't know if I'm looking at the wrong file, but my copy of S0775_ju.bin doesn't include the protocol code. |
That's weird, I mean either the JU box has the protocol built in or it doesn't. I've just loaded my copy of S0775_JU.bin to the Diagnosis Area so you can compare...
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=2404
Here's what the contents look like, where the protocol code is in green ...
Quote: | 0000 73 3d 33 07 02 00 fe fc f6 c0 08 fe 71 00 00 80 s=3...þüöÀ.þq...
0010 08 20 44 10 14 18 20 24 28 30 34 38 66 76 56 68 . D... $(048fvVh
0020 78 08 04 9c e5 2c 00 40 6c a4 48 68 78 70 60 5c x...å,.@l¤Hhxp`\
0030 50 3d 1d a7 0d 80 c5 c9 84 7c 48 dd d9 58 2b 5c P=.§..ÅÉ.|HÝÙX+\
0040 51 8b 16 b6 59 05 06 00 c5 03 32 00 c5 05 73 0b Q..¶Y...Å.2.Å.s.
0050 f2 00 c5 0b f2 05 02 43 8c 08 03 37 00 09 e6 22 ò.Å.ò..C...7..æ"
0060 02 c4 24 0e f6 01 55 18 08 56 c1 03 87 21 04 29 .Ä$.ö.U..VÁ..!.)
0070 04 8d 01 46 |
_________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
Posted: Sat Nov 05, 2005 10:47 pm Post subject: |
|
|
That doesn't match my version.
Strange, but protocol 00 02:5 doesn't produce the same fixed data as is present in that binary upgrade.
The fixed data in the .bin file is , but RM generates fixed data of
That last byte is not computed by the translators coded in protocols.ini. It is taken directly from the default value for fixedData. Do we have the wrong default value in protocols.ini?
Looks like I have a bit of work to do. Here's where I'm planning to go wth this:
Code: |
If there is protocol code in the upgrade
if there is a variant with matching protocol code
use it
else
use a manual protocol with the protocol code from the upgrade
else
for each variant of the protocol
import the fixed data (length determined by the variant) into device parameters
calculate the fixed data from the device parameters
if the imported fixed data matches the calculated fixed data
use the variant with the longest fixed data
|
_________________ -- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21239 Location: Chicago, IL |
Posted: Sun Nov 06, 2005 11:45 am Post subject: |
|
|
I like the idea of letting the protocol code in the upgrade override whichever version that RM was planning on using (assuming the code is different). However, in this case that's not the problem. I just took a closer look at the protocol code in the bin file and while it is different (which I hadn't noticed before), it's not significantly different. Here's the logic part of the old and new versions of the 5-1 version of $0002...
current version...
Code: | FF1B: 18 08 LD W1, R08
FF1D: 56 C1 03 AND W1, #03H
FF20: 87 21 04 LD W2, #04H[W1]
FF23: 29 04 LD R04, W2
FF25: 8D 01 46 JP 0146H |
version found in the Slingbox upgrade...
Code: | FF1B: 08 03 LD W0, R03
FF1D: 37 00 09 BTJRF FF29H, W0.0
FF20: E6 22 02 LD R22, #02H
FF23: C4 24 0E LDW R0E, R24
FF26: F6 01 55 CALL 0155H
FF29: 18 08 LD W1, R08
FF2B: 56 C1 03 AND W1, #03H
FF2E: 87 21 04 LD W2, #04H[W1]
FF31: 29 04 LD R04, W2
FF33: 8D 01 46 JP 0146H |
In the new version, the additional code is at address FF20 thru FF26, but this is skipped if bit0 of the first fixed byte is 0, which it is in our upgrade. The rest of the code is the same.
As for the fixed data question, I just fired up KM, selected the Dish Network Combo protocol and found that the following values generate the fixed data in the upgrade...
unit code = 0
device0 = 0
device1 = 1
device2 = 16
device3 = 4
I then fired up RM to see what it would do and I can see the problem, it's only supporting 3 device codes, not 4, so all you need to do is add an additional device code (which is the 5th fixed byte) and you should be all set. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
Posted: Sun Nov 06, 2005 2:39 pm Post subject: |
|
|
The problem with generating a manual protocol when the protocol code in the upgrade is unique, is that RM doesn't have anything to go on for naming the device and command parameters, or figuring out their translation. So it just punts.
It determines the number of fixed bytes and command bytes from the protocol code.
It will generate one device parameter for each fixed byte..
They will be named "Device 1", "Device 2", etc.
They will be 8 bits, and translation will be MSB.
It will generate one command parameter for each command byte.
They will be named "OBC" ( and "Byte 2" if there is a second byte).
They will be 8 bits and translation will be MSB.
Or, I could use the protocol variant that matches by PID and computed fixed data. I could even enhance it to attach the imported protocol code to the device upgrade. If the user chooses a different protocol, the imported protocol code would get discarded. _________________ -- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21239 Location: Chicago, IL |
Posted: Sun Nov 06, 2005 3:56 pm Post subject: |
|
|
If the 3rd byte of the imported protocol is the same as the 3rd byte of any of the protocol variants of the protocol-id, I would suggest that you try using the translation mechanisms for that variant to see if you can get the same fixed data. But even so, still offer up the imported protocol rather than the one from protocols.ini
I must confess that I haven't tried to use Manual Settings in RM yet, but do you allow all the same controls that KM allows? Ie, can the user specify whether it's MSB, LSB, etc along with specifying how many bits to use for the device and command codes and stating whether the 2nd byte should go before or after the OBC byte? _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|