Some rambling thoughts.....
Taking a look at the bytes, there's basically only a hunk of 10 or so
bytes in the middle that changes between the three Ir commands (1,2,3).
What would be handy is doing a i2c capture of a well known IR protocol
from the JP1 worksheets for the keys 0-10 and cross referencing them
back together. Would also be nice to find two protocols that only
differ in carrier frequency (38 & 56 kHz) and see what changes.
Just a thought, but the bytes in the i2c capture wouldn't be Zilog Z8
op-codes would they? (I believe all Ir functions are handled by the
dedicated Z8F0811 MCU). Obviously the 100 odd bytes isn't the the full
Z8 program, but it might be a mix of IR protocol configuration and a
handful of jump offset's.
Can we do any fancy FLASH reading/dumping on the Z8 via the i2c ?
# Endaf
Mark Weaver wrote:
What I notice is this appears to be an upload into registers 01-63,
followed by an "execute" command. Note the first byte in the addr 70
writes is 01, then it sends 4 bytes, the next write starts at 5, goes
4 bytes, etc until it writes 0x61-0x63. Then it sends a 0x40 to
register 0, which is probably an some sort of "prepare". Then it
reads reg 0 until it changes to 0xa0, which I'm guessing means the
blaster is ready to send. Then it sends 0x80 to register 0, which
I'd assume is execute. It then polls register 0 until it changes can
read back that 0x80.
Thanks -- that's very helpful. As that's a basic send procedure I can
now at least extract all of the hauppage provided codes (I have
written something to prod a component of their software into sending
these), so if it doesn't prove possible to decode the data blocks it
should at least be possible to make it work with the same set of
devices that the windows version works with. Obviously the problem is
the need to redo the procedure for new codesets as they arrive, but
it's better than nothing.
I don't know wtf is going on on address 0x71, but I think those can
be safely ignored.
I believe this is the IR receiver being polled.
Now, what's in that block? Well the first byte is the length of the
block. The rest is a big ? for now. You might want to run some
scripts against the dumps and have them dump out the data blocks in a
line so it is easier to compare them for similarities.
I will do a capture on all the codesets/keys and produce a database,
but even between keys 1 and 2 on one codeset there are 18 bytes
different so I'm not optimistic about working out what actually lives
in there.
Thanks,
Mark
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
ivtv-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ivtv-devel
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
ivtv-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ivtv-devel
