Date   : Sun, 09 Aug 2009 13:37:37 +0200 (BST)
From   : johan@... (Johan Heuseveldt)
Subject: Level 4 FS Y2K query

HI,

On Wed 05 Aug, Michael Firth wrote:


[Date stamping]


> Forgive my ignorance, but is this a limitation of RiscOS, or just the way 
> the desktop is displaying things?

I think it's RISC OS. I also think Acorn got it wrong.
But hey, who do I think I am!

Well some thoughts:

On the 8bit platform, the load and exec addresses are just these;
the load and exec addresses. Although some apps can have their own
use if the file is fully under that app's supervision.

    Such an app is ViewPlot, where these addresses are logical
    colours, in 4 fields of 4 bits, so it's suitable for use
    with DFS (18 bit sized address fields). I think - been a
    while since looked at - the bits 16 and 17 (the 17th and
    18th bit) are MODE information.

On RISC OS there is no flag - e.g. in the attributes - that
makes it clear wether these 64 bits are load-/exec addresses, or
the date/time stamp and file type. RISC OS does some
interpretation: If the highest three nibbles are &FFF then the
whole is regarded as: (in hexa-dec and two 32 bit fields)

    FFFtttdd dddddddd

  F  (12 bits)  recognition of date/time stamp and RISC OS file type
  t  (12 bits)  RISC OS file type
  d  (40 bits)  date/time stamp in GMT format

The 8 bit platform is dealing in local time. Even when date and time
was recognised, the two platforms are out of sync in interpretation
by a time, equal to time zone and DST.

On the 8 bit platform there is an interpretation of the highest
16 bits. If that field is &FFFF, the address is assumed to live
in the Host system, that's the 'Beeb' in a CoProcessor/2ndProcessor
environment. Any thing else in this field is regarded for the
CoPro/2ndPro, aka the parasite.
Only when no parasite active, the Beeb's memory is used.


It is not hard to see that the two systems of use and
interpretation, clashes enormously!

    It's a mystery to me why Acorn didn't get this right
    in the first place, e.g. a bit in the attributes field.
    Even when restricted to 8 bits - not touching the other
    24 bits of the 32 bits sized attributes field - there is
    still space to a dedicated bit for this purpose.

If both 32 bit fields (load and exec) are the same, then RISC OS
assumes the two addresses are indeed the load- and exec addresses.
But in many cases (e.g. your own executables) you want to
differentiate, and execution can have an offset from code start.
When BASIC saves a file, it can use a exec addr, say, &8023, which
is completely outside the file in respect to the used load addr.
Without any flag telling RISC OS exactly, how these two fields
should be interpretated, it gets it wrong almost by default.


Since Level4 is using the underlying RISC OS system, and doesn't
seem to attempt any correction, the assumption previously ventilated
that only RISC OS clients were in mind, could be valid. A *DATE file
completely wrong, both on assumption of load- and exec address, as
well being restricted to the time frame 1981..1989 seems to confirm
that.


Saving an empty BASIC file on FileStore from a Master128, the
file's *INFO/*EX details are (on the Master):

    TEST       FFFF0E00 FFFF8023   000002   WR/        09/08/09

Copying to a RISC OS system, the Filer shows:

    TEST       WR/       2  &F0E        04:22:25 13May 1901

On a A400, being both a FileStore as well as a L4FS client, copying
the file to the L4 server, the file has the same details, on both
the A440 - locally on ADFS and seen from the L4 server.
At the L4 server, looking with RISC OS (4.39), same details again.


You stated 1 Jan 1981, so I'm not sure I have understood you
correctly. Since 1981 is the year Econet year counting started
- as years are an offset 'since 1981' - and starting at 1 Jan,
it suggests a default to me, notifying no date was found at all?

If RISC OS was in control, a year of 1901 should be displayed. It
seems L4 does something? Cuurently I have no L4 running on a A5000
e.g., to check this out. So I can't reproduce this.


Well, fwiiw.


Greetings,
Johan

-- 
Johan Heuseveldt <johan@...              >
  aka  waarland

  The best place is a Riscy place

Actors will happen in the best-regulated families.