6960/9960B01 extender PAUSE value

[unclemiltie]

I'm thinking about tuning the PAUSE protocol in the 6960 and 9960B01 extender to mean something more than an arbitrary pause amount.

I've built a version that has a reasonably accurate 10ms delay as the basis of the pause (ie: $0A would give you a 1 second delay, $64 would give you a 10 second delay)

Is this more valuable to everyone? In reality, the pauses done in the old version were almost meaningless.

opinions?

-bill

[unclemiltie]

oops

I meant in increments of 100ms, not 10ms.

still, a value of $0A would give a 1 second delay, a value of $64 would give a 10-second delay.

[ElizabethD]

I don't have those remotes. But I would think it's a worthwhile effort.
My 6131ext has a Pause protocol built in and it does not suffer from the same non-existent pause as, say 8910. So no need to bring in KM or RM protocol. I have some old timing notes I checked through IRSA once:
$06=1/2sec
$10=1.75sec
$80=9sec
$C0=12.9sec
$FF=17.4sec
Useful pauses.
Now back to taxes?

[yesok]

Hello Unclemimiltie,

still, a value of $0A would give a 1 second delay, a value of $64 would give a 10-second delay.

I like your idea.
That is more scientific way of pause.

Yesok

[unclemiltie]

yesok

if you'd like to give it a try to see how you like it, replace protocol 1FB with this in the protocol add dialog box

URC-6960 version

Code: Select all

00 00 01 E4 07 0B E6 0D 07 C6 02 04 80 C6 04 07 
1B F6 08 E4 C4 5A CA 06 CB 05 16 CA 00 C6 CC 00 
2D E8 08 F6 01 EC 28 2D C6 C0 38 00 F6 01 0D 2A 
F7 AF 

URC-9960 version

Code: Select all

00 00 01 E4 07 0B E6 0D 07 C6 02 06 00 C6 04 0F 
1A F6 10 6F C4 5A CA 06 CB 05 16 CA 00 C6 CC 00 
2D E8 08 F6 0C 68 28 2D C6 C0 38 00 F6 01 0D 2A 
F7 AF 

The number that really means something in here is the 38 00 in the second to the last line. That's the delay count for the 100ms delay. I haven't timed it exactly yet, but it's close. If someone wants to figure out a more exact number and time things that would be great. (the best way to do it is to get a stopwatch and set the delay to $FF, that should be 25.5 seconds)

Of course when you do this, your pause values that you have in your pause specials will have to change.


-bill

[mr_d_p_gumby]

Wow, 50 bytes! The RM/KM pause protocol is only 17 bytes. I guess you'll have to weigh the convenience factor against available upgrade space.

I know the extender's built-in pause protocols (at least the ones that work) have very arbitrary delay values, but you have to remember that the original emphasis when the extenders were developed was to minimize the size of everything.

[unclemiltie]

mike

one of the "issues" with this extender is that the base remote does not read in the entire length of a keymove, it only reads in 4 bytes and not into a place that is stable.

Thus, the first half of this goes and finds the keymove again in order to get the data from the keymove to do the work. The incremental code to do this timed delay was only an LDW, and a DNJZ, which don't take much space.

I hated to do this, but I could find no other way. none of the keymove data survives (that I could see)

I'm still trying to find a way around this, but I'll bet that half of the 50 is going back and finding the keymvoe that got us there


edit: I went back and checked the code and 35 of the bytes are used to fetch the keymove. The LoadKeymove entry point in the ROM only reads 4 bytes from EEPROM and they are read into WW2 and WW6

I'm open to suggestions on how to get around this!


-bill

[ElizabethD]

The LoadKeymove entry point in the ROM only reads 4 bytes from EEPROM and they are read into WW2 and WW6

Bill, I have zero experience with extenders, but I do know that in C7, raw or extended, was a similar limitation - 3 bytes - even with the ext2. And I believe 1994 has it as well. Yet the C7 extender v5 reads the whole thing. Perhaps there are some clues there? Or is it really a property of 6960 etc?

[unclemiltie]

It's really a property of the non-extended remote. The ROM entry point that reads the keymoves on the 6960/9960 reads 4 bytes and stores them in WW2 and WW6. (I have to go check to see if this data survives the entry into the upgrade protocol, if it does, this could make the PAUSE that I did 15 bytes instead of 50) This won't help the other more complicated protocols like ToadTog, DSM and LDKP though as they need much more data.

Previous remotes read the entire keymove of length=n into a buffer starting (usually) at R2D which the protocol could go and pluck the data from. Since this remote doesn't do this, I have to re-create that read and since the pointers to where the keymove was don't survive, I had to re-search and then read. (thus the extra 35 bytes)

This is one of the areas where I wanted to spend some time when I got the extender done trying to reduce this and trying to see if I can pick up the crumbs lying around to not do as much, but right now it's sort of brute-forced to make things work.


-bill

[vickyg2003]

Yes the C7 is one of the remotes that reads the keymove into a buffer. . Also the last varient that I looked at of Bill's extender has 3 parts to do all the screen and light manipulation which must add another layer of complication. The C7 doesn't even have the backlighting to contend with. The C7 just barely required 2 parts.

I can't wait to get my taxes done so I can play with the 9960. I bought one for the lab. Problem is for a kameleon it isn't very good at hiding. DH found it right away. It lit up when he walked into the room. Who can miss that! DH doesn't like the fact that I play with remotes. I have to have my purchases shipped here to the office and pay for them with postal money orders so he doesn't find out.

[unclemiltie]

on further examination, the base remote does things different for 3-byte (key-type) keymoves than it does for 4-byte (hex-type) keymoves and stores away the key to be used in R_Key. I can take advantage of this in the Pause protocol, since it is only a 3-byte keymove.

So, a new version of the extender will be built with a MUCH smaller pause protocol. If you would like to paste it in, use this:

URC-6960B00

Code: Select all

00 00 01 28 8B C6 C0 38 00 F6 01 0D 2A F7 AF 

URC-9960B01

Code: Select all

00 00 01 28 91 C6 C0 38 00 F6 01 0D 2A F7 AF 

Again, the 38 00 is the count value to get the 100ms increments, so this can be tweaked if someone can time this out for me. (the only difference in the two now is the value for R_Key (R8B or R91)


Thanks mike for getting me thinking on this one. (this one has the 100ms delay per unit and is only 15 bytes!)


-bill

[mr_d_p_gumby]

Thanks mike for getting me thinking on this one. (this one has the 100ms delay per unit and is only 15 bytes!)

Congrats! We knew you could do it all along. 8)

[unclemiltie]

yea, but I'd really like to find a way to take those 35 bytes out of ToadTog, LDKP and DSM but it appears that I'm going to have to search and load the keymove in each of the protocols.

-bill