JP1 Remotes

I've written a executor that should be able to send the signals that you need using just 2 variable data bytes. Do you have the ability to verify what the remote is sending and maybe make adjustments if the signal is incorrect? I ask because I have absolutely no expectation that this will work the first time and I haven't tested it.

The following zip file contains a KM upgrade, the PB file and a spreadsheet that shows how I'm looking at the data.

https://www.hifi-remote.com/forums/dload ... le_id=6024

First off, I had to reverse your view of the data, so a 1 is now ON and a 0 is now OFF.

Separating the start and stop bits, the 12-bit signal looks something like this...

1-000000000-11

I can replicate the start bit by using a leadin pair of "+630 -0" and I can replicate the stop bits with a leadout time of +1260. However, that still leaves 9 data bits, so to reduce it to 8 I included the 9th data bit in with the leadout.

The 9th bit of the first 4 words is always 1, and for the rest of all the signals it's 0, so, the format of the first 4 words is:

1-00000000-011

and the remaining words:

1-00000000-111

To switch from format1 to format2, I had to change the leadout from "OneOn, -1260" to "-1890".

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.

If you look closely at the data in the 2nd byte, bit2 is 1 for the 3 short signals and it's 0 for the 3 long signals, so I use this for that purpose in the executor.

You'll notice that bytes 6 thru 15 are all $FF for the "download" button, and you'll also notice that bit4 of the 2nd byte is 1 for the "download" button (it's 0 for all the others), so I use this to format the download signal in the executor.

Unfortunately, there's nothing to differentiate between the 2 "start" buttons so I faked something. I set bit0 of the 4th byte data for the 2nd start button in the KM data, then in the executor I use this to differentiate between the two, but I always reset it to 0 in executor.

6 of the bytes used for the two start buttons are constant, only 4 are different.

Hopefully this made some sense, so if it doesn't work, you can have a crack at fixing the executor in PB.

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 Robman wrote: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's not. It just happens to be in the code I posted earlier. There are actually 3 different types of signals:

1) This signal is 5 bytes long, with the first 2 bits of bytes 1-4 being constant. Bit 9 is 0 for bytes 1-4 and 1 for byte 5.
Byte 1: 11xxxxxx 0 - We only care about the 2 MSBs; the other 6 don't matter.
Byte 2: 00nnnnnn 0 - 2 MSBs will be 0, other 6 are variable.
Byte 3: 01nnnnnn 0
Byte 4: 10nnnnnn 0
Byte 5: nnnnnnnn 1

2) This signal is up to 16 bytes long, with the first 5 bytes being the same as signal 1) and the rest are like byte 5 of signal 1).

3) This one is a bit different. Like 1), it is 5 bytes long, but byte 1 and most of the 9th bits are different:
Byte 1: 10101010 1 or 11111111 1
Byte 2: nnnnnnnn 1
Byte 3: nnnnnnnn 0
Byte 4: nnnnnnnn 0
Byte 5: nnnnnnnn 0

Here are more examples of each. I use HH/b to write it, with HH being the 8-bit byte and b being the 9th bit.

1)
FF/0 04/0 7F/0 C2/0 CB/1
FF/0 08/0 7F/0 99/0 FA/1
FF/0 18/0 7F/0 A8/0 55/1
FF/0 1C/0 60/0 85/0 82/1
FF/0 1C/0 61/0 80/0 DA/1

2)
FF/0 2A/0 7F/0 87/0 crc/1 85/1 DA/1 C2/1 63/1 AA/1 5F/1 23/1 11/1 E3/1 crc/1
FF/0 2B/0 7F/0 84/0 crc/1 A3/1 86/1 0A/1 12/1 crc/1
FF/0 30/0 7F/0 8A/0 crc/1 00/1 00/1 00/1 00/1 00/1 00/1 00/1 00/1 00/1 00/1 crc/1
FF/0 38/0 7F/0 8A/0 crc/1 53/1 00/1 0F/1 0F/1 47/1 98/1 00/1 2C/1 01/1 00/1 crc/1
FF/0 38/0 7F/0 8A/1 crc/1 53/1 00/1 03/1 01/1 20/1 4A/1 00/1 2D/1 01/1 01/1 crc/1

