BASIC FEATURES:
===============

  You can put a Macro or KeyMove on any key.
  Macros can be Nested.
  Macros are fast.
  Very flexible device selection.
  Included special protocols for:
    Device Specific Macros
  Optional special protocols for:
    Pause, Device Multiplexer,
    ToadTog, Long/Double Key Press
  Optional second shift key.

  No direct keying of EFC codes on the remote.
  No long-press-setup functions.
  No Master Power functions.


EEPROM SPACE
============
  The Atlas DVR is supplied with a 1K-byte EEPROM, which imposes
  some limitations when using this extender. The unextended remote
  provides 226 bytes for keymoves/macros, and 761 bytes for upgrades.

  This extender uses as little of the EEPROM as possible, but
  unavoidably ends up providing less space for keymoves and
  upgrades. The available EEPROM space is apportioned as follows:

   365 bytes for keymoves/macros, using 24 bytes for the default
   device-key macros, leaving 341 bytes for other keymoves and
   macros.

   266 bytes for upgrades, using 30 bytes for the extender
   activation device & protocol, leaving 236 available for
   special protocols and user device & protocol upgrades.


INSTALLATION AND ACTIVATION
===========================

  See documentation in Install.txt

******************************************************************************
Without the extender, this remote handles key moves differently from most of
the other JP1 remotes, and does not support multibyte command key moves.
This extender enables multibyte key moves, however, does NOT support the key
moves created without the extender.  You have to convert all the key moves
manually if you choose to copy your settings created for non-extended remote.
******************************************************************************

SPECIAL PROTOCOLS
=================
  Because of the limited space available in a 1K EEPROM, the special protocols
  that are normally included with extenders for other remotes are not pre-loaded
  in this extender, with the exception of the built-in Device Specific Macro
  special protocol.

  However, the device upgrades and protocol upgrades are included in the individual
  files describing each protocol, and they can be installed in IR.EXE as required.

  This extender includes the following special protocol:

  TV/1103               = Device specific Macro
                         (Built-in pseudo device.  Not visible in IR.exe)

  Optionally, you may install any of  the following special protocols:

  TV/1101, protocol 1FE = Device Multiplexer
  TV/1104, protocol 1FB = Pause
  TV/1106, protocol 1F9 = Long/Double Key Press
  VCR/1800, protocol 181 = ToadTog

  See documentation for details on each individual protocol, and be sure to use ONLY
  the versions of the special protocols that are specifically for this extender.

  (The Pause protocol is described in the FAST MACROS section in this document.)

DEVICE SELECTION:
=================

  There is no normal device selection.  There is no VPT.  There is no
Transport Punch Through.  There is no Home Theater Mode.

  Instead there is a device selection mechanism by key set that has a
superset of the power of all the above;  But you must define macros to use
and customize it.

  The device keys have no built in meaning.  You must define macros to
have any device selection at all.

  There are 23 commands that can be used in macros to control device
selection.  Each command specifies the key set and the Device Index that will
be used for keys in that set.  For example V_TV says the TV device will be
used for keys in the "Volume" set.

  There are 4 Key sets: Volume, Transport, Other and Temporary(X).
There are 5 Device Indexes: TV, DVD, CBL, AUD, and AUX.  There is one
additional command X_Cancel.

  To achieve simple device selection (no VPT, TPT or HT) you would put a 3
command macro on each device key, for example the TV device key would have
the macro:
V_TV; T_TV; O_TV

You can use any keys you want for the device selection macros (and you can use
device keys for other purposes).

  To achieve VPT, replace the V_ command within the macro for each device
that should have VPT enabled with the command from the device to which VPT
should be set.  For example, to enable TV VPT on your DVD, the DVD key
macro might be:
V_TV; T_DVD; O_DVD

  If you want full VPT (same V_ selection in all device selection macros) you
can save some macro memory by omitting all the V_ commands.  You can set the
initial V device using IR.  That remains as the V device as long as no V_
commands specify a different V_ device.

  To achieve crude TPT (such as most of the UEIC remotes) replace the T_
