Hello all -

	 I've written a program that will read/write REX memory via a PCMCIA slot under
Windows 95.  I've attached a ".zip" file to this message.

	 In "\readmem\rex\bin", there's a "rex.exe" and a "csaccess.vxd".  The ".vxd"
just allows the application to talk to PC Card services, which can only be
called directly from a ".vxd".

	 In the "bin" directory, you can run:

		 rex readmem filename

			 or

		 rex writemem filename

	 to either READ or WRITE the REX memory image to/from a file called "filename".

	 Under the "src" tree, there's a "vxd" directory and an "app" directory.  You'll
need the MS Win 95 DDK to build the "vxd".

	 To build the "vxd", go into the "vxd" directory and type "nmake /f
csaccess.mak".

	 To build the "rex.exe" app, go into the "app" directory and type "nmake /f
rex.mak".

(in both of the above cases, it's assumed that your PATH, INCLUDE, etc
directories are set up for Win VC 5.0 programming).

	 I haven't had much time to debug this, but it seems to work.

	 I'm also 80-90% finished with a program that will read the REX memory using the
serial port.  I need to debug/test it a bit, I'll probably send it tomorrow
sometime.

	 I've got to go now, I'll talk to you later.

RT



-----== Sent via Deja News, The Discussion Network ==-----
http://www.dejanews.com/  Easy access to 50,000+ discussion forums

Holger,

May I put a direct link from my page to your
http://home.braunschweig.netsurf.de/~holger.lembke/rex/rex-def.htm
page? I was in the process of updating my page when I noticed that
your description is exactly what I wanted to start. If you go on
gathering information about the structures there, I would prefer
linking your page than inventing the wheel twice.

Philipp Adelt
Bielefeld, Germany

Hallo out there,

RT > TIME_ZONE_INFO struct (used in some (or all?) event records for



I digged a little bit into the ZONEs block and used the informations
from REX_TECH. Doesn't work anything... but that seems to be a
rexanalyse-implementation-problem :-) Needs a bit extra time....


The PREFs are decoded up to 45%, there are 23 byte plus a
datetime-block unknown of 46 bytes total.


The www page will be updated soon.





--
mit freundlichen Grüßen
Holger, +49-531-3497854

HL> This is a problem I see: duplicate work.
HL> To solve the duplicate work problem, I'll make my results public
HL >under a specail www-page at my rex-page.

That sounds good.

HL> One my worksheet there is still noone who has done the serial
HL> communication in detail and readable for me. :-)

I started working on a program to read/write REX memory using the serial port -
I still have to learn how all the Windows serial port functions work (timeouts,
etc).  Because I had some problems, I looked at other things that were
interesting (like decoding the CLDR entries).  I'll go back to the serial
program next.

HL> Friday will be the next day when I can pull a large amount
HL> of time into the rex again.

Thursday night will be the next time that I can spend time on REX.

HL> One question that puzzels me: Why is the segment structure so
HL> chaotic? Why do the consecutive block contences jump almost from
HL> anywhere to nowhere? Wouldn't it be much simpler to add them each
HL> after the other?

One idea: maybe to help with serial synchronization (incremental sync).  If you
"insert" data into "block 0", instead of "pushing" all data in following blocks
forward to make room (which would cause "block 1-block N" to change - and
require a new download of all blocks to REX), create a new block at the end and
"insert" it into the linked-list (change block 0's "next" ptr to point to the
new block, block 1's "prev" pointer to point back to the new block instead of
block 0.

When you go to sync, you'll only download block 0, the new block, and block 1.

Does that make sense?

HL> What I'm a little bit curious about: Does Starfish know us? Do they
HL> follow our work? Will the stop supporting us (i signed the
HL >linux-beta-test)? Lets see....
>

I don't know - I've also been curious.  I think that they must be watching
(dejanews forum and padelt's page were announced on the REX page/Starfish's
support page when they were created; padelt's page now points to this onelist
mail list; the mail list archives are now public).

I think that if they know who we are that they would stop supporting us.


--

On Wed, 2 Sep 1998 08:06:38    Holger Lembke wrote:
>From: holger_lembke@... (Holger Lembke)
>
>Hallo Rex,
>
>RT > I don't know how much of this information is already known - If
>RT > someone else has already figured this out, please post the info
>RT > somewhere so I won't be duplicating someone else's efforts.
>
>This is a problem I see: duplicate work.
>
>One my worksheet there is still noone who has done the serial
>communication in detail and readable for me. :-)
>
>
>To solve the duplicate work problem, I'll make my results public
>under a specail www-page at my rex-page. This will happen perhaps
>tomorrow morning or later. Sorry. Not much time the following
>days. Friday will be the next day when I can pull a large amount
>of time into the rex again.
>
>
>I did some minutes work with the PREF-block. I got a very got
>workout about it from an unknown friend (not unknown, but I don't
>know if he wants his name to be known, because he send it private).
>
>
>After knowledge about the BC01-block, work is much easier.
>
>
>One question that puzzels me: Why is the segment structure so
>chaotic? Why do the consecutive block contences jump almost from
>anywhere to nowhere? Wouldn't it be much simpler to add them each
>after the other?
>
>For example:    food ffff 0001
>                food 0000 0002
>                food 0001 0003
>                food 0002 0004
>                food 0003 ffff
>
>instead if mixing it up and totaly confusing everything?
>
>
>
>What I'm a little bit curious about: Does Starfish know us? Do they
>follow our work? Will the stop supporting us (i signed the
>linux-beta-test)? Lets see....
>
>
>
>
>This is, what I have for the CLDR-Block:
>
>Start of block:
>
>       
(*******************************************************************************\
******************)
>        TCLDRBlock = record
>          header    : dword;                        // "CLDR"
>          unknown1  : byte;
>          entries   : word;
>          unknown2  : array[0..13] of byte;
>        end;
>
>For every entry:
>
>       
(*******************************************************************************\
******************)
>        // Calendar-Eintrag
>        TCLDREntryHeader = record
>          entrysize   : word;
>          unknown1    : array[0..3] of byte;
>          extra       : byte;                        // Wenn $80, dann
TCLDRExtraheader
>          start       : tdatetimeblock;
>          ende        : tdatetimeblock;
>          unknown4    : array[0..3] of byte;
>          alarmbefore : word;                        // Anzahl in Minuten
>        end;
>
>       
(*******************************************************************************\
******************)
>        // Extraheader. Unknown
>        TCLDRExtraheader = record
>          unknown1    : array[0..23] of byte;
>        end;
>
>        (*
>        Danach folgt jeweils nullterminiert:
>          Terminort (meist leer, also nur null)
>          Termintitel
>          Notizen (Zeilentrenner OD OA)
>
>        und am Ende wiederholt die Eintragsgroesse
>        *)
>
>
>
>
>
>--
>mit freundlichen Grüßen
>Holger, +49-531-3497854
>
>------------------------------------------------------------------------
>Help support ONElist, while generating interest in your product or
>service. ONElist has a variety of advertising packages. Visit
>http://www.onelist.com/advert.html for more information.
>------------------------------------------------------------------------
>----------------------------------------------------------
>Distributed via the FreeREX technical mailing list.
>Visit http://www.geocities.com/SiliconValley/2867/rex.html
>for more information!
>


