Need help converting a protocol in PB

Post by **ElizabethD** » Sat Apr 16, 2005 5:34 pm

Unless someone has already done it, I'd like to take a shot at converting the standalone L/DKP protocol from 8910 unextended version to unextended Cinema7+(7800). But I need help from the experts.
1. I don't have a clue where/how to find values corresponding to these 8910 declarations:

Code: Select all

R_Iflags	EQU	R87
R_DKey		EQU	R80
R_DKeyCnt	EQU	R83
		
StartT0		EQU	$0791 
ScanKeypad	EQU	$3EAD

KmmLoad		EQU	$167A
ReadKey		EQU	$3E8F

Additonally, unnamed R00, R03-R05, R82, R4A are used in code

I'm pretty sure RC0-RC4, and RCA-RCB are used identically, because standalone DSM uses them already in the C7+ version.

2. How to set up a blink routine (I can't use the LCD code), something like 2 quick blinks for error: LD something with #2, and call a blink routine???

3. Can I assume that the registers used in the 8910 are the same numbers and are used in the same way in C7? Protocol builder readme file indicates the register numbers are the same in old and new S3C8 remotes, but how can I tell if they do/don't the same thing without being able to see

the state of flags/registers/memory in the remote at strategic times?

johnsfine · Post by **johnsfine** » Sun Apr 17, 2005 7:22 am

In the 7800:

R_Iflags = R7B
R_DKey = R75
R_DKeyCnt = R78

Start0 = 175C
ScanKeyPad = 1306
KmmLoad = 0651
ReadKey = 12E7

R00-R05 are used the same across models.

R82 On the 8910 normally holds the code of the current keystroke (from keypad or macro oer wherever). On the 7800, that is R77.

R4A is used for timeouts on both the 7800 and the 8910. I'm not sure is the use is compatible.

The routine at 13F8 will blink the LED the number of times in the W2 (AKA RC2) register.

The routine at 13EC will blink the LED twice unless the flag (in R00) is set indicating a macro is active, in which case it won't blink.

I'm going to be away April 18 through 24, so if I got any of this wrong or it needs explanation, you may need help from another expert or to wait a week.

Edit: R_DKey was wrong in the first version of this post. I explained below, but also changed it here in case someone looks for info from this post later.

Post by **ElizabethD** » Sun Apr 17, 2005 3:53 pm

johnsfine wrote: R4A is used for timeouts on both the 7800 and the 8910. I'm not sure is the use is compatible.

Thanks, John.
This forum is a goldmine

Thanks to your numbers, it looks like nothing to it. BUT, if timeout gets me, and I would not be surprised if it did, I won't know the alternatives. Timeout is the key for both DKP and LKP and if R4A acts differently, the flags might be setting differently too ... just thinking out loud. I'll take it from here, and post if no go.

Post by **ElizabethD** » Sun Apr 17, 2005 8:31 pm

DSM part works.
Blinking works.
Short and Single side work. Hey, you gotta start someplace

I missed RF1 in the shopping list of registers. 8910 comment is "Enable key sense interrupts" and the test is for #$7f.

I maybe jumping to conclusion, but it looks to me like in LKP this branch on carry clear is always taken, so the long side has no chance

Code: Select all

CALL	ScanKeypad ($1306 in 7800)
JRNC	UseM1

I'll try other flags.

johnsfine · Post by **johnsfine** » Mon Apr 18, 2005 5:55 am

I think RF1 is the same between those models, but I don't have the pdf file from Samsung handy. RF1 is one of the registers whose use is determined and documented by Samsung rather than chosen arbitrarily by the programmers who wrote the UEI firmware. The 8910 uses a different Samsung part with different registers than the 7800. But I think that register is the same.

The JRNC instruction is correct. That branch will be taken whenever the scan routine decides the keypad state is not what it was at the start of processing for this physical key.

If the branch is always taken, then either R75 (where the original keycode was stored) or R78 has changed since that start of processing.

A lot of our software messes with that count register (R78 on the 7800) to purposely fool the scan routine. The normal value is 1 (meaning that one key is pressed). We change it to something other than 1 to make it seem that the key is different and change it back to 1 to reenable accurate testing of the keypad.

BTW, my travel plans fell through, so I'll only be away Friday through Sunday, not today through Sunday.

Post by **ElizabethD** » Mon Apr 18, 2005 9:54 pm

What do you call R75 and its corresponding thing in 8910? I'm just converting, not inventing anything. I don't see anything similar there.
When is R75 changed -when a key is pushed or anytime in a long keymove?
I'm driving with my eyes closed

If R78 in 7800 is the R_Closures thing you once explained in the extender forum, then I don''t see that sort of code in the 8910 version. There are at least 5 other time and key related variables taking part in the long/double side. And I don't see the light. Any explanation is valuable, 'cause I don't think it's hopeless yet. Thanks in advance. Thanks for letting me know travel plans

johnsfine · Post by **johnsfine** » Tue Apr 19, 2005 5:59 am

ElizabethD wrote:What do you call R75 and its corresponding thing in 8910? I'm just converting, not inventing anything.

Sorry about all your time I must have wasted. I just looked at my first post in this thread and saw "65" where I thought I typed "75".

R_DKey is R75.

ElizabethD wrote:If R78 in 7800 is the R_Closures thing you once explained in the extender forum, then I don''t see that sort of code in the 8910 version.

Since you asked about R83 in the 8910, which is R78 in the 7800, I assume that code must use it for something.

Post by **ElizabethD** » Tue Apr 19, 2005 1:38 pm

johnsfine wrote: Since you asked about R83 in the 8910, which is R78 in the 7800, I assume that code must use it for something.

oops!
Correct assumption. Reality somewhat different which of course I didn't tell you:
8910's R_DKeyCnt=R83 is declared but not used.
It appears to be unnecessary as L/DKP works great as is.
Since I saw it in the declarations, I asked for it, in case I need it for 7800.
The name sounded like it might fall under the R_Closures concept.

Post by **ElizabethD** » Thu Apr 21, 2005 9:48 am

I think I need more information, please

1. Keymove bytes end up in DCBUF (R03) area when the keymove is being processed. Is there a way for me to see the actual, IR-supplied, keymove bytes and not the copy in DCBUF?
2. Is there a place where 7800 keeps the defined number of bytes (or an index to the current byte) while it processes that keymove?
3. What's in R01 and R02? Interested only if has to do with keymove, timers, keyboard scan.

Post by **ElizabethD** » Thu Apr 21, 2005 5:09 pm

Nils' 8910 L/DKP+DSM can work in unextended C7+ (7800).
It's now running

But not very convenient - assemble for use!

I know what's needed to make it work:
I have to be able to use the 3rd byte defined by IR, and NOT what's in DCBUF+2 for this one line of code: LD R_LastKey, DCBUF+2 where R_LastKey=R77.
I don't know how to code it.
With a hard coded key number, it works great.

The trouble seems to be with DCBUF area NOT using all the bytes defined in the IR keymove, i.e. 3rd byte is left behind. Not timers, not flags, not the key scan routine.
It does need R_Closure adjustment for double press, which is I what I want most to work besides DSM which always did.

mtakahar · Post by **mtakahar** » Sat Apr 23, 2005 11:04 am

ElizabethD wrote:Nils' 8910 L/DKP+DSM can work in unextended C7+ (7800)

Actually, David originally wrote it for 2116.

The trouble seems to be with DCBUF area NOT using all the bytes defined in the IR keymove, i.e. 3rd byte is left behind.

Those old s3c8 remotes don't support 3 bytes or longer key moves. What you can do is to put the control byte in the device upgrade and remove it from the key move.

To do this, change the 3rd byte of the protocol from 03H to 12H (1 fixed, 2 variable) then append the control byte after "F9 00 01" in the device upgrade. This way, the fixed data byte goes to R03 and the key move bytes to R04 and R05.

Hal

Post by **ElizabethD** » Sat Apr 23, 2005 3:26 pm

mtakahar wrote:Those old s3c8 remotes don't support 3 bytes or longer key moves. What you can do is to put the control byte in the device upgrade and remove it from the key move.

Hal, thanks. This explains what I saw.
The deal is this is a triple protocol and that 1st of 3 bytes controls which section of code runs (DSM, LKP, DKP), so it's a variable. I may, of course, be misinterpreting the whole thing. But I sort of have a planB for access to the original keymoves, so I'll take it from here but may need one more help cycle.
I have a planC which stuffs 3 bytes into two but is worthless because it would make the keymoves so nonstandard we'd never know how to use it.

Edited later:
On first quick reading I missed the device editing. I get it, I think.
I suppose three devices can be built all running off the same triple-job protocol. Cool

Post by **ElizabethD** » Sat Apr 23, 2005 9:47 pm

The jp1 tools amaze me more and more every day.

John, thanks for all your help, sorry to have kept you so busy on this one.
Nothing can be done without knowing the key locations.

Hal, your scheme works

and I've learned few things along the way.

One restriction: the keymoves have to be built the old way but for 2 keys that's not a big deal.

I tripped on using the same protocol# 01 f9 which IR understands only too well but doesn't know that I fiddled with it.
I guess that when the [Special protocols] section is in the RDF, IR is not allowing to get rid of/build without the control byte. And if the, now superfluous, control byte is in the hex stream, the third byte is ignored as before.

I know there is a limit of 1FF. If anyone is keeping tabs on what numbers are free to use, I'd like to know. I can upload this job, but not with the 1F9 number.

Can someone move this thread to General? I realised the other day that it really doesn't belong here.

mtakahar · Post by **mtakahar** » Sun Apr 24, 2005 12:18 am

I think 1F9 is just fine. You are seeing that behavior because you added ULDKP to your RDF, and ULDKP (nor multibyte LDKP) is incompatible to the version you created and impossible on this remote anyway. Just get rid of the ULDKP entry from your RDF.

Since you made this far and seem to be enjoying playing with the assembly code, maybe you can try writing the extender for C7+. 1994ex5 would be a good starting point since these two remotes are somewhat close.

Hal

Post by **ElizabethD** » Sun Apr 24, 2005 12:10 pm

mtakahar wrote: maybe you can try writing the extender for C7+.

No way. Too rough.
Besides, I'm off the hook. It's been done already

, loooong ago. It's splendid. I've been using it for couple months. Much faster than in the 8910, I don't know why.
This L/DKP was just a curiosity diversion - small, simple, debugged. Yet it was challenging enough for me as you can see.

What C7+ really needs is L/DKP for ext2 setup.
Way over my head. No source to ext2 exists, no declarations, nothing. And debugging without break points and without seeing the state of the remote is nearly impossible. I don't know how you guys have managed to put out so much good code. It's sort of like coding the Hubble telescope or something out of sight