3)
55/1 BF/1 10/0 08/0 F2/0
55/1 BF/1 0C/0 A9/0 DF/0
FF/1 C1/1 12/0 2C/0 CE/0
FF/1 B3/1 00/0 FF/0 B7/0


I'm afraid there really is no way around it; if I'm to use Shift, XShift, or an extended key then I need to break it up into multiple keys and use a macro to piece it back together. I'll have a look at your executor and see if I can use it to at least make entering these sequences a bit easier.

/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: Ok, now I'm really confused. How does $0146 know how many bytes to transmit? The 'stock' protocol only calls it once... Which brings up another question; since the transmit buffer is in R03-R0A, does R00-R02 hold the pulse width, frequency, and byte count? I noticed you put part of the start signal in R0B/C, but will this work with the 64-bit limit this uC has? (this 64-bit limit was mentioned in one of the readme files; I tried exceeding it and the remote didn't transmit anything). Is there a file somewhere around here that maps registers to their functions? I would like to know what the different registers do. I can already imagine some neat things if I can control the device button LEDs and the backlight; some really really really complex ToadTOG functions could be created if you had some feedback from the remote letting you know where in the sequence you are. Are any of the registers persistent across multiple button presses? Anyway, that's a project for a different day; back to creating huge macros! lol.

/LW

Edit: And a start code: E3 AF 19

