JP1 Remotes

I just acquired a URC 8550 Topline 8 very cheap, so of course the first thing Ive done is plug in the JP1 cable and do a download to IR. (Signiture is ET80ET80 for which two RDFs exist, for normal and extended)

I've now got a few warnings/problems to try and resolve. The first 2 maybe related.

(1) I've got a bad checksum at $0700 error.
From the RDF it looks like that area is used for the timed macros, so I thought I'll setup a timed macro on the remote and try again.
I did this and still have an error. "Bad Checksum at $0700. Expected $34 $CB but found $08 $F7", I can't see any easy relation between the checksum stored and IRs valid checksum. Any ideas?

(2) Fixed data conflict.
The RDF contains the following:

$00A = $3B $00 $FF $00 $FF $04 $FF $06 $CE $07 $CE $07 $CE $07 $CE $07 $CE $07 $FD $07
$7D1 = $45 $54 $38 $30 $80 $0B $00 $0C $01
$7E2 = $08 $A2 $02 $BD $37 $01 $95 $B9 $CA $10 $F8 $A2 $04 $BD $3A $01 $95 $A9 $CA $10 $F8 $20 $0F $88 $28 $4c $64 $88

For the first part of this the bolded part are all actually $FD $07 in the download image. This may then be related to problem (1) since the checksum failing is +$700:$702..$7CE (i.e. $CE $07), but there is another checksum +$7CF:$7D1..$7FD which is valid.

The $7D1 fixed data is all actually $FFs in the downloaded image.
The $7E2 fixed data is also mostly $FF in the download image.

(3) Problem with key translation in IR/RDF
As part of (1) I setup a timed macro. In the Image I can see the sequence. $1C $14 $0C $1D $15 $0D $1E $06 $0E, which relates to the macro of 1;2;3;4;5;6;7;8;9 I put in. These also appear to relate to the values in the buttons section of the RDF. However IR is decoding this as (;2;3;T8;5;6;);8;9. Which looks then like a problem with the rdf line
Which is either wrong, or IR is not handling properly.

Any comments suggestions to try and get this fully working?

Anyone no the full reset sequence for this remote?

Thanks,
Paul.

Writing that may have helped with me with some of the problems.

There seems to be a "feature" in IR which means when there is multiple fixed data or multiple checksums it only flags up an error about the first. For checksums it fixes them all, for fixed data if you say "yes" to fix the first one, it fixes all of them otherwise it fixes none of them.

there is another checksum +$7CF:$7D1..$7FD which is valid.

So this comment is actually wrong, the checksum is getting automatically filled in by IR.

Removing that final checksum and modifying the $700 one to go up to $7FD removes the checksum errors, not sure if this is correct though...

IIRC, the RDF was modified (probably by Jason) as part of the "with Time and HT Support" that you see in the "Name" line of the RDF. I think if you were to accept all the RDF settings, including the one you quoted above, you would find that your remote retains it's clock and HT settings even after a JP1 upload.

The true Timed Macro area does indeed stretch from $0700 thru to $07FD as your download implies, but we have carved away a small slice of that area for the code that retains the settings.

Hopefully Jason will come along and explain better.

Thanks Rob,

I was getting close to concluding it must be something like that.

I'd manually entered enough timed macros to show they went upto 7FD, but had noticed that the HT devices and Time were recorded as being in that area by the RDF and that the HT devices and time got reset every time I downloaded from IR...

The memory layout in these "Producer 8" clone remotes is actually user configurable. Unfortunately, IR was never setup to allow you to configure them using some easy GUI. But regardless, if you wanted to expand one section and reduce another, you can do so. As you already noticed, much of the fixed data is the end addresses of each section. If you change these, and adjust the checksums accodingly, you can change the memory layout.

I've not looked into Jason's code for the clock and HT stuff, so I don't know if the code itself needs to be changed if you re-locate it, but I'm assuming it does.

pgk wrote:I just acquired a URC 8550 Topline 8 very cheap, so of course the first thing Ive done is plug in the JP1 cable and do a download to IR. (Signiture is ET80ET80 for which two RDFs exist, for normal and extended)

I've now got a few warnings/problems to try and resolve. The first 2 maybe related.

(1) I've got a bad checksum at $0700 error.
[...]
(2) Fixed data conflict.
The RDF contains the following:

$00A = $3B $00 $FF $00 $FF $04 $FF $06 $CE $07 $CE $07 $CE $07 $CE $07 $CE $07 $FD $07

This range of data tells the remote where each of the ten memory regions (region0 through region9) ends. Each address is two bytes (least signigicant byte first). So the end of region 0 is $003B, the end of region1 is $00ff, the end of region2 is $04ff, etc.

The bolded section changes the end of regions 4 through 8 from $07FD. This gives us a few bytes for region 9. The remote is set up to check for region 9, see if it has a valid checksum, and contains a 4 byte signature that cooresponds to the remotes signature (in this case ET80). If this is the case, then code in that region is executed. This is only true for region 9, not for any other region.

This code is in the next two fixed data sections:

$7D1 = $45 $54 $38 $30 $80 $0B $00 $0C $01
$7E2 = $08 $A2 $02 $BD $37 $01 $95 $B9 $CA $10 $F8 $A2 $04 $BD $3A $01 $95 $A9 $CA $10 $F8 $20 $0F $88 $28 $4c $64 $88[/quote]

I think what's happening is the following:

You haven't allowed IR to change the fixed data at $00A.
Therefore, your remote still thinks that timed macros go up to $07fd.
And the last checksum is invalid because:
the remote is calculating the checksum on $702 to $7fd
but the RDF is calculating the checksum on $702 to $7ce.

I also think that Rob's suggestions are correct. Namely:

Open IR.
Download from remote.
Accept the changes to fixed data
Upload to the remote.

You should now see the correct time on your remote. If you download again, you shouldn't get any fixed data errors.

Thanks it's all working now (except can't seem to get the extender working, I'll post on that separately once I've played some more).

You are right, my intiial reaction to the IR was to look into why rather than just let it fix it, probably a good case of a little knowledge being dangerous...

pgk wrote: (3) Problem with key translation in IR/RDF
As part of (1) I setup a timed macro. In the Image I can see the sequence. $1C $14 $0C $1D $15 $0D $1E $06 $0E, which relates to the macro of 1;2;3;4;5;6;7;8;9 I put in. These also appear to relate to the values in the buttons section of the RDF. However IR is decoding this as (;2;3;T8;5;6;);8;9. Which looks then like a problem with the rdf line

Code: Select all

"pip on/off":(T8)-PIP{Freeze}=$32, "pip move":(T8)-PP{Move}=$23, "pip swap":(T8)-NORM{Swap}=$1B, (T8)-FREEZE=$B2, (T8)-MOVE=$A3, (T8)-SWAP=$9B,

Which is either wrong, or IR is not handling properly.

Any comments suggestions to try and get this fully working?

In the RDF remove the brackets () from round all occurances of ( T8 )