-----== Sent via Deja News, The Discussion Network ==-----
http://www.dejanews.com/  Easy access to 50,000+ discussion forums

Hallo Rex,

RT > I don't know how much of this information is already known - If
RT > someone else has already figured this out, please post the info
RT > somewhere so I won't be duplicating someone else's efforts.

This is a problem I see: duplicate work.

One my worksheet there is still noone who has done the serial
communication in detail and readable for me. :-)


To solve the duplicate work problem, I'll make my results public
under a specail www-page at my rex-page. This will happen perhaps
tomorrow morning or later. Sorry. Not much time the following
days. Friday will be the next day when I can pull a large amount
of time into the rex again.


I did some minutes work with the PREF-block. I got a very got
workout about it from an unknown friend (not unknown, but I don't
know if he wants his name to be known, because he send it private).


After knowledge about the BC01-block, work is much easier.


One question that puzzels me: Why is the segment structure so
chaotic? Why do the consecutive block contences jump almost from
anywhere to nowhere? Wouldn't it be much simpler to add them each
after the other?

For example:    food ffff 0001
                 food 0000 0002
                 food 0001 0003
                 food 0002 0004
                 food 0003 ffff

instead if mixing it up and totaly confusing everything?



What I'm a little bit curious about: Does Starfish know us? Do they
follow our work? Will the stop supporting us (i signed the
linux-beta-test)? Lets see....




This is, what I have for the CLDR-Block:

Start of block:

        
(*******************************************************************************\
******************)
         TCLDRBlock = record
           header    : dword;                        // "CLDR"
           unknown1  : byte;
           entries   : word;
           unknown2  : array[0..13] of byte;
         end;

For every entry:

        
(*******************************************************************************\
******************)
         // Calendar-Eintrag
         TCLDREntryHeader = record
           entrysize   : word;
           unknown1    : array[0..3] of byte;
           extra       : byte;                        // Wenn $80, dann
TCLDRExtraheader
           start       : tdatetimeblock;
           ende        : tdatetimeblock;
           unknown4    : array[0..3] of byte;
           alarmbefore : word;                        // Anzahl in Minuten
         end;

        
(*******************************************************************************\
******************)
         // Extraheader. Unknown
         TCLDRExtraheader = record
           unknown1    : array[0..23] of byte;
         end;

         (*
         Danach folgt jeweils nullterminiert:
           Terminort (meist leer, also nur null)
           Termintitel
           Notizen (Zeilentrenner OD OA)

         und am Ende wiederholt die Eintragsgroesse
         *)





--
mit freundlichen Grüßen
Holger, +49-531-3497854

Hello -

I don't know how much of this information is already known - If someone else has
already figured this out, please post the info somewhere so I won't be
duplicating someone else's efforts.

I've begun to dig into the "CLDR" entries.  I started looking at the default
"Special Days" to see how they store "rules" like "Last Monday in May (US
Memorial Day)".

After I had some of that information figured out, I started looking into some
more "recurring event" types (go to TIM's "Calendar->Events->Recurring..." menu
item to see the various types).

I've found that most (if not all) recurring events (including "Special days")
share the same basic structure.

For the event types that I've looked at, I've decoded probably about 90%+ of the
corresponding recurring event structure.

A structure that is used throughout many/all of the recurring events is the
"offset from GMT" structure - this contains the event's base time zone's "+/-
offset" from GMT, along with "Daylight savings" rule information.  If you go
into "Earthtime", right-click on a city on your display, and choose "Modify city
information...", you'll see GMT offset info and DST info.  Knowing what was
valid in these entries made it easier to decode.  These "offset from GMT"
structures are in the actual event structures - they may be very similar to data
in the "ZONE" section - I don't know (I haven't looked at the "ZONE" section
yet).

I'm attaching a copy of a ".txt" file describing what I know so far.  There are
many more event types to decode, but now that the basic structure is known, it
should be fairly easy  ;>)

It's getting late here - I should be getting to sleep now.  Please keep everyone
up to date on your accomplishments.

Regards,

RT





-----== Sent via Deja News, The Discussion Network ==-----
http://www.dejanews.com/  Easy access to 50,000+ discussion forums

>Did you notice that the REX user data uploaded starts
>at 00200000?
>Very well possible that under other adresses we find
>the ROMs...

Yes, I did notice.  I wonder what else is there (maybe the 32K ram chip you
mentioned in a different message)?


--

On Tue, 01 Sep 98 20:40:33 +   Philipp Adelt wrote:
>From: padelt@... (Philipp Adelt)
>
>Did you notice that the REX user data uploaded starts
>at 00200000?
>Very well possible that under other adresses we find
>the ROMs...
>
>Philipp Adelt
>Bielefeld, Germany
>
>
>------------------------------------------------------------------------
>To unsubscribe from this mailing list, or to change your subscription
>to digest, go to the ONElist web site, at http://www.onelist.com and
>select the User Center link from the menu bar on the left.
>------------------------------------------------------------------------
>----------------------------------------------------------
>Distributed via the FreeREX technical mailing list.
>Visit http://www.geocities.com/SiliconValley/2867/rex.html
>for more information!
>


-----== Sent via Deja News, The Discussion Network ==-----
http://www.dejanews.com/  Easy access to 50,000+ discussion forums

RT > The information which I think is "new" is the
RT > "Sync range START/END DATE/TIME" values.

HL > Hmmmmm. I thought is was FirstSync, LastSync or
HL > anything like that.

HL > I have dates till 1999-10-15 in my rex (yes,
HL > its true. i known schedules in 1999-10!), but
HL > both values are in the past.

What do you have your "Starting from" and "Through" settings set to in the
TrueSync configuration?

I've done an analysis of various combinations of "Starting from" and "Through"
ranges - both of the "Sync range START/END DATE/TIME" values get changed to
values that are consistent with my settings.

I've attached a text file describing all the combinations that I tested and the
DATE/TIME values found in the 'BCO1' section.

By the way, the 5th byte in the DATE/TIME structure looks like it is "day of
week (01-07)" - not the time zone as I (and I think others) had thought.