You see now why I asked for the complete list of hex codes earlier. Before I attempt this again, could you please post the absolute complete list of the hex codes that you need to replicate (and if the data in any of the bytes doesn't matter, mention which.

Where are you getting the data that needs to be sent? Are you aware of any rules encoded into the data? (eg, if this bit is a 1, that bit will always be a 0, etc)

I think there is something somewhere that expains all the register usage, etc but I don't recall where it is. It's all engraved in my memory so I don't really need it.

In this case, the $0146 routine doesn't know how long the complete signal is, because I'm pretending that this is a 1-byte signal with leadin (for the start bit) and leadout (for the stop bits) portions. I'm calling the $0146 once for ever byte that needs to be sent.

If you were to attempt to send the signal all at once, you would be limited to 10 bytes of data (ie, R03 thru R0C).

Here's a (from memory) list of all the relevant registers:

R00 - button press count
R01 - skip # of fixed bytes
R02 - don't remember
R03-R0C - protocol input data
R0D - minimum # of repeats required
R0E - carrier freq - part1
R0F - carrier freq - part2
R10 - # of fixed bytes
R11 - # of variable bytes
R12 - # of bits per fixed byte
R13 - # of bits per variable byte
R14-R24 - internal protocol data (this is where the burst pair times are stored)
R28-R2A - protocol control bytes

The Robman wrote: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

How do you know what data to use? There must be a finite list of commands that you need to program into your remote.

How many bits/bytes are in each of the following:
<break> <command> <ID> <data>

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. I fully expect to still be working on this 6 months from now...

Oops, I forgot the <crc>. The long ones also have up to 10 additional <data> bytes plus another <crc>. Each "byte" is 9 bits long. Like I posted above,

<break> <command> <ID> <data> <crc> [<additional data> <crc>]

break: 11xxxxxx 0
command: 00nnnnnn 0
ID: 01nnnnnn 0
data: 10nnnnnn 0
crc and everything after: nnnnnnnn 1

Edit 1: Do you know if there's a flag that you can check to see if a button's still held down?
Edit 2: Wow, I just found your post in the Acer Keyboard thread, and I think it explains just about everything That post and the note about CALL 010AH / JRC a few posts up really should be in the assembler help file... I think R2C might help here.

/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 call $0146 after setting the data length registers appropriately.

* there are only 3 "prefixes" with the long data: "FF/0 38/0 7F/0 8A/0 crc/1 53/1 00/1" "FF/0 2B/0 7F/0 84/0 crc/1" and "FF/0 30/0 7F/0 8A/0 crc/1 00/1 00/1" The remaining data is at most 9 bytes long once these are removed.

To save space, I'll then write another executor that takes exactly 5 bytes, with the first byte telling it which break and 9th bit style to use.

By doing it this way, I will not need to use any key moves or macros thus making the 2-byte key move limit is a non-issue. This will also allow repeating as I can call $010A and loop as needed.

I think it's time for me to get coding

Is there a way to make it transmit LSB first? This way I can punch in exactly what it should come out as. I guess I could always RRC/RLC it myself if I really want this...

Oh, are any of the working registers reserved for anything? I noticed you started with W5.

/LW

You can reverse the bits in the executor, but why waste code/memory doing that when you can do it in advance yourself? I can show you how to do it in Excel if you need.

W5 is the only scratch register that will survive a call to $0146, so if it's just some temporary work you can use any of them, but if you want the value to survive a $0146 call, you should use W5.

Also, regarding the keymove limits, you can always create "dummy" upgrades that have all the buttons that you need pre-coded, then you can do "key based" keymoves based on those upgrades (eg, copy the VOL+ button rather than entering hex codes).

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 got it to JP to the actual protocol just fine, but it hard locks when it calls $0146. Do you know of any way to switch the running executor without reloading the key values? I.E. I need a dummy executor that tells the remote to load 5 command bytes for the key, and once they are loaded it switches to the real executor. For now I have the same executor loaded twice with the only difference being the number of command bytes it expects. It's 191 bytes long and I've uploaded it if you want to look at it. It's definately an art to do so much in only 192 bytes! I think I ended up rewriting it at least 12 times... Is there a reason everyone JP's to $0146 to end it? I just RET'ed and it seems to work fine...

Oh, is there a list of callable functions around here? I see a few references to $0161 and another one that's a delay loop, but I can't seem to find a list. I'm thinking about just dumping and disassembling the core code, but it would be nice to have a starting point.

/LW

Lonewolf wrote: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?

The dummy loader concept would work if you were writing code that would reside in the ROM, but it won't work for an EEPROM loaded code because this code gets copied from the EEPROM to the RAM before it gets executed. Code that resides in the ROM gets executed in place, so in theory one executor would know the address of another executor and could make cross-calls.

Also, I hate to beak this to you, but AFAIK the 192 byte limit is an arbitrary limit created by PB itself (ie, it had to stop somewhere). If you think you need more space to create your masterpiece, you could try hacking the PB spreadsheet so that it lets you create longer executors.

The Robman wrote:

Lonewolf wrote: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 Robman wrote:The dummy loader concept would work if you were writing code that would reside in the ROM, but it won't work for an EEPROM loaded code because this code gets copied from the EEPROM to the RAM before it gets executed. Code that resides in the ROM gets executed in place, so in theory one executor would know the address of another executor and could make cross-calls.

That's one of the reasons I got the 15-133: it's flash based so there's no ROM or EEPROM, it's just 5kB (usable) of space! At least that was the impression I got... The call did in fact work in the upgrade space - if I put a return right before the very first $0146 call it would exit normally, but if I put it right after it would hard lock.

The Robman wrote:Also, I hate to beak this to you, but AFAIK the 192 byte limit is an arbitrary limit created by PB itself (ie, it had to stop somewhere).

Lol! This is good to know; I just assumed it was a remote limit as PB would still compile it but with the 'End' statement chopped off...

/LW

Lonewolf wrote:

The Robman wrote:Also, I hate to beak this to you, but AFAIK the 192 byte limit is an arbitrary limit created by PB itself (ie, it had to stop somewhere).

Lol! This is good to know; I just assumed it was a remote limit as PB would still compile it but with the 'End' statement chopped off...

FYI, there is a way in PB to get the assembled hex code out when it exceeds the 192-byte limit. If you click on cell H8 (to the right of the protocol output block), you can copy the entire assembled code and paste it into something else. You'll have to manually construct the header & End lines though, if you need them.