<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
Date   : Mon, 10 Aug 2009 03:05:10 +0200
From   : rick@... (Rick Murray)
Subject: Level 4 FS Y2K query

Johan Heuseveldt wrote:

>> Gee, that's something of a waste, setting three bytes to &F.
> No, 3 /nibbles/ (or nybbles in USA).

Duh! <bangs head on wall>


>>> 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.

Um, I meant 32 bit as in the platform. :-)


>   1900 + 348 = 2248,
> though I'll expect it will be a bit sooner!

In my Econet Y2K doc, I say:
--8<--------
No problems anticipated. The rollover is something like 2108. I'll be 
long-gone by then. ?

What worries me, however, is this little comment in the RISC OS sources:

   ; Year should be >=1995, < 20
   ; (2020 is arbitrary, but everything breaks soon after that)
           MOV     R0, #YearCMOS+1
           BL      Read
           TEQ     R0, #19
           BNE     check20

[in RiscOS.Sources.Kernel.s.NewReset on lines 762 to 767]

What the hell?!?!? The year 2020 is too damn close to see things like 
that in the sources. It isn't the arbitrariness that unsettles me, as 
that could be corrected for softload OSs and patched around for older 
OSs in ROM... what worries me is the "but everything breaks soon after 
that" comment.
What exactly breaks? Where? Why?
--8<--------

Anybody know what exactly is 'broken'? Everything what?


> Also note that APIs are 'loaded' with these load/exec concept.

I think the load/exec is pure legacy support, like BASIC trapping OSBYTE 
(etc) addresses and faking the action.
It prob'ly seemed like a good idea in Arthur, but some stuff progressed 
little beyond then; like the disparate mess that is OS_Byte!


> 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.

True, but can you not - on a FileStore - set a bit of code with a 
load/exec address, and also say WHEN the file was written?

Is that possible under Level4? The attributes of the host system IS 
important, as it is the host that is making the limitation.


> Showing 1901 almost always means a proper Beeb file!

Ah, so you see 1901 on the RISC OS machine serving the file. I'm with 
you now. What does it say *on the Beeb* if you try to read the timestamp 
of the file?


Best wishes,

Rick.

...mmm, I oughta change this... \/ \/ \/ \/
-- 
Rick Murray, irregular internet access at local library.
BBC B: DNFS, 2 x 5.25" floppies, EPROM prog, Acorn TTX
E01S FileStore, A3000/A5000/RiscPC/various PCs/blahblah...
<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>