JP1 Remotes

I'm looking for a memory efficient way to get more than 8 ToadTog bits. (Currently, using nested Toadtogs, I've got three bits holding 8 states, effectively giving me 13 Toadtog bits, but it's awfully expensive on macro/keymove memory.)

I'm wondering if multiple ToadTog devices with sequential setup codes, e.g., MISC 1800, MISC 1801, etc., all assigned to the same protocol would "do the trick". That protocol would compute the correct ToadTog storage register using the setup code in 3rd/4th byte of the keymove. The memory impact should be minimal (assuming the setup code is readily accessible). Of course, this approach also assumes there are one or more unused registers available for additional ToadTog status storage.

At this point, it's not clear from reviewing the 8910 (and other) extender code in which register the device setup code would be found. (8910.ex1 indicates that, for keymoves, only the 1st 3 bytes and the 5th byte onward are retrieved and held in registers.)

I'd welcome any comments/suggestions on the approach and if anyone knows in which register the setup code is stored and if it's still there after the protocol is loaded into RAM, please tell me.

Edit: Just realized that each device index has its associated setup code stored in the lower part of Eeprom. So, if the setup code is not already in a register, I should be able to get it using the device index in the first nibble of W03. I'll test on that basis. Comments still welcome.

It wasn't a very relaxing weekend, but I did learn a lot!

First, I'm reasonably certain that there's no (easy) way to determine the setup code for a keymove from its associated special protocol (SP) .

However , by including the address of the desired ToadTog status register in the dummy device definition and sending it to the SP (minor mod - 5 bytes) as fixed data, the number of additional ToadTog bits appears limited only by the available storage locations. (I used register RB6 as the second status register.) Each 8-ToadTog-bit set requires its own dummy-device (definition now 4 bytes long v.s. 3).

I also modified the CustomName SP included with the 8910 extender. The base SP requires padding the associated keymoves to 9 characters; mine doesn't. It saved me nearly 50 bytes of keymove memory. Offsetting that is a 15 byte "hit" on upgrade memory to accommodate the enlarged SP.

As byproducts of that activity, I created a detailed map of the IR dump, which doesn't appear to be documented on Yahoo (but can be inferred from the RDF and the extender assembler code) and developed another SP that allows stepping through all the S3C8 registers (on a remote with a LCD display).

If any of these items seem of general interest, I'd be pleased to post it/them. They are for the 8910/9910, but should be readily adaptable to other remotes. However, be forewarned; "messing" with special protocols requires assembler language skills. And, unless the "extender guys" eventually adopt them, you may be on your own.

Finally, if the "extender guys" have thoughts/concerns about what I've done, please say so.

Don

DGG wrote:As byproducts of that activity, I created a detailed map of the IR dump, which doesn't appear to be documented on Yahoo (but can be inferred from the RDF and the extender assembler code)

If not posted to Yahoo, would you, please, e-mail me that map? Thanks!

Sounds like you had fun anyway Don.

I would like the see the source for the Multiple TT and the register reader. I assume what you mean is that it displays the register values on the LCD correct?

I would post the SP multi TT to the special protocols area since others may have an interest.

Correct, it steps thru registers 2 at a time and displays the lower register number on the top line of the LCD and the contents of the register pair on the bottom line.

The .asm file is now posted in the Yahoo Diagosis Area as "Dpy_Reg.asm".

I'll post the multi-TT .asm in the special protocol area shortly, after I clean-up the comments.

Don

Multiple ToadTog file now posted in Yahoo Special Protocols as "Multi-ToadTog.asm"

I think it's worth posting the alternative Custom Name SP as well. Then people will have a choice depending on where their memory is running low.

David

It's posted as "CustomName-Pad.asm".

Incidentally, David, I also had a look at the pause protocol (in the 8910 extender) that produces very short delays. My only thought is that the "Delay" subroutine in the remote may require an input to select clock resolution - which it isn't getting.
Don