Page 2 of 3

Posted: Mon Mar 19, 2007 5:08 pm
by Capn Trips
ElizabethD wrote: Note that sig still says x1, annoying :(
Yeah, I remember when "team" first did this, I pointed out to him that using the same rdf sig for multiple extender variants would confuse matters and suggested alternate rdf names, but he didn't choose to do so, so you have to be very careful using three different rdfs with the same sig (or simply rename them yourself - making the attendant hex file changes, as well)), keeping track of which IR file you have created using which sig. :evil:

I don't use the altenate memory boundaries, so I ultimately deleted those additional rdfs, as I got sick of always having IR ask me WHICH rdf I want to use whenever I was downloading from my remote.

Posted: Mon Mar 19, 2007 5:53 pm
by unclemiltie
Ok, some initial testing on the 9960B01 tonight

I moved the start of the Adv Codes to $500 and put a bunch of upgrades (the same with different setup codes) into the upgrade area. The one just before the boundary, the one that crossed the boundary and the one that was above the boundary worked fine in the 9960B01 extender.

haven't tested fully, but this is great news.

now, back to why I think I didn't try this before (I remember thinking about it) There is a byte at $400 that tells the remote that there is nothing in the learned area (either $00 or $FF) and I always wondered if the remote would do something odd if it found something else there. Since it's probably finding the keymove to load the extender before it would have searched to find a learned key for the power key, it's probably OK. (I'm going to search more to be sure)

Thanks to jsevinsk for getting me on this kick. I think that my next release of the 9960B01 extender will expand the upgrade memory since there is nearly unlimited adv code memory and the upgrades are getting a bit tight.

Posted: Mon Mar 19, 2007 6:58 pm
by ElizabethD
Capn Trips wrote:I don't use the altenate memory boundaries, so I ultimately deleted those additional rdfs, as I got sick of always having IR ask me WHICH rdf I want to use whenever I was downloading from my remote.
Same here. Today was my first 'overload' use. But then along came pasha and his IR file was using ext2, and so it was back to the confusion. Where is the site owner?

In 8910 I have 6 bytes left on each side. Anyone can come up with how I can get 20-25 keymove bytes free ? :evil:
unclemiltie wrote:there is nearly unlimited adv code memory
Lucky you :)

Posted: Mon Mar 19, 2007 9:02 pm
by jsevinsk
So, in what order does IR pack the devices and protocols in the upgrade area?

Posted: Tue Mar 20, 2007 7:27 am
by ElizabethD
Don't know if this will be helpful to you, but IR can tell you. If you change a byte on the Protocols or Devices sheet in IR you'll see it in raw data. Add or delete and watch the two pointers at $100 and a whole block change or shift. It all behaves the same as the D_table and P-table calculations in asm with the results in the hex file. IR might be inserting, I don't remember.

Posted: Tue Mar 20, 2007 7:47 am
by jsevinsk
ElizabethD wrote:Don't know if this will be helpful to you, but IR can tell you. If you change a byte on the Protocols or Devices sheet in IR you'll see it in raw data.
Ah yes, I see that now. I guess it's a trial-and-error job to figure out the last thing in the upgrade area, huh?

Posted: Tue Mar 20, 2007 2:23 pm
by jsevinsk
So, I would like opinions about a better way to implement a feature that I added, which is the one that supports TVs with no discrete input commands. The new protocol takes as parameters the input number you want to select, the total number of inputs, and the key codes for the menu, up, down, and enter keys. The protocol remembers what input you're on, and if you're on input 2 and you want to go to input 4, the remote sends menu, down, down, enter.

It works, but what I don't like about it is that for every input you want to use, you have to specify all the key codes in all the hex commands. (You'll see what I mean if you look at the example IR file included in the extender zip file.) The only thing that's different between all of them is the input you want to go to. I would like to find a way to specify the four key codes and the total inputs in one place if possible. Ideas?

Posted: Tue Mar 20, 2007 4:01 pm
by StephenR0
I won't venture an opinion about how you implement it, but I'm very interested in this functionality. I'll certainly be helping you test it. Right now, I'm using a cascading series of double key macros to automate changing inputs. One thing that I've discovered with my TV is that I have to put a small delay in my macros just after calling for the input menu. It seems to need that before it can accept up or down arrows to go to a different input. Do you think your feature will be able to accommodate that kind of thing?