Regards,

- RT

--

On Tue, 1 Sep 1998 07:13:41    Holger Lembke wrote:
>From: holger_lembke@... (Holger Lembke)
>
>Hallo Rex,
>
>RT > Are you talking about the "1K" blocks in the "REX*.DAT" file?
>
>No, not really. :-)
>
>The PREV-NEXT-SIZE-chain is well known:
>
>
>Every 1k-block begins with
>
>        TDSubblock = record
>          Ident     : word;
>          prev,
>          next      : word;
>          blocksize : word;
>        end;
>
>
>RT > When you speak of "blocks", are you talking about things like
>RT > "BCO1", "CLDR", "ZONE", etc?
>
>
>YES! After sleeping very well and a fresh cup of coffee: no new idea
>how to find the begins.
>
>
>I still can't imagine, that they must scan the entire memory to find
>the PREFs block.
>
>Because, if there are no direct pointers, to reach the PREFs they
>need to do:
>
>1.) got to the begin
>2.) seek plus sizeof (bco1-block)
>
>3.) fetch the number of schedules
>
>4.) seek plus sizeof (CLDR-Header-block)
>
>5.) repeat
>      read sizeof schedule item
>      seek plus sizeof schedule item
>    until all schedules seeked
>
>
>Step 3 to 5 will have to be done for CONTs, TODOs, MEMOs and ZONEs.
>Then the pointer would stand at the beginning of the PREF-block.
>
>
>Looks very very stupid.
>
>
>But I don't figure out any other way.
>
>
>
>RT > For myself, this would make it easier to view the entire 256K image
>RT > (instead of jumping around to different 1K blocks).
>
>I'll build in a "bring in order" button.
>
>
>RT > The information which I think is "new" is the "Sync range START/END
>RT > DATE/TIME" values.
>
>Hmmmmm. I thought is was FirstSync, LastSync or anything
>like that.
>
>I have dates till 1999-10-15 in my rex (yes, its true. i known
>schedules in 1999-10!), but both values are in the past.
>
>
>It seems to be what I figured out: syncfile-create-datetime and
>last-sync-datetime.
>
>
>For the rest of the BCO1-block I don't know more than you.
>
>
>
>
>
>--
>mit freundlichen Grüßen
>Holger, +49-531-3497854
>
>------------------------------------------------------------------------
>Help support ONElist, while generating interest in your product or
>service. ONElist has a variety of advertising packages. Visit
>http://www.onelist.com/advert.html for more information.
>------------------------------------------------------------------------
>----------------------------------------------------------
>Distributed via the FreeREX technical mailing list.
>Visit http://www.geocities.com/SiliconValley/2867/rex.html
>for more information!
>


-----== Sent via Deja News, The Discussion Network ==-----
http://www.dejanews.com/  Easy access to 50,000+ discussion forums

Hallo ppl,


I added the memo-block to the rexanalyse. Hoppefully it works,
didn'd do many checks.



MEMO-Block

         TMemoBlock = record
           header    : dword;                       // "MEMO"
           unknown1  : byte;
           entries   : word;
         end;


every Entry


         TMemoEntryheader = record
           entrysize : word;                        // including length-word
           unknown1  : array[0..10] of byte;
         end;
         (*
         after that follows
           Title
           Notice
           and finally the entrysize again
         *)




--
mit freundlichen Grüßen
Holger, +49-531-3497854

Did you notice that the REX user data uploaded starts
at 00200000?
Very well possible that under other adresses we find
the ROMs...

Philipp Adelt
Bielefeld, Germany

I've read some of the hardware guides available for the REX.
It seems there is a CPU in there that runs at 4,3MHz.
Additionally to the 256KByte data mem it has 32KByte what
is called "Working memory" there.
Do you think it would be possible that the REX builds the linked
lists as Holger searched for while uploading or after this!?
This would be a bit more "smooth" method to jump to information
other than brute-force jumping around in memory and would even
be more power efficient than having dynamic linked lists inside
the data!

Philipp Adelt
Bielefeld, Germany

Great!
I'll add this as soon as possible to my page. This should give us all
we need to make up a valid BCO1 block.

Philipp Adelt
Bielefeld, Germany

On Mon, 31 Aug 1998 17:13:27 -0700, Rex Tech wrote:
>From: "Rex Tech" <rex_tech@...>
>
>I don't know if either/both of you already have this figured out, but I've
found out the following about the 'BCO1' block:
>
>Offset Data 		 Description
>------ -------------------------- -------------------------------
>000000 42 43 4F 31 	 'BCO1' marker
>000004 ?? ?? 		 Unknown (guess: 2 byte value)
>000006 ?? ?? 		 Unknown (guess: 2 byte value)
>000008 ?? ?? 		 Unknown (guess: 2 byte value)
>00000A ?? ?? 		 Unknown (guess: 2 byte value)
>00000C ?? ?? 		 Unknown (guess: 2 byte value)
>00000E ?? ?? 		 Unknown (guess: 2 byte value)
>000010 ?? ?? 		 Unknown (guess: 2 byte value)
>000012 ?? ?? 		 Unknown (guess: 2 byte value)
>000014 ll ll ll ll ll ll ll ll  Last sync date/time (GMT)
>00001C ii ii ii ii ii ii ii ii  DID
>000024 ss ss ss ss ss ss ss ss  Sync range START DATE/TIME (GMT)
>00002C ee ee ee ee ee ee ee ee  Sync range END DATE/TIME (GMT)
>000034 ?? ?? ?? ?? 	 Unknown (guess: 4 byte value)
>000038 ?? ?? ?? ?? 	 Unknown (guess: 4 byte value)
>00003C ?? ?? ?? ?? 	 Unknown (guess: 4 byte value)
>000040 ?? ?? ?? ?? 	 Unknown (guess: 4 byte value)
>000044 ?? ?? ?? ?? 	 Unknown (guess: 4 byte value)
>000048 4C 00 00 00 	 Size of 'BCO1' block?
>
>The information which I think is "new" is the "Sync range START/END DATE/TIME"
values.
>
>In the TrueSync configuration dialog box, when selecting a calendar to sync,
you specify the start/end RANGE of dates to sync (in the "Starting from/Through"
items).  The DATE/TIME (in GMT) of the specified range are stored at offsets
0x24 and 0x2C in the 'BCO1' block (respectively).
>
>For example, if you specify "This year" through "Next year", the "Sync range
START DATE/TIME" will be the GMT date/time for "Jan 1st, 1998 00:00", and the
"Sync range END DATE/TIME" will be the GMT date/time for "Jan 1st, 2000 00:00".
>
>
>
>
>-----== Sent via Deja News, The Discussion Network ==-----
>http://www.dejanews.com/  Easy access to 50,000+ discussion forums
>
>------------------------------------------------------------------------
>To unsubscribe from this mailing list, or to change your subscription
>to digest, go to the ONElist web site, at http://www.onelist.com and
>select the User Center link from the menu bar on the left.
>------------------------------------------------------------------------
>----------------------------------------------------------
>Distributed via the FreeREX technical mailing list.
>Visit http://www.geocities.com/SiliconValley/2867/rex.html
>for more information!

