JP1 Remotes

I wonder if there is a problem here or if it's me.
When I paste this out of PB or notepad into the Notes section in KM

Upgrade protocol 0 = 01 34 (S3C8) JVCp0134 (PB v3.11)
42 8D 11 8B 14 85 59 08 08 01 06 00 F2 01 06 02
FF 2E 24 10 68 08 20 FF 06 8D 01 33
End

This comes out:

Upgrade Protocol 0 = 01 34 (S3C8) Custom Protocol for DVD/1559 JVC-dvd-XVS502SL-forC7ext2 (KM v8.31)
42 8D 11 8B 14 85 59 08 08 01 06 00 F2 01 06 02
FF 2E 24 10 68 08 20 FF 06 8D 01 20
End

I don't think KM has anything against 33 'cause I can put it in other positions and it remains 33.
Just this last byte of a jump address gets clobbered.
If it's me, please tell me where to fix my ways.

Many jump addresses are supposed to get clobbered.

There are two versions of the S3C80 chip being supported here.

The basic system is that PB and other chip-independent sources always generate code for the newer S3C80 chip.

KM and RM recognise when you are taking a protocol executor from the new S3C80 chip and using it in the old S3C80 chip and they make certain adjustments to the code that usually correctly transform a new-chip executor into an old-chip executor.

When we first built PB, we didn't set it up this way, so PB had the ability to generate new or old S3C80. I haven't checked whether that is completely gone from PB. I hope so, because I think KM or RM will assume the incomming protocol is always new S3C80.

Bottom line, if you go back to PB and change the Remote Type to S3C8+ (new), you'll be good to go.

johnsfine wrote:When we first built PB, we didn't set it up this way, so PB had the ability to generate new or old S3C80. I haven't checked whether that is completely gone from PB. I hope so, because I think KM or RM will assume the incomming protocol is always new S3C80.

It's not gone in PB, but unlike KM & RM, it can now translate from/to old/new in both directions, as long as it knows what the starting point is. However, you are correct that PB should be set to create an S3C80+ protocol when it will be copied into KM or RM using manual settings.

Very interesting. Not sure I understand. But it clearly works that way and explains why I had a devil of a time adapting a good protocol.

I do now see that when I paste a S3C8+ protocol into KM it changes jump address and S3C8+ to S3C8 as well. Is that what your answers are about? This is precisely the desired effect?

If yes, this opens a new can of worms for me, amplified by this:

mr_d_p_gumby wrote: ... PB should be set to create an S3C80+ protocol when it will be copied into KM or RM using manual settings.

My reading of the answers makes me conclude that:
If I intend to go through KM, I should tell PB wrong remote.
If I intend to go directly to IR, I have to tell PB correct remote.
Is that the intention? I must be missing something again.

KM expects home-made protocols to be S3C8+, it will then convert them to S3C8 if needed. So, you should select S3C8+ when creating the protocol in PB and copy it over to KM like that. Then, if you select the 15-1994 (for example) in KM, it will convert addresses like 01 46 to 01 33, and if you select the URC-6131 (for example) it won't.

01 33 is a valid address for an S3C8+ protocol but it's not for the IR engine (which is what the 01 33/01 46 address is for), so KM will convert it to 01 20 if you select an old remote like the 15-1994.

ElizabethD wrote:If I intend to go through KM, I should tell PB wrong remote.

It's not that you set PB for the wrong remote. Remember that KM has to support both types of S3C8s, and in order to simplify things for protocol authors, we standardized on using the S3C8+ versions in these cases. That way, the author does not have to create both versions. As Rob says, KM can convert it to the old version when needed.

Another little known aspect of using home-made protocols in KM is that the comments block can simultaneously contain protocol code for P8/740 and both 6805 types, in addition to the S3C8+ code. KM will select the correct code based on the selected remote. (I have not checked, but I doubt that RM can import the multiple protocol types.)

If you have an S3C8 (old) protocol and need to convert it to the S3C8+ (new) type, you can do this in PB. Copy the old code into the Decode block, click Decode. Go to the assembler tab, click Load Disassembly, then click Assemble. Go back to the Setup tab, and check the Use Assembled Protocol Code box. Set PB for S3C8+ (new), and it will output an S3C8+ version.

mr_d_p_gumby wrote:I have not checked, but I doubt that RM can import the multiple protocol types.

It does.

gfb107 wrote:

mr_d_p_gumby wrote:I have not checked, but I doubt that RM can import the multiple protocol types.

It does.

Good. I was worried that you had not seen an example of this to test the import. Or, to put it another way....

Capn Trips wrote: COOL!!!

mr_d_p_gumby wrote: ... As Rob says, KM can convert it to the old version when needed.

The history and how you manage this helped a lot. Simple. I understand. Thanks.

mr_d_p_gumby wrote: Another little known aspect of using home-made protocols in KM is that the comments block can simultaneously contain protocol code for P8/740 and both 6805 types, in addition to the S3C8+ code. KM will select the correct code based on the selected remote.

I actually saw that in the readme and used it. Neat trick. it works too.

mr_d_p_gumby wrote: If you have an S3C8 (old) protocol and need to convert it to the S3C8+ (new) type, you can do this in PB. Copy the old code into the Decode block, click Decode. Go to the assembler tab, click Load Disassembly, then click Assemble. Go back to the Setup tab, and check the Use Assembled Protocol Code box. Set PB for S3C8+ (new), and it will output an S3C8+ version.

I saw that as well though it took few trials to do it correctly first time. I used it going from S3C8+ to S3C8 and back. PB is amazing.

Thing that got me, was not knowing that KM expects the recent stuff. And at that time, while seeing the jump address was being changed, I just wasn't sure what was going on in the absense of memory maps and lack of any experience with these register things. It all really started herewhere I never got an answer about WHY only extended C7 was doing me in till the signal values got changed. I still hope there is a rational explanation.

ElizabethD wrote:it works too.

Of course it does!

Thing that got me, was not knowing that KM expects the recent stuff.

Maybe I need to add something to KM's readme?