Revision beta12 * Last Updated 09.10.1999
Note: Trademarks and copyrights are properties of their
respective owners!
This page shows some details we found
out about the data the TrueSync Information Manager exchanges with the
REX Card (Model REX-3) and how this is done via the Dockingstation and
COM-port. We are currently not working on the PCMCIA upload process.
All the information shown here was found out by comparing TrueSync and
the REX memory in some way or another. Starfish does *not* give out
information about the REX or TrueSync itself...
If you are interested in what is happening, please look at the links how to join our mailing list and other resources!
I'm working on this because I use OS/2 a lot and there is no software
for it and my REX. I have heard that Linux lacks support as well
and more and deeper knowledge of the structures inside the REX will
perhaps help someone develop software for it.
This is an unordered listing of people working on this:
- Rex Tech rex_tech at my-dejanews com
- Holger Lembke rexholger at hlembke de
- and me: Philipp Adelt
There are some sources of information about the REX that are interesting:
What we look at is the memory that holds the data uploaded.
The REX has 256 KBytes of user data memory. It is structured into 256 Blocks
of 1 KByte each. They are adressed from 00h to FEh (255d). FFh seems to have
a special meaning not known so far. The blocks are combined using a double
linked list. Each block has a "next" and a "previous" pointer.
Pointers and other data stored in a "word" (2 bytes) are encoded little endian:
The lower-significant byte is stored first.
A very detailed description of the data formats has been compiled by Holger
Lembke out of data we've found out. It is available here.
The REX card can be updated with data either through a PCMCIA slot or via
a Docking Station that is attached to a standard RS-232 interface like the
COM-port of a PC.
The port is set to 9600bps,8,n,1 or 57600bps,8,n,1. No other bps rates that work have
been found so far.
Commands are transmitted as standard ASCII text and are
terminated by 0Dh (=13d) (Carriage return, NO linefeed).
The responses are sent the other way round. I have used two computers hooked up as follows:
I used a program by Dave F. Baskin (COMM_MON, runs under OS/2, can be found
at Hobbes) to trace what was going on
between COM1 and COM2 of PC1. Using a normal Terminal program (Telix),
I verified what I saw. The result was the following syntax reference. It has
many holes, but shows enough to successfully supervise the REX card.
The communication starts after the program opens the COM-port. It sends
"GO" (474Fh) to the REX. REX answers with "OK<CR>" (4F4B0Dh). The program sends
the START-command: "<SP><SP>START<CR>" (202053544152540Dh)
and the REX answers "Err: 00<CR>" (4572723A2030300Dh). Then commands and data
according to the description below are exchanged. To end the communication,
the software sends "<SP><SP>END<CR>" (2020454E440Dh) and REX answer with
"Err: 00" again. The port is closed, the REX displays "Done." and turns off.
Note: <CR> means Carriage Return (0Dh=13d), <SP> means Space
(20h=32d).
Is used as the first command after the "GO"-"OK<CR>"-handshake and is sent
to end a WAIT-phase.
The VER-command is the second command TrueSync sends. After the program
sends "<SP><SP>VER<CR>", REX answers with the following:
De 44 65
v: REX.M 76 3A 20 52 45 58 0D 4D
em: 0100 65 6D 3A 20 30 31 30 30
.Blk: 04 0D 42 6C 6B 3A 20 30 34
00.DID: 30 30 0D 44 49 44 3A 20
4DFB9FB7 34 44 46 42 39 46 42 37
8EF16872 38 45 46 31 36 38 37 32
.Pwd: 00 0D 50 77 64 3A 20 30 30
.Ver: 01 0D 56 65 72 3A 20 30 31
00...... 30 30 0D
Field meanings:
- Mem: Amount of 1 KByte-Blocks present (in hex). (=user memory)
- Blk: Size of on Block (seems to be always 1KByte in known REX-3)
- DID: Device ID (see further information by Rex Tech)
- Pwd: Password enabled(?)
- Ver: Version of REX(?)
Program sends "<SP><SP>TS,xxxxxxxx<CR>" where
xxxxxxxx is the time in seconds since the 01.01.1980 0:00 (UTC?),
written in hex. Example: "<SP><SP>TS,2311A6C1<CR>"
REX answers with error-code ("Err: 00<CR>" means OK).
Program sends "<SP><SP>TG<CR>".
REX answers "Err: 00<CR>UTC: xxxxxxxx<CR>" where xxxxxxxx very
likely is the time since 01.01.1980 0:00 (UTC?).
Program sends "ERR<CR>". REX answers "Err: 00<CR>",
displays "Failed." and powers-off after some seconds.
After power-on, REX gives out the message "Warning! Synchronization
Incomplete.".
Guessed meaning is set password but real function is unknown so far.
Guessed meaning is reset REX but real function is unknown so far.
This command requests information about a 1 KByte-block in the REX.
Program sends "<SP><SP>XX,a,a" where a is the block number in hex.
Technically the REX extracts the header data of a block, calculates the
checksum and answers something like:
Err: 45 72 72 3A 20
00.Prv: 30 30 0D 50 72 76 3A 20
FFFF.Nxt 46 46 46 46 0D 4E 78 74
: 0002.C 3A 20 30 30 30 32 0D 43
hk: 715D 68 6B 3A 20 37 31 35 44
. 0D
Field meanings:
- Err: 00=command understood
- Prv: previous block number
- Nxt: next block number
- Chk: Checksum of block
It seems that the command tells the REX to "keep" the information inside the
specified block without the need for TrueSync to upload the block again.
All the blocks that are not overwritten are "XS"ed by TrueSync.
Program sends "<SP><SP>XS,a,a<CR>" where a is the block
number in hex.
REX answers with an error-code (00 is OK).
Tells REX to empty a specified block. Actually it writes "DE AD FF FF FF FF 00 00 ... 00 00"
into the 1KByte-Block. It does not "unlink" the specified block from the others.
Program sends "<SP><SP>XE,a,a<CR>" where a is the block
number in hex.
REX answers with an error-code (00 is OK).
This tells the REX to answer a block of its user memory.
Program sends "<SP><SP>XR,a,a<CR>" where a is the block
number of the block to be read.
REX answers something like:
Err: 00. 45 72 72 3A 20 30 30 0D
Len: 01A 4C 65 6E 3A 20 30 31 41
9.ð.ÿÿ.. 39 0D F0 0D FF FF 02 00
¡.BCO1.. A1 01 42 43 4F 31 00 01
........ 00 01 01 00 01 00 00 00
......Î. 00 00 00 00 00 00 CE 07
....#3rh 08 16 07 11 23 33 72 68
ñŽ·ŸûMÎ. F1 8E B7 9F FB 4D CE 07
...... (34lines snipped) ......
. Weaver 2E 20 57 65 61 76 65 72
. .Thank 0D 20 0D 54 68 61 6E 6B
you..Re 20 79 6F 75 2E 0D 52 65
main cal 6D 61 69 6E 20 63 61 6C
m.. 6D 2E 00
Where "Len: 01A9" means that after the "Len: 01A9<CR>" 01A9h (=425d)
bytes of data follow.
Tell REX to store data in one of the 1 KByte-blocks.
Program sends "<SP><SP>XW,a,a,b<CR>" where a is the number
of the block to be overwritten and b is the length of the data in hex (no
0-padding). This command immediately follow the b bytes of data.
REX answers with an error-code.
Lets the REX display "Processing". No timeout counting for more data?
- To display the DID for your device, go to the Preferences/Setup page
and press VIEW CHANGE (2nd button).
- A brand new REX (fresh batteries) has a DID value of 0000000000000000.
- If the DID is all zeros (as above), and a sync is started, the following appears to happen:
- After "Transferring updates from REX" (this is where it reads the
device's DID value), Truesync will prompt you for a user
configuration to associate with the device.
- Truesync will create a new DID value (I'm not sure of the algorithm)
and assign it to the REX device.
- Truesync will associate this DID value with the configuration
(in the registry - see below) by setting the configuration's
"UserID" value to the new DID.
- If the DID value in the REX matches the "UserID" value of a
configuration, Truesync knows not to prompt your for the
user configuration.
- If the DID value in the REX is non-zero, but doesn't match any
"UserID" value in a configuration, you'll be prompted for a
configuration. When you choose it, the configuration's "UserID"
value will be replaced with the DID value that was in the REX
(once a REX has a DID value, it doesn't change to a new value
when you change a configuration).
- I don't know if this is always true, but the DID value is stored
in the first 1K block of device memory at offset 0x24.
If the DID value displayed in the Preferences second
page is 1122334455667788, then the bytes at offset 0x24 of the
first block of data will be:
0x88, 0x77, 0x66, 0x55, 0x44, 0x33, 0x22, 0x11
Known DID conversions (by Rex Tech)
"Device:" displayed in Preferences page 2:
1122334455667788
Name of STATUS FILE:
REX5566778811223344.DAT
XOR-key for STATUS FILE:
{ 0x44, 0x33, 0x22, 0x11, 0x88, 0x77, 0x66, 0x55 }
UserID value in registry (under configuration):
88 77 66 55 44 33 22 11
DID value stored at offset 0x24 in first 1K of device memory:
0x88, 0x77, 0x66, 0x55, 0x44, 0x33, 0x22, 0x11
Using TIM 1.5, the following registry key is used for a particular
configuration:
HKEY_LOCAL_MACHINE\SOFTWARE\Starfish\TrueSync 1.0\REX Information
manager\{name of configuration}
Within this key, the value "UserID" holds the DID value of the last
REX device that synced with it. The DID value in this key is in
reverse byte order than what is displayed in the REX. If the REX
shows a DID value (in the second page of Preferences) of
1122334455667788, the UserID key in the registry will be "88 77 66
55 44 33 22 11".
When a NEW configuration is created (and has not been chosen during
a sync to be associated with a REX), there is no UserID key under
that configuration. This reinforces my assumption that DID values
identify devices, not configurations (the UserID key just tells you
which REX was the last REX to sync with that configuration).
After a sync, a status file is created in the "\Program
files\Starfish\REX Truesync\data" directory. This file appears
to keep a copy of the memory image that was transferred to the REX.
The name of this file is based on the DID, but is in a different byte
order than either the DID that's displayed on the device or the one
in the registry.
If the DID displayed on the device is 1122334455667788, the name
of this status file will be REX5566778811223344.DAT.
STATUS FILES are ENCODED. Each group of 8 bytes in the 256k image
is XOR-d with the 8 bytes of the DID. If the DID displayed in your
device is 1122334455667788, then the "XOR-key" will be:
{ 0x44, 0x33, 0x22, 0x11, 0x88, 0x77, 0x66, 0x55 }
See "decrypt.c" posted on the "rex_tech" forum on dejanews for a code that will
decode a STATUS file. (Also available here as viewable text or here
as downloadable ZIPped file.)
I've figured out the "Chk:" value used by the "XX" command - it's a
standard 16-bit CRC (using standard CCITT 16-bit CRC code for polynomial 0x1021).
I've attached a file (gencrc.c) that will generate
a CRC value when passed a pointer to a REX memory data block.
The CRC is computed over the size of the header (8-byte 'F00D PREV
NEXT COUNT') plus the size of the data bytes (the 'COUNT' value from
the header). This is also true for 'DEAD FFFF FFFF 0000' blocks - the
count is simply '8' since the DATA COUNT is 0000 in this case.
For non-data blocks (like CODE ROM), the CRC is computed over the entire 1K
block instead of just the header + data bytes. This doesn't really matter, since
we'll never be downloading data to the CODE ROM, but just for your information.
Now that we know it uses standard CRC code, it will be possible to write a fast sync program that only downloads changed blocks (instead of always downloading ALL data since we can't first check with CRC).
To be continued...
If you want to contribute, please let me know!
