New protocols.ini entry for Acer Keyboard

As keyboards are such a pain to get replicate using a remote, they get their own forum. Hopefully having all the posts in one place will make it easier to find the solution.

Moderator: Moderators

Post Reply
jon_armstrong
Expert
Posts: 1238
Joined: Sun Aug 03, 2003 9:14 pm
Location: R.I.P. 3/25/2005
Contact:

New protocols.ini entry for Acer Keyboard

Post by jon_armstrong »

I converted a KM upgrade for the Acer Keyboard to RM. Included in the zip is the RM protocols.ini entry with a very good description from John Fine as to how the protocol and decoder work. I have commented that section out so it's not even in the notes that I think would confuse the average user but it seems like a good place to put it since some of the information was very helpful to create the ini entry.
-Jon
gfb107
Expert
Posts: 3411
Joined: Sun Aug 03, 2003 7:18 pm
Location: Cary, NC
Contact:

Post by gfb107 »

Thanks Jon. I'll include this in the next (1.00!) version of RM.
jon_armstrong
Expert
Posts: 1238
Joined: Sun Aug 03, 2003 9:14 pm
Location: R.I.P. 3/25/2005
Contact:

Correction for Acer Keyboard for protocols.ini

Post by jon_armstrong »

I set the wrong default value in the last version and reduced the lead-out off time in the protocol. Here is the correct entry in it's entirety:

[Acer Keyboard]
PID=01 11
DevParms=Device:4=15,Sub Device:3=3
DeviceTranslator=Translator(lsb,0,3,4) Translator(lsb,0,1,8,3) Translator(lsb,1,3,9)
FixedData=8E EC
CmdParms=OBC:7=0
CmdTranslator=Translator(lsb,0,7) XorCheck(1,7,0,7)
DefaultCmd=00
Notes=
# From John Fine's explanation of the decoder and protocol $01 11:
# Includes my initial kludge version of decoding this protocol. The OBC
# and Hex are based on ideas described below
#
# ...
#
# Bits
# 13 000 1111 110 110 (this was later changed to 0:3,D:5,S:3)
# 07 Key
# 01 Release flag
# 01 Check bit
# 03 110
# 07 ~Key
# 01 ~Release flag
# 01 Check bit
#
# If we wanted a hand coded protocol, we would prefer to keep the
# variable data down to 8 bits. The Check bit is a pain to compute in
# S3C80 ASM code (though possible if necessary) and I think we can get
# away with doing little or nothing with the Release flag, so in my
# kludge decoder I made the OBC be just the 7 bit Key and I made the Hex
# command be the 7 bit key plus the 1 bit check, skipping the release flag.
#
#
# Call the 7 key bits tuvwxyz.
# Call the inverted 7 key bits TUVWXYZ.
# Remember a '1' is just gap, so we can add a '1' on the beginning
# without changing anything.
#
# Call the whole thing five 7-bit bytes (with an 8'th bit that won't be
# transmitted shown on the right of each).
#
# R03: 1000111#
# R04: 1110110#
# R05: tuvwxyzc
# R06: 0c110TU0
# R07: VWXYZ1c0
#
# If we come in with just R03,R04 (fixed) and R05 (variable) set as
# shown. I think the following code would set R06 and R07.
#
# W0 0 ; Enable easier access to R00..R07
# LD R06, 6 ; R06 = 00000110
# LD R07, R05 ; R07 = tuvwxyzc
# LDB R06.3, R07 ; R06 = 0000c110
# RR R07 ; R07 = ctuvwxyz
# ADD R07, R07 ; R07 = tuvwxyz0
# COM R07 ; R07 = TUVWXYZ1
# RLC R07 ; R07 = UVWXYZ1c
# RLC R06 ; R06 = 000c110T
# RLC R07 ; R07 = VWXYZ1c0
# RLC R06 ; R06 = 00c110TU
# RLC R06 ; R06 = 0c110TU0
# W0 C0 ; Restore normal easy access to RC0..RC7
#
# Then just increase fixed bytes from 2 to 4 and jump to the main engine.
#
# This assumes we can send just press commands and never release. If
# that's false we could call the IR engine (while key down) instead of
# jumping to it, then invert the release flag:
# XOR R06, C0
# XOR R07, 6
# and finally jump to the IR engine.

Code.S3C80= 43 89 21 8B 0F 87 80 40 07 07 00 00 01 90 00 D2 00 BE 06 40 31 00 6C 06 78 05 47 77 06 E0 07 02 77 60 07 10 07 10 06 10 07 10 06 10 06 31 C0 E6 10 04 8D 01 46
-Jon
gfb107
Expert
Posts: 3411
Joined: Sun Aug 03, 2003 7:18 pm
Location: Cary, NC
Contact:

Post by gfb107 »

The update will be included in RM v1.00
Post Reply