God, I've searched for over an hour for the mail at Starfish
describing how to get to this mode - my father read about it
but he couldn't remember. Thanks!

Philipp Adelt
Bielefeld, Germany

On Mon, 31 Aug 1998 23:18:07 -0700, Rex Tech wrote:
>I finally figured it out by ERASING the REX's memory from "Factory test mode"
(hold down "VIEW CHANGE", then press RESET (while still holding key), then
choose "Clear memory/Restart.
>After doing the "Restart", I got back into the "Factory test mode", then chose
"Debug Memory".  It displays a hex dump of the (almost empty) memory.

I've changed the list archives type to public to allow foreigners
to read our published mails.

Philipp Adelt
Bielefeld, Germany

HL>This is excactly what I thought how it should work. And I was
HL>searching at exact the same places.

HL>But I was to stupid to figure it out.... :-))

Believe me - it took FOREVER to figure it out.

I finally figured it out by ERASING the REX's memory from "Factory test mode"
(hold down "VIEW CHANGE", then press RESET (while still holding key), then
choose "Clear memory/Restart.

After doing the "Restart", I got back into the "Factory test mode", then chose
"Debug Memory".  It displays a hex dump of the (almost empty) memory.

The (almost empty) memory image has the same basic structure as other files, but
only has a "skeleton" with empty sections in it.

With this tiny (2K) image, I could easily see that the offsets to each "section"
were stored in the "BCO1" header (but they weren't quite exact - some (in the
first block) were off by 8 bytes, others (in the second block) were off by 16
bytes).  This lead me to the idea of a "flat" memory image.

I've attached a HEX dump of the first 2K of an "empty" REX's memory.

- RT.




--

On Tue, 1 Sep 1998 07:56:02    Holger Lembke wrote:
>From: holger_lembke@... (Holger Lembke)
>
>Hallo Rex,
>
>RT > I've basically figured out how to find the start of the individual
>RT > 'PREF', 'ZONE', 'TODO', etc. segments in the REX memory.
>
>This is excactly what I thought how it should work. And I was
>searching at exact the same places.
>
>
>But I was to stupid to figure it out.... :-))
>
>
>
>
>Thanks for that!! Now I'll go to my dailly work, will be a happy
>day... :-))) And incorporate to into rexanalyse.exe when I'm back.
>
>
>
>
>
>
>--
>mit freundlichen Grüßen
>Holger, +49-531-3497854
>
>------------------------------------------------------------------------
>To unsubscribe from this mailing list, or to change your subscription
>to digest, go to the ONElist web site, at http://www.onelist.com and
>select the User Center link from the menu bar on the left.
>------------------------------------------------------------------------
>----------------------------------------------------------
>Distributed via the FreeREX technical mailing list.
>Visit http://www.geocities.com/SiliconValley/2867/rex.html
>for more information!
>


-----== Sent via Deja News, The Discussion Network ==-----
http://www.dejanews.com/  Easy access to 50,000+ discussion forums

Hallo Rex,

RT > I've basically figured out how to find the start of the individual
RT > 'PREF', 'ZONE', 'TODO', etc. segments in the REX memory.

This is excactly what I thought how it should work. And I was
searching at exact the same places.


But I was to stupid to figure it out.... :-))




Thanks for that!! Now I'll go to my dailly work, will be a happy
day... :-))) And incorporate to into rexanalyse.exe when I'm back.






--
mit freundlichen Grüßen
Holger, +49-531-3497854

Hallo ppl,

Changes on my Rex-Page:


   - no new informations
   - mispellings, silly words fixed

and

   - new version of rexanalyse.exe


Have a look at


   http://home.braunschweig.netsurf.de/~holger.lembke/rex/rex.html


--
mit freundlichen Grüßen
Holger, +49-531-3497854

Holger -

I've basically figured out how to find the start of the individual 'PREF',
'ZONE', 'TODO', etc. segments in the REX memory.

I've attached a file (rexmem1.zip) that has a small program (along with source
code) that will take a "REX*.DAT" file, load it into memory, and create a "flat"
image with all physical block info removed.

The "flat" offsets to each of the 'PREF'/'ZONE', etc. segments is in the 'BCO1'
segment - the key is that the offsets are "logical" and do not include physical
block header bytes or the "empty" NON-data bytes at the end of a data block.

I am sorry if I am not explaining this well - please look at "rexmem.h" in the
".zip" file for a brief description.  The code (not very well commented) is in
"rexmem.c".

A sample program that loads/saves "REX*.DAT" files is "main.c".

I compiled using MS VC 5.x command-line compiler:
      cl main.c rexmem.c

to generate 'main.exe'.

Please let me know if you have problems with my code or my explanation.

Feel free to use/publish any of my code for "public domain" use.

--

On Mon, 31 Aug 1998 21:12:49   Holger Lembke wrote:
>From: holger_lembke@... (Holger Lembke)
>
>Hallo ppl.,
>
>
>current "most wanted information" is how to come from block to
>block.
>
>
>  Facts is: blocks don't begin at segment begins.
>
>
>Possible fact is: there is no "pointerarray" that points to the
>begin of the blocks.
>
>
>I'm trying to go from block to block by dummy-reading the space
>between the blocks. But it's a poor approach.
>
>
>
>Any ideas? Help needed.
>
>
>
>
>
>--
>mit freundlichen Grüßen
>Holger, +49-531-3497854
>
>------------------------------------------------------------------------
>To unsubscribe from this mailing list, or to change your subscription
>to digest, go to the ONElist web site, at http://www.onelist.com and
>select the User Center link from the menu bar on the left.
>------------------------------------------------------------------------
>----------------------------------------------------------
>Distributed via the FreeREX technical mailing list.
>Visit http://www.geocities.com/SiliconValley/2867/rex.html
>for more information!
>


-----== Sent via Deja News, The Discussion Network ==-----
http://www.dejanews.com/  Easy access to 50,000+ discussion forums

Hallo Rex,

RT > Are you talking about the "1K" blocks in the "REX*.DAT" file?

No, not really. :-)

The PREV-NEXT-SIZE-chain is well known:


Every 1k-block begins with

         TDSubblock = record
           Ident     : word;
           prev,
           next      : word;
           blocksize : word;
         end;


RT > When you speak of "blocks", are you talking about things like
RT > "BCO1", "CLDR", "ZONE", etc?


YES! After sleeping very well and a fresh cup of coffee: no new idea
how to find the begins.


I still can't imagine, that they must scan the entire memory to find
the PREFs block.

Because, if there are no direct pointers, to reach the PREFs they
need to do:

1.) got to the begin
2.) seek plus sizeof (bco1-block)

3.) fetch the number of schedules

4.) seek plus sizeof (CLDR-Header-block)

5.) repeat
       read sizeof schedule item
       seek plus sizeof schedule item
     until all schedules seeked


Step 3 to 5 will have to be done for CONTs, TODOs, MEMOs and ZONEs.
Then the pointer would stand at the beginning of the PREF-block.


Looks very very stupid.


But I don't figure out any other way.



RT > For myself, this would make it easier to view the entire 256K image
RT > (instead of jumping around to different 1K blocks).

I'll build in a "bring in order" button.


RT > The information which I think is "new" is the "Sync range START/END
RT > DATE/TIME" values.

Hmmmmm. I thought is was FirstSync, LastSync or anything
like that.

I have dates till 1999-10-15 in my rex (yes, its true. i known
schedules in 1999-10!), but both values are in the past.


It seems to be what I figured out: syncfile-create-datetime and
last-sync-datetime.


For the rest of the BCO1-block I don't know more than you.





--
mit freundlichen Grüßen
Holger, +49-531-3497854

I don't know if either/both of you already have this figured out, but I've found
out the following about the 'BCO1' block:

Offset Data 		 Description
------ -------------------------- -------------------------------
000000 42 43 4F 31 	 'BCO1' marker
000004 ?? ?? 		 Unknown (guess: 2 byte value)
000006 ?? ?? 		 Unknown (guess: 2 byte value)
000008 ?? ?? 		 Unknown (guess: 2 byte value)
00000A ?? ?? 		 Unknown (guess: 2 byte value)
00000C ?? ?? 		 Unknown (guess: 2 byte value)
00000E ?? ?? 		 Unknown (guess: 2 byte value)
000010 ?? ?? 		 Unknown (guess: 2 byte value)
000012 ?? ?? 		 Unknown (guess: 2 byte value)
000014 ll ll ll ll ll ll ll ll  Last sync date/time (GMT)
00001C ii ii ii ii ii ii ii ii  DID
000024 ss ss ss ss ss ss ss ss  Sync range START DATE/TIME (GMT)
00002C ee ee ee ee ee ee ee ee  Sync range END DATE/TIME (GMT)
000034 ?? ?? ?? ?? 	 Unknown (guess: 4 byte value)
000038 ?? ?? ?? ?? 	 Unknown (guess: 4 byte value)
00003C ?? ?? ?? ?? 	 Unknown (guess: 4 byte value)
000040 ?? ?? ?? ?? 	 Unknown (guess: 4 byte value)
000044 ?? ?? ?? ?? 	 Unknown (guess: 4 byte value)
000048 4C 00 00 00 	 Size of 'BCO1' block?

The information which I think is "new" is the "Sync range START/END DATE/TIME"
values.

In the TrueSync configuration dialog box, when selecting a calendar to sync, you
specify the start/end RANGE of dates to sync (in the "Starting from/Through"
items).  The DATE/TIME (in GMT) of the specified range are stored at offsets
0x24 and 0x2C in the 'BCO1' block (respectively).

For example, if you specify "This year" through "Next year", the "Sync range
START DATE/TIME" will be the GMT date/time for "Jan 1st, 1998 00:00", and the
"Sync range END DATE/TIME" will be the GMT date/time for "Jan 1st, 2000 00:00".




-----== Sent via Deja News, The Discussion Network ==-----
http://www.dejanews.com/  Easy access to 50,000+ discussion forums

Holger -

I think that a nice option in 'rexanalyse' would be to create a "flat" 256K
image by re-arranging the 1K blocks into "logical" order (so "logical" block 0
is the same as "physical" block 0, and so on).  For example, if the blocks are
in the following order:

(TAB-aligned, view in "fixed-width" font):
----------------------------------------------------Offset Marker Prev Next
000000 F0 0D FF FF 02 00 Logical block "0" (start of chain)
000400 F0 0D 02 00 05 00 Logical block "2"
000800 F0 0D 00 00 01 00 Logical block "1"
000C00 F0 0D 04 00 FF FF Logical block "6" (end of chain)
001000 F0 0D 06 00 03 00 Logical block "5"
001400 F0 0D 01 00 06 00 Logical block "3"
001800 F0 0D 05 00 04 00 Logical block "4"
001C00 DE AD FF FF 02 00 "Empty"
002000 DE AD FF FF 02 00 "Empty"

Re-arrange them to look like:

----------------------------------------------------Offset Marker Prev Next
000000 F0 0D FF FF 01 00 Logical block "0" (start of chain)
000400 F0 0D 00 00 02 00 Logical block "1"
000800 F0 0D 01 00 03 00 Logical block "2"
000C00 F0 0D 02 00 04 00 Logical block "3"
001000 F0 0D 03 00 05 00 Logical block "4"
001400 F0 0D 04 00 06 00 Logical block "5"
001800 F0 0D 05 00 FF FF Logical block "6" (end of chain)
001C00 DE AD FF FF 02 00 "Empty"
002000 DE AD FF FF 02 00 "Empty"


For myself, this would make it easier to view the entire 256K image (instead of
jumping around to different 1K blocks).

If any "flat/logical" offset values are stored in any of the data, they may more
easily be interpreted if the data we're looking at is also "flat".

--