Steve

Posted: Tue Mar 20, 2007 4:03 pm
by vickyg2003
John, after you put your problem out, it caused me to start thinking and I found an excellent way for me to do this. I had a complicated method that worked, BUT everytime we added or subtracted a device on the system the macro had to be reworked. Then I came up with this idea that took all the problems out of state keeping.

I put a macro on my Device keys that does this.

DVD:

T_DVD
M_DVD
C_DVD
X_TV
PHANTOM1 && LONG KEYPRESS

end of macro

PHANTOM1: && TV mode
if longkeypress
PHANTOM2 && presses toadtog to turn on menu
DNARROW
pHANTOM1 && keeps repeating
else
ENTER
PHANTOM3 && Turnoff Toadtog
X_CANCEL
PHANTOM1 && in the original mode for any follow up procedure
endif

end of macro

PHANTOM2: && TV mode Check to see if I already
If toadtog1(1) oN
do nothing
else
TV/VCR && This turns on
force on
endif

end of macro

PHANTOM3: && TV mode force toad tog off
iF toadtog On
turn toadtog1 off
else
turn toadtog1 off
endif



PHANTOM1: && DVD mode
PLAY && serves as a discrete on

end of macro


All of your devices use the same phantom1 key on the TV and it cycles through the menu until the person holding the remote finds the right selection. After you let up on the LKP of the DVD, the short side executes. All devices keys have X_TV; Phantom1 in there call.

Posted: Tue Mar 20, 2007 4:11 pm
by Mark Pierson
jsevinsk wrote:I would like to find a way to specify the four key codes and the total inputs in one place if possible.
I've never written any kind of protocol, nor have I looked at anything you've done thus far...

However, couldn't this be done as fixed data in a dummy upgrade? By that I mean specifying the required items as you would device and sub-device settings for any normal upgrade? That should allow your SP keymoves to only require 1 byte of data to represent the number of the desired "input".

Posted: Tue Mar 20, 2007 5:30 pm
by jsevinsk
StephenR0 wrote:I won't venture an opinion about how you implement it, but I'm very interested in this functionality. I'll certainly be helping you test it. Right now, I'm using a cascading series of double key macros to automate changing inputs. One thing that I've discovered with my TV is that I have to put a small delay in my macros just after calling for the input menu. It seems to need that before it can accept up or down arrows to go to a different input. Do you think your feature will be able to accommodate that kind of thing?

Steve
Not as it is right now, but if I changed it so that it could handle more than one key code for entering and exiting the menu, one key code could be a pause function.

Posted: Tue Mar 20, 2007 5:32 pm
by jsevinsk
Mark Pierson wrote:However, couldn't this be done as fixed data in a dummy upgrade?
Hmm, let me think about that one. Thanks for the idea.

Posted: Tue Mar 20, 2007 7:33 pm
by StephenR0
Ok. Thanks for your response. I have to leave town for a few days. But when I get back, I'll try what you have and see if I need any delays.

Steve

Posted: Tue Mar 20, 2007 9:45 pm
by jsevinsk
StephenR0 wrote:I won't venture an opinion about how you implement it, but I'm very interested in this functionality. I'll certainly be helping you test it. Right now, I'm using a cascading series of double key macros to automate changing inputs. One thing that I've discovered with my TV is that I have to put a small delay in my macros just after calling for the input menu. It seems to need that before it can accept up or down arrows to go to a different input. Do you think your feature will be able to accommodate that kind of thing?

Steve
After thinking about it some more, I think my input select protocol might work as-is. For the menu key, specify a key which is a DSM for the string of commands that you need, like your TV's menu key, then a delay. I think it should work, but I haven't tried it.

Posted: Mon Mar 26, 2007 4:07 pm
by StephenR0
I tried it out and it seems to work pretty well. I used your idea about using a DSM for the menu key and that worked as well. I'll keep using it and I'll try new versions as you come up with them. Thanks.

Steve