| View previous topic :: View next topic |
| Author |
Message |
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
 Posted: Tue Aug 30, 2005 5:24 pm Post subject: |
 |
|
It is the same executor that is already in RM as DirecTV, pid 01 62.
So it would be better to use it as that.
After the raw import to get the basic assignments of EFC numbers to buttons, I'm not sure what is involved in switching over to DirecTV protocol but preserving those EFC numbers and preserving or restoring the fixed data. |
|
| Back to top |
|
 |
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21234
Location: Chicago, IL
|
|
| Back to top |
|
|
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Tue Aug 30, 2005 5:56 pm Post subject: |
|
|
| Since this protocol is called DirecTV in RM, should I rename it in DecodeIR (from "Russound" to "DirecTV") so we won't be confused this way next time? |
|
| Back to top |
|
|
gfb107
Expert
Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC
|
|
| Back to top |
|
|
pasha
Joined: 30 Aug 2005
Posts: 26
|
| Posted: Tue Aug 30, 2005 6:06 pm Post subject: |
|
|
WOW!!!
This works!
This is defenetly great help from all of you.
Thanks
-Pasha |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21234
Location: Chicago, IL
|
| Posted: Tue Aug 30, 2005 7:22 pm Post subject: |
|
|
I've been meaning to take a look at the $0162 exec for a while as it's such a big piece of code. It's too big to be loaded into the Slingbox, which has a 200 byte limit. So this thread has nugged me into reviewing it.
I've only just started looking, but right off the bat I can se that there's some code up front which handles a couple of different frequencies, which most people won't need, and I'm guessing that some of the rest of the code is there to handle the checksum. If the checksum code were eliminated, each function would need 2 bytes of data, so the question is, which would result in a smaller upgrade (device and protocol together).
_________________
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 |
|
|
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Tue Aug 30, 2005 7:31 pm Post subject: |
|
|
| The Robman wrote: | | I've been meaning to take a look at the $0162 exec for a while as it's such a big piece of code. It's too big to be loaded into the Slingbox, which has a 200 byte limit. |
I notice it has a lot of subroutine calls to other parts of itself. Those tend to be very costly in executor size for what they accomplish. Usually it is easy to join all the call point of a given subroutine into a loop so there is only one call point so you don't need it to be a subroutine.
Computing the check nibble shouldn't be very hard, but I haven't looked to see how hard they made it for themselves. I'm sure it can be done in few enough protocol bytes to typically save space vs. an upgrade with two byte hex cmds. |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21234
Location: Chicago, IL
|
| Posted: Tue Aug 30, 2005 8:58 pm Post subject: |
|
|
That's what I was thinking too. I recall the size of their original ReplayTV exec vs. yours. If you get a chance, could you take a look at this exec please? I'm sure you can do a nice job of cleaning it up.
_________________
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 |
|
|
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Wed Aug 31, 2005 7:12 am Post subject: |
|
|
How small do you need it?
There are a bunch of bytes of code that can be removed trivially, without changing the basic approach to creating the signal. Probably there is a better basic approach that I could find with a lot more effort. But then I might not find time to finish it. |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21234
Location: Chicago, IL
|
| Posted: Wed Aug 31, 2005 7:34 am Post subject: |
|
|
Well, the current exec code is 184 bytes and the maximum upgrade size for the Slingbox is 200 bytes, so that only leaves 16 bytes for everything else. Ideally, I'd like to see the code smaller by 50 bytes or so, but I'll take whatever I can get.
For starters, I figure that I can delete all that code that selects the carrier freq as each user just needs one freq. I haven't dug deep enough into the checksum and 4-burst code to see if I can reduce any of that yet.
_________________
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 |
|
|
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Wed Aug 31, 2005 7:57 am Post subject: |
|
|
| The Robman wrote: |
For starters, I figure that I can delete all that code that selects the carrier freq as each user just needs one freq. I haven't dug deep enough into the checksum and 4-burst code to see if I can reduce any of that yet. |
I have some misgivings about stripping out the options (frequency and ???). That would mean our executor wouldn't be fully compatible with upgrades based on UEI's. You're probably right that each user would want the options only one way, so RM could have several protocols.ini entries that hard code each option.
I didn't look up details to see what the option on bit 0 means. Bits 1 and 2 seem to select frequencies.
You can save the 4 bytes of call and return on the check nibble computation because it is only used once. You can save nearly half of the code within that computation by getting rid of the stupid table for looking up 1, 3, 5 and 7.
You can use 5 words instead of 8 for the table of bursts by taking advantage of the overlap, and in doing so you save a couple bytes of code in accessing that. I think a few more bytes can also be simplified out of that section.
The three calls, the return and the other overhead of invoking the routine that processes bit pairs looks excessive for what it does, but it isn't immediately obvious how to do the 2/4/2 sequence in a loop rather than as calls. |
|
| Back to top |
|
|
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Wed Aug 31, 2005 8:00 am Post subject: |
|
|
| The Robman wrote: | | Well, the current exec code is 184 bytes and the maximum upgrade size for the Slingbox is 200 bytes, so that only leaves 16 bytes for everything else. |
I haven't looked at all at how Slingbox upgrades work. Most models move the protocol upgrade and device upgrade into ram independently, so any limit would apply to each of them, rather than to their total. Is that different on the Slingbox? I hope you don't mean the total upgrade area in eeprom is just 200 bytes. That would be really lame. |
|
| Back to top |
|
|
pasha
Joined: 30 Aug 2005
Posts: 26
|
| Posted: Wed Aug 31, 2005 8:03 am Post subject: |
|
|
seams like this protocol only works alone...
remote doesn't work with extender.... |
|
| Back to top |
|
|
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Wed Aug 31, 2005 8:07 am Post subject: |
|
|
| pasha wrote: | seams like this protocol only works alone...
remote doesn't work with extender.... |
That doesn't sound likely.
You should upload (to diagnosis area) your .ir file with the extender and this upgrade and everything as it was when you tested to find that it doesn't work with extender. Maybe we'll spot some error. Also please clarify "doesn't work". With a specific description of actions and results we may be able to perform a comperable test ourself and/or explain what you're doing wrong. |
|
| Back to top |
|
|
gfb107
Expert
Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC
|
| Posted: Wed Aug 31, 2005 8:50 am Post subject: |
|
|
| johnsfine wrote: | | You're probably right that each user would want the options only one way, so RM could have several protocols.ini entries that hard code each option. |
RM has support for translating device parameters directly into the protocol code, so it might be possible to do that sort of thing with just one protocols.ini entry.
This is done using the CodeTranslator.<processor> value.
_________________
-- 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 |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
