Common JP1.3 Extender V3

[Lurker]

With the Atlas OCAP remote, LongPress in Other Settings has a choice of Deactivate or BL Toggle. Does this mean if I want to turn off the backlight, then I will be unable to deactivate the extender? Is this safe? Same question goes for the other way around. Can I have both at once?"

If you are going to use the Long Press (Setup) to toggle the Backlight then you could put a keymove on another key to deactivate the extender. Either that or if you need to deactivate you can just change the setting, re-load the remote and then deactivate. (The 15-100 has an option to set the clock on long press of Setup)

I'm digging back into the memory here but I *think* I put that part in for the deactivation of all of the remotes when I built the combined extender and then had to deal with the conflict that was (IIRC) only there on those two remotes on that button. Looking at the source code and the revision history I put that selection in in March of 2009!

If you want to load a keymove on some other key (like maybe Shift-Shift) you would use Protocol 180, which is the activate/deactivate protocol. If you put the first key in the keymove (it has to have two keys in it due to a limitation in the unextended remote, discussed elsewhere) as a $01 it will deactivate. Everything else will activate.

Thank you, that is very helpful.

[Lurker]

Is there a technical reason why extenders have only 8 toad togs available, or was this just assumed to be "enough"?

[The Robman]

Is there a technical reason why extenders have only 8 toad togs available, or was this just assumed to be "enough"?

I'm just guessing here, but each toadtog uses a "bit" of data, so 8 of them would use a "byte". To increase the number, we'd need to grab a second byte of data (ie, another internal register). So yeah, the thinking was probably that 8 was enough, after all, how many people try to control more than 8 devices with a single remote?

[Lurker]

Is there a technical reason why extenders have only 8 toad togs available, or was this just assumed to be "enough"?

I'm just guessing here, but each toadtog uses a "bit" of data, so 8 of them would use a "byte". To increase the number, we'd need to grab a second byte of data (ie, another internal register). So yeah, the thinking was probably that 8 was enough, after all, how many people try to control more than 8 devices with a single remote?

Why are you assuming one toadtog per device? I have been using all 8 for a while now. Toadtogs are the only way to remember states or create if/then logic in macros.

If anyone ever feels like working on this old code again, and it is easy to do, more toadtogs would be a very useful upgrade.

[Ed]

I had an older model RCA TV that had no discretes at all, so I made judicious use of toadtogs to "create" them. I had several different toadtogs for that one device -- one tracked the on/off state of the TV, which was straightforward, but then I used several toadtogs to track which video input was selected. I recall there being four different input choices available, so I think I used four toadtogs to track that state. (On this TV, the number of up/down presses to get to the desired input depended on which input was selected, and there was no button to press that would put the input back to a "known" state.)

On a good day, these toadtogs worked well, but more often than not, they went out of synch and it became very painful to synch them back up again.

So, while I can see there being a potential use for multiple toadtogs for a device, in practice I had so much trouble keeping them in synch I just abandoned using them. So, based on my experience only, I'm not sure more toadtogs would be useful.

[Lurker]

I had an older model RCA TV that had no discretes at all, so I made judicious use of toadtogs to "create" them. I had several different toadtogs for that one device -- one tracked the on/off state of the TV, which was straightforward, but then I used several toadtogs to track which video input was selected. I recall there being four different input choices available, so I think I used four toadtogs to track that state. (On this TV, the number of up/down presses to get to the desired input depended on which input was selected, and there was no button to press that would put the input back to a "known" state.)

On a good day, these toadtogs worked well, but more often than not, they went out of synch and it became very painful to synch them back up again.

So, while I can see there being a potential use for multiple toadtogs for a device, in practice I had so much trouble keeping them in synch I just abandoned using them. So, based on my experience only, I'm not sure more toadtogs would be useful.

Yes, I agree, this is a huge problem if you can't find any way to get back to a known state. I have found many uses which work well for me. I have to choose my "top 8" and drop the rest.

[The Robman]

Why are you assuming one toadtog per device? I have been using all 8 for a while now. Toadtogs are the only way to remember states or create if/then logic in macros.

I wasn't, I was just guessing as to the original intent. I didn't write the extender.

[Lurker]

I wasn't, I was just guessing as to the original intent. I didn't write the extender.

All of the extenders seem to have this same limitation, which is why I wondered if it is because of a fixed technical limit, or if they all made the same design choice for some reason. Hopefully the authors will chime in with an explanation.

