Acorn Computers Year 2000 compliance
NB. This document is considered by the author to accurately reflect the technical reality of Year 2000 compliance on all production Acorn kit, however it has not been ratified by Acorn's Legal dept. and as such must be treated as a non legally-binding draft.
This document is provided "as is"; Acorn Computers Limited ("Acorn") makes no warranty, express or implied, of the fitness of this document for any particular purpose. In no circumstances shall Acorn be liable for any damage, loss of profits, or any indirect or consequential loss arising out of the use of this document or inability to follow instructions laid down in this document, even if Acorn has been advised of the possibility of such loss.
Current and Historical Acorn Kit and Y2K: State of the Universe and Testing Strategy .
Caveat emptor: This document covers hardware and OS-level software only. Even on a machine specified below as Y2K-compliant, there is no guarantee that a user would not be running, say, a database package which, owing either to the way it was written or the way it was set up, only accepts two-digit year fields. Be careful out there.
System range:
No concept of real time (and therefore no Y2K problem) unless fitted with an RTC card. Speaking to Chris Turner (now at Virata) who was one of the senior engineers on the System project, he confirms that no RTC card was ever produced by Acorn (although this doesn't take third parties into account).
Atom:
No concept of real time (and therefore no Y2K problem).
BBC Model A/B:
No concept of real time (and therefore no Y2K problem) unless fitted with a third-party RTC card and running software which uses it. No second processor boxes contain RTCs either.
Pop the case, remove the keyboard and check the ROM slots on the front RH corner of the PCB; third-party RTCs tended to go in here in the form of a small card holding ROM, RTC and maybe a PAL, attached to a 28-pin header. Do not worry if you see anything which fits this physical layout but has a label containing the subword "Inter" stuck to the top of the ROM; these are PALPROMs designed to get 32K of non-time-aware application code running in a .
16K mapped address space...
In addition, examine any mezzanine boards (eg ROM / RAM) in the system; the dead giveaway to indicate the presence of an RTC is the presence of a battery either on a mezzanine board or at the end of a flying lead (and usually tucked away in the case moulding down the LH side).
Unfortunately, code to access the RTC varies wildly depending on the manufacturer of the RTC add-on. Some RTCs, particularly those released in or after 1984 when the Master was released, will emulate or attempt to emulate the Master's way of doing things; in the absence of manuals pertaining to the software interface to a particular RTC found fitted to a machine, a good first pass when it comes to certifying software would be to check it using the same metric as software to be run on a Master (see below). Otherwise, for strict conformance testing, it will be necessary to contact the RTC card's manufacturer.
Model B-hosted Acorn Level 3 Fileserver:
These systems were Model B computers fitted with either a twin floppy drive or a SASI hard disc via an adaptor on the 1MHz bus, and a potted and epoxy sealed RTC in a module which hung off the User Port. The RTC was powered solely by a NiCd cell potted on the package, which has a design lifetime of 5 years; considering the operational lifespan of these cells you are very, very unlikely to run across one of these which is still operational. Should you come across a dead one which has data on it worth recovering (note that the system will die when the NiCd dies; the L3 server software will refuse to boot), Acorn can supply a hacked copy of the fileserver software such that the fileserver can be booted readonly and without an RTC so that the data can be harvested.
Electron:
No concept of real time (and therefore no Y2K problem) unless fitted with a third-party RTC. If an RTC is fitted, contact the RTC's manufacturer.
Model B+:
No concept of real time (and therefore no Y2K problem) unless fitted with a third-party RTC card. Treat as per Model B.
Master Series:
All Master series systems (except Compact) contain a 146818 RTC. DFS-based files do not stamp with time or date, ADFS-based files do where a realtime feed is available; therefore any ADFS-based code which performs file save operations will fall over either by failing to read the actual "newest" file (as it will be incorrectly datestamped) or failing to write the actual "newest" file over an in-actuality older one with the same filename.
From BASIC, the RTC is accessed using the pseudo-variable TIME$; if this variable is found in any BASIC code, chances are that the code will break.
Also the OSWORD call below can be made from BASIC, using.
A%=
X%= ] parameters you don't need to worry about Y%= ] Z%=USR(&FFF1).
From the Supervisor, *TIME does the same thing and thus code dependent on the outcome of such a call will break.
From Assembler, the RTC is read from using OSWORD 0xE and written to with OSWORD 0xF. Any object code which, when disassembled, contains the sequence.
LDA &0F (or LDA &0E)
LDX ] whatever arguments
LDY ]
JSR &FFF1
will break.
A sideways ROM (named "Doomsday") is available for UKP 5.00 (inc. postage) from:
R P Sprowson
6 Bollinbrook Road Macclesfield Cheshire SK10 3DJ.
which claims to fix this; you can find more details on this ROM at http://www.york.ac.uk/~rps102/bbc/doomsday.htm and you will also find there an automatic code checker which looks for instances of the suspect OSBYTE calls in any given piece of application code.
Note that a Compact, although it has no internal RTC, *will* timestamp things if it receives a time feed from an Econet connection. It's as 2K compliant as its timefeed.
Communicator:
No concept of real time (and therefore no Y2K problem).
Econet FileStore:
As per Master series, with the additional proviso that some early versions of its OS ROM only handle the unextended version of the Econet time system. This would cause FileStores fitted with this software version to wrap their clocks (effectively suffering a Y2K problem) on January 1st 1997, so we can safely assume that no systems still running and using this software are left in the field :-).
Later versions of the Econet software had an additional 4 bits assigned to the time field, so the Econet epoch will not end until 21<something>.
However, the OS is likely to break as per the Master regarding Y2K. An appropriate recovery tool set would need to be built along the lines of the L2 Fileserver patch, so that data can be downloaded from a clock-stricken server before it is scrapped.
Cambridge Workstation and ABC:
Treat as per B+. The CW is effectively a Model B+ with 32016 second processor, and the ABC is ditto with Z80 second processor (although a prototype ABC was built with a 6502 second processor, I don't believe it made it into the field).
Archimedes range, Axxxx range and Risc PC:
- All these systems contain a Philips PCF8583 RTC, which sits on the internal IIC bus. Real time is enumerated as a signed integer count of centiseconds occupying 5 bytes of memory, offset from 00:00 January 1st 1900. This theoretically gives an epoch such that the clock will not wrap until just turned 00:07 June 3rd 2248; any machine still running Arthur, however, will technically fail in 2100 as it will erroneously consider that year to be a leap year.
From RISC OS 2 onwards the following applies:
It is possible to specify years in two-digit form when passing arguments to the system calls SWI "Territory_ConvertTimeStringToOrdinals" (with reason codes 2 and 3) and SWI "OS_Word",15 (with reason codes 15 and 24, which specify that the operation to be performed is a write to CMOS); in the case of these specific calls, dates supplied as arguments and which contain a two-digit year field are treated as follows:
0<year<65: 2000 is added (ie 01-Jan-44 is treated as 01-Jan-2044).
67<year<99: 1900 is added (ie 01-Jan-94 is treated as 01-Jan-1994).
The changeover point below which 2000 is added and above which 1900 is added is 26-Jan-66.00:00:00. Check code for the presence of these calls; SWI "Territory_ConvertTimeStringToOrdinals" can also be represented as SWI &40350 and SWI "OS_Word" can also be represented as SWI &07.
Otherwise, the systems should remain happy until 2248 unless code which needs to perform writes is hosted on a non-ADFS filing system which doesn't support four-digit values in year fields..