On Mon, 31 Aug 1998 15:03:51   Rex Tech wrote:
>From: "Rex Tech" <rex_tech@...>
>
>Are you talking about the "1K" blocks in the "REX*.DAT" file?
>
>I noticed that the 1K blocks are not in order, but using the "Prev/Next"
pointers, it looks like it is possible to construct a "flat" image.
>
>For example, I had a "REX*.DAT" file that (after XOR-key decoding) had 7 1K
blocks of "data" - the rest of the 256 1K blocks were "empty".
>
>Each "data" block starts with "F0 0D" as the first two bytes of the 1K block,
followed by a "prev" block number and a "next" block number.  "Empty" blocks
start with "DE AD", and the "prev/next" values are both "FF FF".
>
>Below is a dump of the first 6 bytes of each 1K in my "REX*.DAT" file (only
showing the first 10 1K blocks, since the remaining blocks are all "empty"):
>
>(TAB-aligned, view in "fixed-width" font):
>----------------------------------------------------
>Offset Marker Prev Next
>000000 F0 0D FF FF 02 00 Logical block "0" (start of chain)
>000400 F0 0D 02 00 05 00 Logical block "2"
>000800 F0 0D 00 00 01 00 Logical block "1"
>000C00 F0 0D 04 00 FF FF Logical block "6" (end of chain)
>001000 F0 0D 06 00 03 00 Logical block "5"
>001400 F0 0D 01 00 06 00 Logical block "3"
>001800 F0 0D 05 00 04 00 Logical block "4"
>001C00 DE AD FF FF 02 00 "Empty"
>002000 DE AD FF FF 02 00 "Empty"
>
>"F0 0D" means "valid" data block.
>"DE AD" means "empty/unused" block.
>
>PREV/NEXT values are stored little-endian (low-byte/high-byte)
>
>If PREV is "FF FF", this is the FIRST logical block (start of chain)
>
>If NEXT is "FF FF", this is the LAST logical block (end of chain)
>----------------------------------------------------
>
>So, the blocks are "physically" stored at any physical block in the RAM image -
the logical-to-physical mapping is based on the PREV/NEXT linked-list values.
>
>Does this make sense?  Am I understanding your question correctly, or did you
mean something else?
>
>
>--
>
>On Mon, 31 Aug 1998 21:12:49   Holger Lembke wrote:
>>From: holger_lembke@... (Holger Lembke)
>>
>>Hallo ppl.,
>>
>>
>>current "most wanted information" is how to come from block to
>>block.
>>
>>
>>  Facts is: blocks don't begin at segment begins.
>>
>>
>>Possible fact is: there is no "pointerarray" that points to the
>>begin of the blocks.
>>
>>
>>I'm trying to go from block to block by dummy-reading the space
>>between the blocks. But it's a poor approach.
>>
>>
>>
>>Any ideas? Help needed.
>>
>>
>>
>>
>>
>>--
>>mit freundlichen Grüßen
>>Holger, +49-531-3497854
>>
>>------------------------------------------------------------------------
>>To unsubscribe from this mailing list, or to change your subscription
>>to digest, go to the ONElist web site, at http://www.onelist.com and
>>select the User Center link from the menu bar on the left.
>>------------------------------------------------------------------------
>>----------------------------------------------------------
>>Distributed via the FreeREX technical mailing list.
>>Visit http://www.geocities.com/SiliconValley/2867/rex.html
>>for more information!
>>
>
>
>-----== Sent via Deja News, The Discussion Network ==-----
>http://www.dejanews.com/  Easy access to 50,000+ discussion forums
>
>------------------------------------------------------------------------
>To unsubscribe from this mailing list, or to change your subscription
>to digest, go to the ONElist web site, at http://www.onelist.com and
>select the User Center link from the menu bar on the left.
>------------------------------------------------------------------------
>----------------------------------------------------------
>Distributed via the FreeREX technical mailing list.
>Visit http://www.geocities.com/SiliconValley/2867/rex.html
>for more information!
>



-----== Sent via Deja News, The Discussion Network ==-----
http://www.dejanews.com/  Easy access to 50,000+ discussion forums

Holger -

I must have misunderstood your question - I can see that your "rexanalyse"
program is aware of the PREV/NEXT values, and the logical/physical 1K blocking
mechanism.

When you speak of "blocks", are you talking about things like "BCO1", "CLDR",
"ZONE", etc?



--

On Mon, 31 Aug 1998 15:03:51   Rex Tech wrote:
>From: "Rex Tech" <rex_tech@...>
>
>Are you talking about the "1K" blocks in the "REX*.DAT" file?
>
>I noticed that the 1K blocks are not in order, but using the "Prev/Next"
pointers, it looks like it is possible to construct a "flat" image.
>
>For example, I had a "REX*.DAT" file that (after XOR-key decoding) had 7 1K
blocks of "data" - the rest of the 256 1K blocks were "empty".
>
>Each "data" block starts with "F0 0D" as the first two bytes of the 1K block,
followed by a "prev" block number and a "next" block number.  "Empty" blocks
start with "DE AD", and the "prev/next" values are both "FF FF".
>
>Below is a dump of the first 6 bytes of each 1K in my "REX*.DAT" file (only
showing the first 10 1K blocks, since the remaining blocks are all "empty"):
>
>(TAB-aligned, view in "fixed-width" font):
>----------------------------------------------------
>Offset Marker Prev Next
>000000 F0 0D FF FF 02 00 Logical block "0" (start of chain)
>000400 F0 0D 02 00 05 00 Logical block "2"
>000800 F0 0D 00 00 01 00 Logical block "1"
>000C00 F0 0D 04 00 FF FF Logical block "6" (end of chain)
>001000 F0 0D 06 00 03 00 Logical block "5"
>001400 F0 0D 01 00 06 00 Logical block "3"
>001800 F0 0D 05 00 04 00 Logical block "4"
>001C00 DE AD FF FF 02 00 "Empty"
>002000 DE AD FF FF 02 00 "Empty"
>
>"F0 0D" means "valid" data block.
>"DE AD" means "empty/unused" block.
>
>PREV/NEXT values are stored little-endian (low-byte/high-byte)
>
>If PREV is "FF FF", this is the FIRST logical block (start of chain)
>
>If NEXT is "FF FF", this is the LAST logical block (end of chain)
>----------------------------------------------------
>
>So, the blocks are "physically" stored at any physical block in the RAM image -
the logical-to-physical mapping is based on the PREV/NEXT linked-list values.
>
>Does this make sense?  Am I understanding your question correctly, or did you
mean something else?
>
>
>--
>
>On Mon, 31 Aug 1998 21:12:49   Holger Lembke wrote:
>>From: holger_lembke@... (Holger Lembke)
>>
>>Hallo ppl.,
>>
>>
>>current "most wanted information" is how to come from block to
>>block.
>>
>>
>>  Facts is: blocks don't begin at segment begins.
>>
>>
>>Possible fact is: there is no "pointerarray" that points to the
>>begin of the blocks.
>>
>>
>>I'm trying to go from block to block by dummy-reading the space
>>between the blocks. But it's a poor approach.
>>
>>
>>
>>Any ideas? Help needed.
>>
>>
>>
>>
>>
>>--
>>mit freundlichen Grüßen
>>Holger, +49-531-3497854
>>
>>------------------------------------------------------------------------
>>To unsubscribe from this mailing list, or to change your subscription
>>to digest, go to the ONElist web site, at http://www.onelist.com and
>>select the User Center link from the menu bar on the left.
>>------------------------------------------------------------------------
>>----------------------------------------------------------
>>Distributed via the FreeREX technical mailing list.
>>Visit http://www.geocities.com/SiliconValley/2867/rex.html
>>for more information!
>>
>
>
>-----== Sent via Deja News, The Discussion Network ==-----
>http://www.dejanews.com/  Easy access to 50,000+ discussion forums
>
>------------------------------------------------------------------------
>To unsubscribe from this mailing list, or to change your subscription
>to digest, go to the ONElist web site, at http://www.onelist.com and
>select the User Center link from the menu bar on the left.
>------------------------------------------------------------------------
>----------------------------------------------------------
>Distributed via the FreeREX technical mailing list.
>Visit http://www.geocities.com/SiliconValley/2867/rex.html
>for more information!
>


