Use of ToadTog (standalone) on 8910

[alex750]

After looking over the 8910 extender, I decided not to install that just yet. Instead, I gave the standalone ToadTog protocol a try. I need ToadTog because my DVD player doesn't have discrete on/off codes.

The ToadTog.asm file is for a 15-1994. From what I understand, there are three sections to the source code:
(a) A listing of keys and keycodes for the remote in question;
(b) The program proper; and
(c) The commands which one wants ToadTog to execute, i.e., which bit to use, what to do to that bit, and which keycode(s) that bit corresponds to.

I pasted in the keycodes for an 8910 from IR's .rdf file (to which I had previously added some phantoms; I have verified that they work) where the 15-1994 keycodes were. I then put the following commands in the DATA section:

DB 5F ;Discrete on for DVD, use bit 7 to track
DB 1 ;Map this to phantom1 ($3D)
DB prev ;Use EFC 139 (eject) to turn on

DB 57 ;Discrete off for DVD
DB 1 ;Map this to phantom2 ($3E)
DB power ;Use EFC 070 (power) to turn off

DB 10

I ran this through S3C8ASM, pasted the resulting protocol into IR, created a dummy device (it's DVD_2047) to access it, and the keymoves for $5F and $57 to DVD_1573-Phantom1 and -Phantom2 respectively.

But when I use them in macros, they don't work. Also, for some reason, VPT is broken.

Questions:
(1) Are the keycodes in section (a) above of ToadTog.asm the same as those in an .rdf file?
(2) Are the ToadTog commands for discrete on and off (using bit 7) correct?
(3) Is there a specific protocol code for ToadTog, or can I use anything? (I used $0123, as in the 15-1994 example.)
(4) Will a simple dummy device referencing this protocol work (again, as I surmised from the example), or do I need to create a full-blown ToadTog device upgrade with KM?
(5) Does the ToadTog device need to be assigned to a device key (e.g., db-08) to work? This wasn't the case with the delay protocol, for instance...

[vasqued2]

There are a couple more remote-specific changes you need to make. Try changing MacNext = R95, MacSize = R9C, MacBufr = R9D and recompiling. I just did a cursory glance so there might be some additional remote specific changes. Try that first and see.

David

[johnsfine]

(1) Are the keycodes in section (a) above of ToadTog.asm the same as those in an .rdf file?

In this case, I think they are. S3C8ASM requires each keycode individually and in hex. An rdf file can have keycodes in either hex or decimal and individually or automatically incrementing from the previous. But if we're looking at the same RDF, then the keycodes there are individual and in hex as required by S3C8ASM.

(3) Is there a specific protocol code for ToadTog, or can I use anything? (I used $0123, as in the 15-1994 example.)

Anything that isn't used for a different protocol by another UPGRADE in the same remote is OK.

(4) Will a simple dummy device referencing this protocol work (again, as I surmised from the example), or do I need to create a full-blown ToadTog device upgrade with KM?

A simple dummy device upgrade is correct. It is needed only to associate a setup code with the protocol ID.

(5) Does the ToadTog device need to be assigned to a device key (e.g., db-08) to work? This wasn't the case with the delay protocol, for instance...

No. Setup codes that are intended only for use in KeyMoves never need to be assigned to device keys.

David's answer was important. The protocol is totally incompatible with the remote without that correction. I didn't check that his numbers are right, but I assume he knows such things. I also didn't check any other aspect of this other than what I answered, so there might still be other details to deal with. ToadTog via the extender is much simpler.

[ot04298]

I looked at this from a different angle a few days ago, but never followed up. The ToadTog standalone in the files is for 1994 extender 3. I was looking at what it would take to use the newer ToadTog version included in the newer extenders as a standalone protocol. John is right, the newer version is much simpler. In addition to the 3 variables mentioned above, the ToadTog status bit register might also vary by remote or extender version.

Could a standalone of the newer ToadTog version be created and posted with versions for various remotes, similar to the LDKP special protocol?

[vasqued2]

You would need a remote-specific version for essentially every different remote. A lot of work for not a lot of payoff, especially when most extenders come packaged with ToadTog already.

PS. I didn't realize the 'stand alone' ToadTog was really designed to work w/ the 1994 extender. I haven't looked at the code in detail, but I'd be suprised if it actually worked on any unextended remote without some significant modifications.

David

[johnsfine]

I didn't realize the 'stand alone' ToadTog was really designed to work w/ the 1994 extender. I haven't looked at the code in detail, but I'd be suprised if it actually worked on any unextended remote without some significant modifications.

The 'stand alone' ToadTog was not designed to work with the 1994 extender, nor any extender. It was designed to work stand alone. I think it would take some changes to make it work with an extender, though I'm not really sure about that for some of the simpler 1994 extenders.

The "new" ToadTog is very dependant on a couple extender features. It would be very hard to make a stand alone version of it.

[alex750]

There are a couple more remote-specific changes you need to make. Try changing MacNext = R95, MacSize = R9C, MacBufr = R9D and recompiling. I just did a cursory glance so there might be some additional remote specific changes. Try that first and see.

I did so. Still no go, and still no VPT on the TV, even after reloading the original download.

Thinking perhaps my phantoms were at fault, I deleted them from both the .rdf and the ToadTog.asm source, reassembled ToadTog, and this time assigned my ToadTog commands as follows (remember DVD_2047 is my ToadTog "device"):

DVD_1573: Shift-0<-DVD_2047: 57 (discrete off using EFC 070)
DVD_1573: Shift-1<-DVD_2047: 5F (discrete on using EFC 139)

Still no go, still no VPT. Should I have done a memory flush (fill buffer with FF, upload, then do an OPS RESET on the remote)?

Could there possibly be a clash with the delay protocol?

Perhaps I should consider the extender again--being able to use a custom device name to display "BOOB TUBE" when the TV is selected would be cool 8)