JP1 Remotes

If you liked that, go unhide all the sheets in KM Master and look around

KM flat out impressed me the minute I opened it up, and I haven't even un-hid anything. My ability to do anything with a spreadsheet stops right about around =SUM(A1,A2) for complexity.
You guys are doing things with Excel that I had no idea was possible, so I'll leave any spreadsheet work up to yall (yeah, I'm a southerner). Now on the other hand, if you ever come across a need for a spreadsheet to add two cells together and display the results in a third cell, I'm your man.

Ironbreeze wrote:KM flat out impressed me the minute I opened it up, and I haven't even un-hid anything.

If you do start unhiding stuff, start with the EFCw sheet!

Ironbreeze wrote:...if you ever come across a need for a spreadsheet to add two cells together and display the results in a third cell, I'm your man.

We'll keep that in mind!

Now, if you could write a spreadsheet that would look for things like the formula you spotted for this keyboard, please step forward! I'd still love to know what to look for to spot checksums that use ADD.

I skipped explaining how I figured out the formula, because quite frankly I didn't think anyone would really care. But I'll run through it since it very well may help you or someone else here be able to spot another one in the future. And you may be able to incorporate some of the methodology <sp?> in a spreadsheet, or some other automated method. Of course I don't think it would be possible to automate all of it, but maybe some of it none the less.
ok here goes...
The first thing was to order and group the samples by the validation code to see if a pattern was obvious. And keep in mind this is prior to realizing this was a LSB first format, so it wasn't truly in order, but still helps. The ones I put an asterisk by stuck out because if A=B then C=A (C being the validation nibble). Which meant that an AND was probably being used. But AND alone didn't work for all of the samples, so we needed something else. XOR would be a perfect candidate because whatever we had left to do couldn't interfere with the AND of the situations where A=B. And of course when you XOR a number by itself it always comes out 0 which we could ADD, SUB, OR, or AND and it wouldn't change those results that we already have working. So to test this I grabbed some samples who's AND came out 0, and therefore probably wouldn't impact the XOR results. Well that was a definate pattern, and from there we can see that the XOR results just need to be ROL by 1 bit. Now we just needed to figure out how these two results (the AND and the XOR) are combined when neither are 0.
I tried the obvious of AND,XOR,OR,ADD etc but none yeilded the correct results.
So the first thing I did was take the right most bit of the AND and XOR results to see what the different combinations would yield,
if it was
0 0 = 0
0 1 = 1
1 0 = 1
1 1 = 1
then its probably an OR;
if its
0 0 = 0
0 1 = 0
1 0 = 0
1 1 = 1
then an AND;
if
0 0 = 0
0 1 = 1
1 0 = 1
1 1 = 0
then probably an ADD, etc
But this is where the confusion set in, none of the bit combinations resulted in a recognizable pattern. So that lead me to reason that there was interference from another column by (most likely) a carry bit. And since ADD causes carry bits (actually so does SUB, MUL, DIV but hopefully you wont have to deal with these very often). Now the only way a carry bit can effect the right most bit is if this is in LSB-MSB order. Which ended up being that missing link, so then when I did the ADD as a LSB-MSB the results came out right (except the one I screwed up ).
So if you want to incorporate some of this in an automated way, I'd suggest checking for a known combination on the right most bit (which shouldn't be effected by any other column in a MSB-LSB number) and if that doesn't yeild one of the known combinations try using the left most bit which won't be effected in a LSB-MSB situation.
Since there is virtually an unlimited amount of things you can do to 2 set of numbers to get a result set, testing all possibilities would be impossible. But luckily since the remote guys are limited by memory and clock cycles, they'll keep it to these simple operations.
I hope some of this helps you come up with a few ideas to implement. Even if not, I enjoyed reminiscing about the day I actually figured something out.


I'm off for the day,
so have a good one.
IB

I tried creating a custom protocol to generate the complicated checksum for this keyboard, but I couldn't get it to work correctly. The signal generated was all 1's. I ran out of time to dig into this any further, so I've posted my files in the Diagnosis Area in case anyone else wants to take a look: keyboard.zip

I haven't had time to look at it much (been very busy here today). But I gather that you're using the right bit of the command to represent the make/break bit, and dropping the left bit to make room for it. Might as well, it appears to always be 0 anyway. But the code doesn't seem to right shift the command back into it's correct place and appending the 0 to the left before doing the calculations on it. should be...
also since the bits haven't been reversed at the point of the rr of the xor result... I think that it should be... I may be completely wrong, I have no way to test these changes, not to mention my understanding of what your doing may be way off.

ps. That reverse sub is a work of a pure genius. I would never have believed that bits could be reversed with so few opcode bytes.

Anyway, hopefully this helps
IB

Ironbreeze wrote:I haven't had time to look at it much (been very busy here today). But I gather that you're using the right bit of the command to represent the make/break bit, and dropping the left bit to make room for it. Might as well, it appears to always be 0 anyway. But the code doesn't seem to right shift the command back into it's correct place and appending the 0 to the left before doing the calculations on it.

Actually, here's how I was trying to do it. Rather than define the signal as using a 5-bit device, 8-bit command and 4-bit checksum, I set it up as 5-bit device, 7-bit function and 5-bit checksum. So once control is passed to the engine, it will only take the 7 leftmost bits from the command (R04) and ignore the right bit. It will get the rightmost command bit from the first bit of the checksum, which I do make sure is the right value.

The reason I did it like this was so that I could use one XOR to set up the BREAK signal.

However, now that I'm re-thinking it, I realize that I do need to clear that bit before I load R04 into the registers that I'm using to calculate the checksum. I just updated the zip file with a new version of the code that does clear the make/break bit.

At any rate, I think there is a problem bigger than whether my code calculates the correct checksum because I'm seeing all 1's regardless of what device and command codes I use. My next move (when time permits) is to try Jon's original 2-byte upgrade to see if that works, as that's what my code is based on.

Ironbreeze wrote:ps. That reverse sub is a work of a pure genius. I would never have believed that bits could be reversed with so few opcode bytes.

Why, thank you sir!