command within the macro for each device that should have TPT enabled with
T_DVD.  For example, your TV key macro might be:
V_TV; T_DVD; O_TV

  To achieve dynamic TPT (similar to the URC7800).  Omit the T_ command from
the macro for each non Transport device and include it in the macro for each
transport device (VCR, DVD etc.).  When you select a non transport device,
the T keys will all remain associated with whatever transport device was
most recently selected.

  Shifted keys all go into the key set containing their unshifted
counterpart.  For example SHIFT-Stop is in the T set.  Phantom keys are in
the O set.  Device keys are in the O set;  But most people will put macros
on device keys.  If a key is a macro, it doesn't matter which set it is in.
The set only matters for KeyMoves and for keys defined by setup code.

Temporary Device Selection:
---------------------------

  Within a macro, you often want to issue a key to a specific device
regardless of the previous device selection and without disturbing that
previous device selection.  You use X_ commands to do that.  For example,
the sequence
X_TV; 0; 3
in a macro would send the 0 and 3 keys to the TV regardless of the previous
device selection.

  The X_ selection is automatically canceled when the outermost macro (see
nested macros) completes.  If the above example were intended for use as a
top level macro, there would be no need for it to explicitly cancel its X_
command.  If the above example were in a general purpose macro that might
be called by other macros, you probably should change it to:
X_TV; 0; 3; X_Cancel

  While an X_ command is active, it applies to all keys.  The usual division
into Volume, Transport and Other doesn't apply.

NESTED MACROS:
==============

  You can nest macros to any depth.  Any key that is a macro when used from
the keyboard is the same macro when used inside a macro.

  This is very different from the base remote and from other extenders.  Pay
careful attention to this detail when converting a configuration for use
with this extender.  There is no protection from infinite loops when a macro
nests into itself.

  Many people have used the fact that macros don't nest (in the basic remote)
for things like a Power macro that uses the normal Power key.  Find and
change anything like that in your configuration (see "Cloaking with Shift").

  There is a 32 byte macro buffer (vs. the 15 byte buffer used by SelNestMac
on other remotes).  That doesn't change the limit on an individual macro
(still 15 commands) nor does it set a limit on the total number of
commands executed by one macro (virtually unlimited).  It limits the number
of commands "pending" at any one moment.

  To understand "pending" commands, imagine 4 macros, A, B, C, and D:
A = B; C; D
B = 1; 2; 3
C = 4; B; 5; 6
D = 7; 8; 9
when you press A, you get 1 2 3 4 1 2 3 5 6 7 8 9, which is 12 commands, but
in executing those 12 commands, there were never 12 commands "pending".
When the extender processes the first B there are 5 command pending:
1; 2; 3; C; D;
Later it process the C and there are again 5 commands pending:
4; B; 5; 6; D
When it processes the second B there are 6 commands pending
1; 2; 3; 5; 6; D
The whole 12 commands are sent with a maximum of 6 ever pending.  You should
be able to design ridiculously long macros without ever hitting the limit of
32 pending commands.

FAST MACROS:
============

  I reduced both the hold time and the delay time for commands in a macro.  I
think that is necessary to make macros useful.  There are situations in which
you need to add back some hold time or delay time.

  For delay, you can use:

1)  For a very small delay, use a redundant device selection command.  If you
know that an X_ selection won't be in use at the relevant point in macro
execution, you can use a redundant X_Cancel as a tiny delay.  If you know or
use any other device selection, you can use it again as a delay.  For example,
if you want a delay between digits in the macro "O_TV; 0; 3" you could use
"O_TV; 0; O_TV; 3".

2) For a slightly longer delay, use an undefined key code. The actual amount
of delay will depend on the number of items in your KeyMove and Macro area.
For example, if you have no KeyMove or Macro for shift-X_Cancel, you could
use shift-X_Cancel as a delay.

