(DSM) protocol question

[spock]

Thanks to this great forum I was able to get LKP and DSM special protocols
running with my (unextended) URC-7552 B00 (EBV0EBV1).

The DSM is mainly done by

LD R_Key, R03
POP RC0
POP RC1
POP RC2
POP RC3
POP RC4
LDW RCA, KmmLoad
PUSH RCB
PUSH RCA
PUSH RC4
PUSH RC3
PUSH RC2
JP @RC0
(This command sequence is apparently used with many other RC types too)

After thoroughly analyzing the LKP protocol for my RC, I concluded
that a protocol only consisting of the commands

LD R_Key, R03
JP KmmLoad

could do the DSM job as well - and it really does!

Now I just wonder if there is any disadvantage "from an expert's point of view"
of my DSM protocol approach compared with the protocol "usually" used
for the DSM.
Can anyone tell me please, what values the RCx registers do contain
during the execution of the protocol, so I could get a clue what this
"lively" register pushing/popping is good for?


BTW, does anyone know other important subroutine addresses
("ReadKey", "LED blinking", Timer(s), etc.) for the URC-7552 (7550, 7560...)?

I'd like to do some more protocol programming, but it is nearly impossible
of course, without knowing the OS "internals".
I already figured out some addresses and registers from working protocols.
But there are still a lot of them missing...

[sfhub]

Let me first say that I've never really looked at the assembly, but usually when you see a lot of push and pops like this, somebody is setting up or unwinding a stack frame, possibly to account for recursion. Again, this is just a guess, I could be totally off base due to having never looked at this stuff before.

The DSM is mainly done by

LD R_Key, R03
POP RC0
POP RC1
POP RC2
POP RC3
POP RC4
LDW RCA, KmmLoad
PUSH RCB
PUSH RCA
PUSH RC4
PUSH RC3
PUSH RC2
JP @RC0
(This command sequence is apparently used with many other RC types too)

After thoroughly analyzing the LKP protocol for my RC, I concluded
that a protocol only consisting of the commands

LD R_Key, R03
JP KmmLoad

could do the DSM job as well - and it really does!

Now I just wonder if there is any disadvantage "from an expert's point of view"
of my DSM protocol approach compared with the protocol "usually" used
for the DSM.
Can anyone tell me please, what values the RCx registers do contain
during the execution of the protocol, so I could get a clue what this
"lively" register pushing/popping is good for?

[spock]

Thanks for your reply...

After examining this (long) command sequence once again, I think I
understand now, what it does - but still don't know why it does it.

Obviously a 16 bit address (in RC0/RC1) is taken from the stack
(and that address is jumped to at the end of the special protocol).
Then 3 values are taken from the stack, the 16 bit KmmLoad address
is pushed there and the 3 values are put back to the stack (to be
processed next by internal routines, perhaps)
KmmLoad address obviously would be processed afterwards.
"unknown" address (RC0/RC1) -> stack values (RC2/3/4) -> KmmLoad

The short protocol leaves the stack untouched, and therefore I think the
processing order would be KmmLoad -> "unknown" address -> stack values.

I don't see a different behaviour with my remote using the long protocol
compared with the short one.
Maybe, only the long protocol works with extenders, but this is just a guess.

Of course I could be satisfied with the fact, that the short protocol
works fine with my remote, but sometimes I want to know why it works, though.

I think it would become much clearer if I knew, what values and what
"unknown" address the stack does contain, while processing the special
protocol.
(Maybe, I'll have to find a way to make my remote tell them to me... )

[ElizabethD]

My understanding is: the first 2 values are thrown away. There is substitutions going on and things on the stack shift. Considering how much code compacting needs to take place here, I suspect this section can't be cut short or someone by now would have changed it. What's there? I think it's under NDAs .

FYI: Extender versions of DSM use completely different algorithm, only unextended version have this type of code.

[Nils_Ekberg]

Elizabeth, good catch.

The main reason the push/pops are not in the extender versions is because the extender is basically controlling the stack one byte at a time. For non-extender protocols the stack needs to be protected/preserved hence the reasons for the push/pops. In some cases it may not cause a problem to eliminate the push/pops depending on what is going on in the remote at the time the protocol is triggered. Probably safe to go without them just remember if the remote burps in some fashion the first thing to suspect is the protocol.