-----== Sent via Deja News, The Discussion Network ==-----
http://www.dejanews.com/  Easy access to 50,000+ discussion forums

Are you talking about the "1K" blocks in the "REX*.DAT" file?

I noticed that the 1K blocks are not in order, but using the "Prev/Next"
pointers, it looks like it is possible to construct a "flat" image.

For example, I had a "REX*.DAT" file that (after XOR-key decoding) had 7 1K
blocks of "data" - the rest of the 256 1K blocks were "empty".

Each "data" block starts with "F0 0D" as the first two bytes of the 1K block,
followed by a "prev" block number and a "next" block number.  "Empty" blocks
start with "DE AD", and the "prev/next" values are both "FF FF".

Below is a dump of the first 6 bytes of each 1K in my "REX*.DAT" file (only
showing the first 10 1K blocks, since the remaining blocks are all "empty"):

(TAB-aligned, view in "fixed-width" font):
----------------------------------------------------
Offset Marker Prev Next
000000 F0 0D FF FF 02 00 Logical block "0" (start of chain)
000400 F0 0D 02 00 05 00 Logical block "2"
000800 F0 0D 00 00 01 00 Logical block "1"
000C00 F0 0D 04 00 FF FF Logical block "6" (end of chain)
001000 F0 0D 06 00 03 00 Logical block "5"
001400 F0 0D 01 00 06 00 Logical block "3"
001800 F0 0D 05 00 04 00 Logical block "4"
001C00 DE AD FF FF 02 00 "Empty"
002000 DE AD FF FF 02 00 "Empty"

"F0 0D" means "valid" data block.
"DE AD" means "empty/unused" block.

PREV/NEXT values are stored little-endian (low-byte/high-byte)

If PREV is "FF FF", this is the FIRST logical block (start of chain)

If NEXT is "FF FF", this is the LAST logical block (end of chain)
----------------------------------------------------

So, the blocks are "physically" stored at any physical block in the RAM image -
the logical-to-physical mapping is based on the PREV/NEXT linked-list values.

Does this make sense?  Am I understanding your question correctly, or did you
mean something else?


--

On Mon, 31 Aug 1998 21:12:49   Holger Lembke wrote:
>From: holger_lembke@... (Holger Lembke)
>
>Hallo ppl.,
>
>
>current "most wanted information" is how to come from block to
>block.
>
>
>  Facts is: blocks don't begin at segment begins.
>
>
>Possible fact is: there is no "pointerarray" that points to the
>begin of the blocks.
>
>
>I'm trying to go from block to block by dummy-reading the space
>between the blocks. But it's a poor approach.
>
>
>
>Any ideas? Help needed.
>
>
>
>
>
>--
>mit freundlichen Grüßen
>Holger, +49-531-3497854
>
>------------------------------------------------------------------------
>To unsubscribe from this mailing list, or to change your subscription
>to digest, go to the ONElist web site, at http://www.onelist.com and
>select the User Center link from the menu bar on the left.
>------------------------------------------------------------------------
>----------------------------------------------------------
>Distributed via the FreeREX technical mailing list.
>Visit http://www.geocities.com/SiliconValley/2867/rex.html
>for more information!
>


-----== Sent via Deja News, The Discussion Network ==-----
http://www.dejanews.com/  Easy access to 50,000+ discussion forums

Hallo ppl.,


current "most wanted information" is how to come from block to
block.


   Facts is: blocks don't begin at segment begins.


Possible fact is: there is no "pointerarray" that points to the
begin of the blocks.


I'm trying to go from block to block by dummy-reading the space
between the blocks. But it's a poor approach.



Any ideas? Help needed.





--
mit freundlichen Grüßen
Holger, +49-531-3497854

Hallo ppl.,


The PREF-block, the MEMO-Block

I have a pref-block located not at a block begin. It is in Block 0x1d
with offset 0x17f, that is 0x757f in direct memory. I can't find any
pointer to that location. Same for MEMO-block.

07570  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50  | P
07580  52 45 46 01 00 00 00 00 01 00 00 00 00 01 01 01  | REF
07590  00 00 00 03 04 04 03 04 04 CE 07 08 1C 06 00 00  | #
075A0  00 00 00 00 00 00 00 00 00 00 00 00 00 48 6F 6C  | Hol
075B0  67 65 72 20 4C 65 6D 62 6B 65 0D 0A 48 61 6D 62  | ger Lembke Hamb
075C0  75 72 67 65 72 20 53 74 72 61 CA 65 20 32 38 34  | urger Strae 284
075D0  0D 0A 33 38 31 31 34 20 42 72 61 75 6E 73 63 68  |   38114 Braunsch
075E0  77 65 69 67 0D 0A 2B 34 39 2D 35 33 31 2D 33 33  | weig +49-531-33
075F0  34 36 37 36 00 00 00 00 00 00 00 00 00 00 00 00  | 4676


01000  F0 0D 0C 00 12 00 F8 03 54 4F 44 4F 01 00 00 4D  |       TODO  M
01010  45 4D 4F 01 0B 00 6C 04 00 00 00 00 8C 00 01 00  | EMO   l
01020  27 36 04 55 73 69 6E 67 20 50 6F 70 75 6C 61 72  | '6 UsingPopular
01030  20 4F 72 67 61 6E 69 7A 65 72 73 20 77 69 74 68  |Organizers with
01040  20 52 45 58 20 43 61 72 64 00 54 72 75 65 53 79  |  REX CardrueSy
01050  6E 63 20 50 6C 75 73 20 74 72 61 6E 73 66 65 72  | nc Plustransfer
01060  73 20 79 6F 75 72 20 6F 72 67 61 6E 69 7A 65 72  | s yourorganizer

I think there must be any way to hold up the memory chain from block
to block. perhaps a blocksize-vaule in every block header?




CONT-BLOCK looks quite difficult. Any ideas?






--
mit freundlichen Grüßen
Holger, +49-531-3497854

Hallo ppl,


