JP1 Remotes

Do we need to do anything special (like deactivate before/reactivate after) when switching over from the beta?

/LW

That's all right, I was more interested in seeing which registers / functions did what, and I think I found it.

/LW

Unfortunately toggling R2C.2 didn't work out so I had to do it the hard way
What were you trying to do with R2C?
I was hoping to use it to prepend a 0 and append a 1 or 0, and it almost works if I reverse the one and zero times.

The dummy loader concept would work if you were writing code that ...

Well, I got it working. Unfortunately toggling R2C.2 didn't work out so I had to do it the hard way, and I ended up writing 1 executor that handles both the short and long codes as both share about 85% of the code. I was hoping to make a "loader" protocol for the short codes to save key space, and I ...

Is the source for the extender around here somewhere? I would love to see what makes it tick.

/LW

I got it! Since the 64-bit limit is not an issue if we call $0146 manually, I'll write an executor that takes up to 10 8-bit bytes, with the first byte telling it which prefix* to use and how long the data is. The executor will then add the lead-in, toggle R2C.2 as needed to make the 9th bit, and ...

Yes, I'm only putting a handful in the remote, but that list is constantly changing as I make tweaks. I don't even have a complete list of what I want in the first version of the remote put together yet; the data is coming from multiple sources and it's taking me a while to collect and organize it ...

the complete list of hex codes
There is no "complete list!" It pretty much goes <break> <command> <ID> <data> and while there are only a few commands, ID and data are both 00 - FF inclusive for 3) and 00 - 3F for 1). The long ones can be anything from 00 to FFFFFFFFFFFFFFFFFFFF.

/LW

Ok, after looking at the executor you sent me and coming up with a bunch of questions I decided to give it a shot anyway. Using E7 EA 55 as a test, the remote transmits: FF/0 08/1 7F/0 C0/0
new sig, last was 21 long
FF/0 08/1 7F/0 C0/0
new sig, last was 21 long
FF/0 08/1 7F/0 C0/0
new sig, last was ...

Yes, I have a USB dongle to capture signals and I wrote a program to decode them; it would be neigh impossible to debug this thing without.

The 1st and 3rd bytes are constant, so I have hard coded them in the executor. The 2nd, 4th and 5th bytes are supplied via the variable data. Unfortunately it ...

Zip file. Left and right arrows work as expected; shifted they do not.

broken_long_code-pb.txt - PB save file
broken_long_code-protocol.txt - PB output
broken_long_code.rmdu - RM save file
broken_long_code-upgrade.txt - RM output

/LW

So I go to put together a KM file for you as I have been using RM, and it turns our KM will not let you use Key Moves if the protocol is longer then 2 bytes (that whole sheet is grayed out). I'm not sure if I should call this a bug in RM or a lack of documentation... Do you still want to see the RM ...

Ok, now I'm getting somewhere: it seems Key Moves have a limit of 16 bits; only 'normal' keys can be 64 bits. Grrrr. Oh well, workaround implemented, macros functioning correctly. Now, if I could just get it to repeat the ENTIRE macro when you hold a button down it would be PERFECT! That and make ...

I'm calling it in a macro, but yes, while testing individual buttons I was hitting "P" twice. I've also tried with the Guide, Menu, Info, and phantom1 buttons with the same result; some of the gibberish changes depending on which button it's assigned to, some stays the same, and I do get a few 'good ...

Well, I've got it mostly working. Because of the size, I had to break it up into 4 different buttons and then join them back together with a macro. However, this is only working for non-shifted buttons; if I try to program something onto a shifted/xshifted button, I get gibberish. I'm using 6 8-bit ...