[unclemiltie]

Is there a technical reason why extenders have only 8 toad togs available, or was this just assumed to be "enough"?

I wrote this extender, which is a derivative of others, so can shed some light.

the status of the TOG is kept in a single register on the SCF8 processor. they are 8-bit registers, so 8 TOGs were designed by someone before me.

could this be expanded? sure, but it would require:

• the programmer to find another unused register that the remote doesn't use for something else or clobber at odd times. This list is small and we extender writers use them for lots of stuff, not just TOG status. There is no "documentation" so it requires a bit of experimentation and sometimes getting remote that do weird things, including becoming "bricks"
  
  Some compexity in the protcol that fires the TOG to understand two registers. as you probably know, code space is tight so that is a complexity that might fit into the extender, might not.
  
  some more work in the tools RMIR so that it knows how to properly format the TOG and which register to use to store the bits.

Could it be done? sure, but it's a lot of work.

here is the source for the TOADTOG protocol for this extender so you could give it a try. you could just replace the existing tog or you could give it a new number and have a separate one. Graham is going to have to weigh in on what it would take in RMIR to deal with it.

Code: Select all

L181_Start:	  INCW	RR_AdvCodeAddr			;increment address of keymove past device setup code
		  INCW	RR_AdvCodeAddr
		  LDW	RCA,RR_AdvCodeAddr		;copy address of keymove data 
		  LD	W2,R03				;copy the ToadTog control byte (first byte of keymove) from R03
		  SWAP	RC2				;Top digit selects bit number
		  LD	W8,#01				;Start with bit 0
L181_1:		  AND	RC2,#07				;Use low three bits as bit number, also handle
							; overflow when rotating 8 times for bit 0
		  RL	RC8				;Rotate bit into position
		  DJNZ	W2,L181_1			;Do it N times for 1 to 7, and 8 times for 0
		  LD	W3,R03				;use ToadTog control to get top of true side
		  AND	RC3,#07				;mask off all but length bits
		  LD	W0,#01				;bottom of true side
		  TM	RC8,R_ToadTog			;is the toggle bit set for this toggle?
		  JRNE	L181_3				;yes, copy true side keys to the macro buffer
		  LD	W0,RC3				;compute bottom of FALSE side buffer
		  INC	W0
		  LD	W3,R_AdvCodeLen			;compute top of FALSE side buffer
		  SUB	RC3,#03				; adjust to point to last key
L181_3:		  CP	RC3,RC0				;selected side empty?
		  JRLT	L181_4				;yes, check and change toggle bit for this toggle
		  LD	R_AdvCodeLen,RC3		;compute length of selected side
		  SUB	R_AdvCodeLen,RC0
		  INC	R_AdvCodeLen
		  ADD	RCB,W0				;adjust address to point to data to load into macro buffer
		  ADC	RCA,#00
		  LDW	RC0,RCA				;transfer new address to get ready for load
		  CALL	LoadMacro			;load the macro into the macro buffer
							;set or toggle bits in ToadTog register 
L181_4:		  LD	W2,R03				;get ToadTog control byte
		  BTJRF	L181_5,W2.3			;Set requested?
		  OR	R_ToadTog,RC8			;Yes: do it
L181_5:		  BTJRT	L181_Return,W2.7		;Toggle requested?
		  XOR	R_ToadTog,RC8			;Yes: do it
L181_Return:	
		  RET

[unclemiltie]

BTW, vickyg2003 wrote a protocol that kept track of inputs and fired the right number of "arrow" keys to get where you want. She did that a long time ago. i have no idea where to find it, but i know it's been done outside of a TOG.

[vickyg2003]

Rob sent me a message to look at this thread.

We have his and hers remotes in my house, so I never used toad togs for the purpose of keeping track of my equipment because you never know what remote is going to use.

My solution is to use a recursive LKP. Typically I use this for input selection, and my custom MUTE button that cycles through the closed caption options until I release the button.

I used to try to get people interested in recursive LKP's every time there was a toadtog discussion. Typically the toad/tog conversation kept going, and nobody people ever responded to my solution. That is until this thread. After I mentioned recursive LKPs several times in this thread, sti491 asked for a more information.

On Page 11 of this thread, we got into an example.

http://www.hifi-remote.com/forums/viewt ... &start=150

Hope this helps.
Vicky