I've got a linux-direct-pcmcia-card-dump from a rex.


It is the same as the data files stored by TrueSync.


So the theory is right that this is the internal representation of
the REX.

A big step, I think.




--
mit freundlichen Grüßen
Holger, +49-531-3497854

Philipp,

PA > >1.) the rex-datafile is a exact copy of the rex internal memory.
PA > >this could by tested by anyone that has a pcmcia-connection to the
PA > >rex, because it is known that the rex memory can be accessed
PA > >directly. please send me a dump :-)
PA > Well, you mean that the REX shows up like a SRAM card? Is there
PA > any known way to communicate with easy means with such a card or
PA > does it always need API-specialized software?


I've heard from Linux-Users, that they can access any pcmcia-memory
card as "normal" memory. It looks like a simple device (e.q.
harddrive or so), that can be accessed in a raw mode.


NT offers the same to any harddrive, if you have admin-rights. I
can simply access my drives as one large file.


PA > >3.) the first block is a BC01, then follows the CLDR, a CONT (?),
PA > >NOTES (?), TODO, ZONE (?), REF (?).
PA > CONT are the contacts
PA > ZONE defines your local and world timezones.

ZONE is needed to display correct times. CLDR entries are save with
GMT or so.

I'll investigate that, if I have solved my current cldr-decoding.


PA > All the blocks (CLDR, CONT, NOTES etc) start on new blocks.
PA > If a block is used <1KByte and i.e. a CLDR block is finished,
PA > space is wasted and the next (maybe CONT) block starts on the
PA > next memory segment. So the REX just searches for the next
PA > block if the needed information is not present.

PA > >Is there any wait to jump directly from block to block? from the
PA > >begining of a block to the next block?
PA > Why should it? Blocks have a definite size (1 KByte) and are very
PA > likely adressed absolutely so the CPU may have immediate access.


Ok. Lets think about a probably design aproache: If I would have to
design it, I would create linked list:

  primary list contains pointers to the blocks. So there would be a
  array of pointers to bc01, cldr, cont, etc.

direct jump into the list would be possible. the rex needs to scan
all 256 blocks to find the needed block.


why it is not that way? I don't know. perhaps they simple didn't
thought about that way.

Or perhaps they build it dynamicly inside Rex-Ram.


Next problem, waiting for a solution: what has the Rex to do to
display all schedules within a certain day?

First it must scan for the cldr-header. than scan through all
entries, check the date. if it fits into the current day: display
it. next entrie. test again.


the schedules seems to be sorted. so it could stop scanning if the
entries date is greater than the current day.


This is, if I think about energie and cpu-time, a really bad
solution. But it saves a lot storage, because all other solutions
would need (2+1+1+2) 6 bytes extra per schedule (building up a
pointer-list into the schedules). 6 bytes with 3000 schedules are
18k. a lot in 256k.


PA > >Oh, last words: my object orientated datastructure handels the
PA > >bc01-block and the cldr-block. I didn't do anything with the rest.
PA > I'll go on decoding the more simple ones... PREF etc.

Yes, good idea.

there is still some work to do with seriall communication.





--
mit freundlichen Grüßen
Holger, +49-531-3497854

On Sun, 30 Aug 1998 11:16:20 GMT, Holger Lembke wrote:
>From: holger_lembke@... (Holger Lembke)
>
>Hallo out there,
>
>after working hard at my highly object oriented datastructures for
>the rex-datafile I would like to make some statements/questions etc.
>about the structure. Despite that something sounds like "facts", I'm
>not sure that is is.
>
>
>1.) the rex-datafile is a exact copy of the rex internal memory.
>this could by tested by anyone that has a pcmcia-connection to the
>rex, because it is known that the rex memory can be accessed
>directly. please send me a dump :-)
Well, you mean that the REX shows up like a SRAM card? Is there
any known way to communicate with easy means with such a card or
does it always need API-specialized software?

>2.) every memory begins with a FFFF-00xx-block, that means the first
>block is the begin of the prev-next-block-memory-chain.
Agreed. Block 0 always has FFFF as PREV so it is the first block.
(hardcoded)

>3.) the first block is a BC01, then follows the CLDR, a CONT (?),
>NOTES (?), TODO, ZONE (?), REF (?).
CONT are the contacts
ZONE defines your local and world timezones.

>A remark: if I would design such a device, I would build a list of
>pointers, that points to the begin of BC01/CLDR/CONT etc.
>If there is no such list, that means:
>  - the rex device builds up this list dynamicly
> or
>  - the rex dev. did not need that list, because the blocks have a
>    predefined sequence.
All the blocks (CLDR, CONT, NOTES etc) start on new blocks.
If a block is used <1KByte and i.e. a CLDR block is finished,
space is wasted and the next (maybe CONT) block starts on the
next memory segment. So the REX just searches for the next
block if the needed information is not present.

>Is there any wait to jump directly from block to block? from the
>begining of a block to the next block?
Why should it? Blocks have a definite size (1 KByte) and are very
likely adressed absolutely so the CPU may have immediate access.

>Oh, last words: my object orientated datastructure handels the
>bc01-block and the cldr-block. I didn't do anything with the rest.
I'll go on decoding the more simple ones... PREF etc.

Philipp Adelt
Bielefeld, Germany

Hallo out there,


after working hard at my highly object oriented datastructures for
the rex-datafile I would like to make some statements/questions etc.
about the structure. Despite that something sounds like "facts", I'm
not sure that is is.


1.) the rex-datafile is a exact copy of the rex internal memory.
this could by tested by anyone that has a pcmcia-connection to the
rex, because it is known that the rex memory can be accessed
directly. please send me a dump :-)



2.) every memory begins with a FFFF-00xx-block, that means the first
block is the begin of the prev-next-block-memory-chain.



3.) the first block is a BC01, then follows the CLDR, a CONT (?),
NOTES (?), TODO, ZONE (?), REF (?).




A remark: if I would design such a device, I would build a list of
pointers, that points to the begin of BC01/CLDR/CONT etc.

If there is no such list, that means:
   - the rex device builds up this list dynamicly
  or
   - the rex dev. did not need that list, because the blocks have a
     predefined sequence.


Is there any wait to jump directly from block to block? from the
begining of a block to the next block?



Oh, last words: my object orientated datastructure handels the
bc01-block and the cldr-block. I didn't do anything with the rest.



The rexanalyse.EXE will show this datastructures in an explorer like
tree. my latest work will be available 98-08-30 late at night, don't
expect to much work done within the week... :-)


See http://home.braunschweig.netsurf.de/~holger.lembke/rex/rex.html



--
mit freundlichen Grüßen
Holger, +49-531-3497854

Test