3) For a long delay, use a KeyMove connected to the Pause protocol (TV/1104).
The hex command is the amount of delay from 01 (smallest) to FF.  The delay
is in units of about 0.4 seconds.

  For adding back hold time, I haven't provided anything in this version of
the extender, except for the last step of a macro.

HOLDING LAST STEP OF A MACRO:
=============================

  If the last step of a macro transmits a signal, and you held down the
original key that started the macro through the entire macro execution,
the extender will continue the last signal while that button is held,
just as the remote normally does for a signal that is the only action of
a button.

  This feature acts the same for ToadTogs and DSMs as for ordinary macros.
It acts the same for mini-macros (from a Fav list) as well, except that all
mini-macros are really exactly 3 commands long, rather than being 1 to 3
commands long as they seem.  IR.EXE pads any shorter mini-macros with NULL
commands to make them 3 commands long.  If a mini-macro is less than 3
commands, its last command is a NULL command, so holding the key won't make
a difference.  If you want holding the key to make a difference, try padding
the beginning or middle of the mini-macro with redundant device selection
commands rather than letting IR.EXE pad the end with NULL commands.

  In rare cases, you want to defeat this feature and avoid having the last
step of a macro continued if the user holds the key.  You can most easily do
that by adding an X_ command to the end.

SHIFTED KEYS:
=============

   Pressing the Setup key causes the next key to be "shifted".

   The shift only affects the lookup of the key as a KeyMove or Macro.  If no
KeyMove or Macro is found for a shifted key, the remote then checks whether
the unshifted version of the key is defined by the setup code.

   The Setup key only acts as a shift key when used from the keyboard.  When
used in a macro the Setup key is just an ordinary (O set) key.  When used
from the keyboard the Setup key is both a shift key and an ordinary key, so
you can get some confusing or interesting (depending on your intent)
behavior by defining a KeyMove or Macro for the Setup key.

   To use a shifted key in a macro use the "Add Shift" option of IR;  Do not
try to make it shifted by preceding it with the Setup key.

Changing the Shift Key:
-----------------------

   In the General/Other_Settings pane of IR.EXE you can configure shift to be
a different key or two keys.

"Shift Button Keycode" defines the primary shift key.  The value is displayed
as a decimal number.  The default is 1, which is the Setup key.  You can
change it to any key you prefer.  If you look up the keycode in KeyCodes.htm,
that value will be in hex.  You can type a hex value in the settings area by
prefixing it with "$".  IR will change it to the decimal value.  For example,
if you type the value in as $36 and IR shows it as 54.

"Alt Shift Button Keycode" defines an optional second shift key.  If that is
the same as the primary shift keycode then the extender will use only the
primary.  If it is a different valid code, that code will be a second shift.

"Alt Shift" selects whether the second shift key performs an xshift operation
or a ordinary (same as the first shift code) shift operation.  You can select
ordinary to have two shift keys that perform the same operation.  Using xshift
you can have up to three key moves on other keys by having an unshifted
keymove, a shifted keymove, and an xs-keymove.

The second shift key can be a code shifted by the first shift key.  In fact it
can be the first shift key shifted by itself.  For example, I set the first
shift keycode to $01 and the second one to $81 and selected "xshift".  Then if
I press Setup once, the next key is shifted;  If I press Setup twice, you get
the xs version of the next key;  If I press Setup three times, the next key is
back to normal.

Cloaking with Shift:
--------------------

   If you want to define a macro for a key (such as Power) but also use that
key as defined by the setup code (probably in that macro) the trick is to
use the shifted version of the key.  For this to work, you must not define
a KeyMove for the shifted key (in the current device index) nor define a
macro for it.  Then put shift-Power inside the Power macro.  When the
extender fails to find a KeyMove or macro for shift-Power, it looks in the
setup code for a definition of Power and finds the one that you couldn't
access directly because the macro is in the way.

Shifted device selection commands:
----------------------------------

   In other extenders shifted versions of the device selection commands (shift
T_VCR etc.) have been available as phantom codes, because they had no built in
meanings.  In this extender, most shifted versions of device selection commands
share the identical keycodes with xshifted versions of normal keys.  To avoid
confusion, you should avoid using shifted versions of device selection commands.

