Hi, I have this info on Metastock format, but the .dat files
are not text, they are some sort of binary.  Does anyone know
how they are stored internally?  Failing that, could someone
enter data for a bogus company (called XYZ or something) with
a price of $6.66 on 13/12/95 etc and then give me a hexdump
of the created file?  It is easier to reverse-engineer the
data format if I know an example of the input.  I do have
some metastock data here, but I don't know the values inside
it, all I know is that it is the S&P index for unknown dates.
I have made an unsuccessful attempt, as you will see below 
the quote.

============================================
 * Original From: Maurice Tindall, 3:800/822
 * Original To  : Paul Edwards, 3:711/934.9
 * Original Date: 1995-10-09 08:15
============================================

Hello Paul,

MT>    I have 5 years of ASX historical data including local and overseas
MT>    Indices for sale.

 PE> Is this data from the ASX themselves?  If so, could you do me a
 PE> favour and tell me the format of it?  E.g. file called MAYD.PRN

    Sorry about the delay - I don't get on this echo very often.
    
    The data is from Almax and is in Metastock format.

    Order and form is --

                Date Open High Low Close Volume    

                Date format is mm/dd/yy - not the US style

    This format is easily changed to comma delimited ascii with a 
    decent conversion program, even to the extent of eliminating data 
    which you may not require.  Say DCV or even just DC.  
                                        
    The files themselves are named f(n).dat, each with a small format 
    file f(n).dop, but the full name does appear when opened in an
    analysis program.

    Hope this is sufficently clear.

    Regards.........Maurice


    
... Surfing the Internet/Fidonet/Usenet on a wsOMR!
~~~ wsOMR/1.04b [UNREG]


Here is an example of some of the index data that I have...

000000  0000D404 00000000 00000000 00000000  ................
000010  00000000 00000000 00000000 20D35B94  ............ .[.
000020  B85E6E88 B85E6E88 B85E6E88 B85E6E88  .^n..^n..^n..^n.
000030  B85E6E88 00000000 30D35B94 D7E36F88  .^n.....0.[...o.
000040  D7E36F88 D7E36F88 D7E36F88 D7E36F88  ..o...o...o...o.
000050  00000000 40D35B94 29DC7088 29DC7088  ....{at}.[.).p.).p.
000060  29DC7088 29DC7088 29DC7088 00000000  ).p.).p.).p.....
000070  50D35B94 5CCF7088 5CCF7088 5CCF7088  P.[.\.p.\.p.\.p.
000080  5CCF7088 5CCF7088 00000000 60D35B94  \.p.\.p.....`.[.
000090  F6A87088 F6A87088 F6A87088 F6A87088  ..p...p...p...p.
0000A0  F6A87088 00000000 90D35B94 5C8F6F88  ..p.......[.\.o.
0000B0  5C8F6F88 5C8F6F88 5C8F6F88 5C8F6F88  \.o.\.o.\.o.\.o.
0000C0  00000000 A0D35B94 33B37088 33B37088  ......[.3.p.3.p.
0000D0  33B37088 33B37088 33B37088 00000000  3.p.3.p.3.p.....
0000E0  B0D35B94 9A597188 9A597188 9A597188  ..[..Yq..Yq..Yq.
0000F0  9A597188 9A597188 00000000 D0D35B94  .Yq..Yq.......[.
000100  0AD77088 0AD77088 0AD77088 0AD77088  ..p...p...p...p.

The DOP file suggests that there is a field called "OI" in
addition to the above fileds mentioned by Maurice.  I will assume
by the large runs of numbers that there are 5 values, all the
same, which represent the price, since that's what we have the
most of.  I will assume also that the fact that they are always
the same is because we have no better data than that they are
all the same.  The fact that it is the rightmost bit that varies
the least from day to day means that it is stored in little-endian
format long integers.  The data appears to be grouped in fields
of 7 long integers.  The first record appears to be a header 
record, possibly specifying the number of entries in the file.

I will assume that that number is 0x04d4 rather than 0x04d40000,
meaning that there are 1236 entries.  since the file that I am
looking at is 34636 bytes long, that makes it 28.02 bytes per
entry.  7 longs of 4 bytes is 28.  So that sounds close.  
34636/28 = 1237, so the 1236 obviously doesn't include the 
header record.

Now the date portion, assuming it is the date, starts off with
a 20D35B94, which is 0x945bd320.  This gets changed to 0x945bd330
for the next entry, etc, always being incremented by 0x10.  Looking
at the original file, I note that when it goes from 0x945bd3f0
that has finished incrementing, it goes to 0x945bd400 (or it would
if there wasn't a weekend in the road).  So this is looks like a
fairly straight count on days since an arbitrary point in time,
using increments of 16 decimal per day.  I will need a date to
match with this though, in order to determine that arbitrary
point.  Obvious choices are 1/1/1980, 1/1/1970, 1/1/1900, 1/1/1.
The number of days is then actually 0x945bd3f, which in decimal
is 155565375.  With 365.25 days per year, that would be 425914
years, which is obviously way out.  Let's try dropping the 94,
so we get 0x5bd3f, trying to get a number of days out of that.
That makes it 376127 days, or 1029 years.  No, that doesn't make
any more sense.  I will need some real data to determine how
the year is calculated.

The volume looks like the 7th long integer, and presumably that
data is unavailable hence the consistent 0.  Why there are 5
different values for the price I don't know.  Open, close, high,
low have been specified.  Maybe there's an average too?  What
does "OI" stand for I wonder?  

Nope, can't help without real data.  BFN.  Paul.
@EOT:

---