Date : Sun, 09 Aug 2009 23:08:11 +0200 (BST)
From : johan@... (Johan Heuseveldt)
Subject: Level 4 FS Y2K query
Hi Rick,
On Sun 09 Aug, Rick Murray wrote:
> Johan Heuseveldt wrote:
> > interpretation: If the highest three nibbles are &FFF then the
> > whole is regarded as: (in hexa-dec and two 32 bit fields)
>
> Gee, that's something of a waste, setting three bytes to &F.
No, 3 /nibbles/ (or nybbles in USA).
That's 3 times 4 bits, is 12 bits - as stated.
> > The 8 bit platform is dealing in local time.
>
> While the 32 bit is dealing with UTC.
No; 40 bits. In 1/100s of seconds, since 1rst Jan 1900.
32 bits would give: 2^32 / 100 > seconds
2^32 / (100 * 60) > minutes
2^32 / (100 * 60 * 60) > hours
2^32 / (100 * 3600 * 24) = 497 days; not of much use!
With 40 bits, this is 2^40 / (100 * 3600 * 24) = 127258 days
then DIV 365 would give : 348.6.. years.
So RISC OS is at its end - unless the 40 bits field is extended to
48, or even more - somewhere in:
1900 + 348 = 2248,
though I'll expect it will be a bit sooner!
> But we cannot complain. Take a look at what
> [...]
> <http://www.heyrick.co.uk/software/webscan/>
Nice, but Wins, so no fun there!
> > 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 PROPER application, these are more or irrelevant. Apps start
> at &8000 with a header. Modules start anywhere with a header. Utilities
> start wherever without a header but with conditions... Using load/save
> under RISC OS is possible, but a bit evil.
No. The issue is that Acorn did have tried to include awareness
for the old platform, but failed in many respects. (my view)
Also note that APIs are 'loaded' with these load/exec concept.
Running a file server /needs/ this awareness. So it's a real
pitty Acorn got it wrong, or at least not up to standards.
> > 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
>
> 1901?!? I'm surprised that works, for NetFS (A3000, RISC OS 3.11) seems
> to really dislike dates before 1981!
Sprow also explained;
It's the RISC OS translation of the load- and exec address into
a date, time and file type. It has nothing to do with any reality
concerning date and time.
> I guess it is damn near impossible under RISC OS to hold both the
> load/exec AND the date - so I think perhaps rather than "abandoning" the
> eight bitters as was suggested elsewhere, they may have either:
> 1. Been too lazy to think about it much.
> 2. Felt that a RISC OS fileserver is likely to be of direct use to
> a RISC OS network, so concentrated on making that work best, even
> to the unfortunate detriment of 8 bit stations.
I think you do forget something here. The way the host system
sees whatever attributes (general term) of a file or directory
is far from important. As long as this system is reliable not
to change them in any way, the clients - our Beebs - can be
assured of correct and safe storage.
There's only a small inconvenience when dealing - like editing -
with these files on the same host system. E.g. I like to write
the 6502 code in John Kortink's 6502_BASIC.
In general the advantages are more important than a few 'issues'!
> > 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.
>
> Is that possible over Econet? 1901 isn't a valid date.
I think there is some confusion about what system we have in
mind, and on what system we have done something! :-)
It all depends on which system the date was created, and on
which system it is displayed.
Showing 1901 almost always means a proper Beeb file!
Greetings,
Johan
--
Johan Heuseveldt <johan@... >
aka waarland
The best place is a Riscy place
The only perfect science is hind-sight.