KEY SETS:
=========

T  =  Fwd, Pause, Play, Record, Rew, Stop, Replay, List, Live
V  =  Vol+, Vol-, Mute
O  =  Setup, Power, Ch+, Ch-, device keys, number keys, *, #/Enter,
      Last, Fav, Up, Down, Left, Right, Select, Settings, Guide,
      Menu, Info, Exit, Page Up, Page Down, A, B, C, Macro1,
      Macro2, Macro3, Video Source, PIP On/Off, PIP Swap, PIP Ch+,
      PIP Ch-, PIP Move, Phantom1, Phantom2, DiscreteON, DiscreteOFF

RDF FILES:
==========

  The enclosed RDF file "SA_71Kx1 (Atlas DVR-PVR 5-Device 1K Extender 1).rdf"
is needed in the directory where you run IR.EXE to edit an eeprom
image of the extender.

  The above rdf as well as the rdf file for the unextended Atlas DVR are
required in the directory where you run the ExtInstall program.

  In the past, as newer versions of IR.EXE have been released, they have been
bundled with updated versions of rdf files for various extenders.  If you use
this extender with a newer version of IR, it might include updates to the rdf
files that are included with this extender.  Such updates would have names
whose first 8 characters exactly match the first 8 characters of the rdf being
replaced (other parts of the name may be different).  If IR includes such
updates, you should probably use them instead of the rdfs included here.  If
IR is older than this extender or does not include such updates, then the
rdf files included here should be used.

TROUBLE SHOOTING:
=================

  This is a complicated extender that may still have some bugs in it, and it
lets you define very complex behaviors for your remote, which will probably
have errors on first try.

  The major method of trouble shooting is to break complex operations down
into their parts and see if the parts work individually.

Example:  You have a macro that does some device selection and does two
phantom codes and each phantom code does a ToadTog and it doesn't work.
Assign those two ToadTogs to physical keys (temporarily for trouble
shooting).  If necessary, define some simple macros to duplicate the
device selection of the complex macro.  Test the individual pieces of the
complex macro and see which work.

Example:  You have a ToadTog that doesn't work:  Make a simple macro or
DSM out of each command list of the ToadTog.  Test the two sequences that
way.

  A moderate fraction of macro, DSM and ToadTog problems are due to one of
two timing issues:

1)  The extender reduces (to the minimum value) the duration of signals which
are not the very last step in its macro buffer and signals which are processed
after the user has released the key that started the whole operation.
  If you suspect you have a duration problem, you should confirm it with two
tests.  Put the single function on a pressable key and press and hold that
key.  If that doesn't work, something more basic than a duration problem is
wrong.  Put a macro or DSM on a pressable key that is just the problem
function followed by an X_Cancel.  When you press that key, the function is
not last, so the duration will be minimum.  If that introduces the failure
you know it's a duration problem (there are then a variety of approaches to
fixing it).

2)  The extender reduces the time between signals within any automated
sequence of signals.  If functions work when manually sent in sequence, but
don't work when automatically sent in sequence, and you determine it's not a
duration problem, then it's time to try delays.  Define a KeyMove for a
moderately long use of the pause protocol.  Insert that before and/or after
the problem function(s) in your sequence.  If that fixes it, you've confirmed
that it is a timing problem and you can then experiment to fine tune the
correction to fix the problem with minimum increase in the time it takes the
whole operation to complete.
   Rarely, a device is sensitive to any signal at all right before or right
after its signal.  In those cases, the best you can do is find the smallest
added delay that fixes the problem.
   More often, a device just needs time to do the operation you gave it before
it is ready for the next.  In a complex macro, you may have an alternative to
adding delay.  If you're sending two commands to device A, then one command to
device B, try sending the command to device B in between the two commands to
device A.  That probably takes one or two extra X_ commands beyond doing it the
simple way, but probably takes less total execution time than simply adding
delay.
