Excuse me? Y2K? Now?!?That's right! While the millennium came, went, and the world didn't end... the majority of the Econet hardware around predates the event.
If you are a collector, it may be useful to know how the equipment copes with the date change, and - furthermore - what limitations exist.
Econet protocol (original)The original Econet protocol allocated only four bits for holding the year, which is an offset from 1981.
The roll-over would have occurred at the end of 1996.
In communications with the FileStore (older E01 models, and Level2/Level3), communications with function code 0 argument 0 (examine file) return information in the form:
This is replicated in function code 16 (read date and time).
Econet protocol (later)As it was determined that 1997 was within the lifetime of Econet systems, the date was expanded to provide seven bits. Therefore the official Econet rollover will be in 2108.
The data is modified thus:
The year, offset from 1981 as always, is comprised by taking the 3 bits from the first byte and shifting them atop the four bits from the second byte, like 1112222; or in BASIC:
year% = (((yearday% AND %11100000) >> 1) + (yearmonth% >> 4))
In pictorial form, the date is laid out as:
Level 2 and Level 3 serversThese servers will fail to return a correct date after 1996.
J.G.Harson has written a patch for both of these servers to correct this problem.
FileStore E01Some versions fail to return a correct date after 1996.
Early versions of the E01 only used a 4 bit year offset. If your FileStore is so affected, you should either upgrade your ROMs or look for a second-hand FileStore that does work correctly.
FileStore E01STested on random dates between 2000 and 2080. All works correctly, though dates over this may not work due to hardware limitations.
I do not remember if I tested the 29th February roll-over. It is a moot point though, as that date has long passed.
SJ MDFS ROM version 1.05, software version 2.00Tested on random dates between 2000 and 2080. All works correctly.
Note that the date adjustment program will allow dates up to 2108. This does not work, as dates above about 2090 will roll over.
Acorn Level 4Will not be affected - uses the RISC OS time facilities to implement the Econet date.
awServerWill not be affected - uses the RISC OS time facilities to implement the Econet date.
BBC Atom / B / B+I do not know how these stations will cope with a post-Y2K date.
I am inclined to think that it will not matter as - these computers do not normally include date facilities so will rely upon support from the server.
BBC Master / Master Compact / CommunicatorI do not know how these stations will cope with a post-Y2K date.
I would imagine that two versions of the Master 128 exist - the early ones that cannot cope with such dates, and later ones that can. I am using the logic of the E01 versions here - but it is just a guess.
The interesting thing is the Master Compact, which has a sort of NVRAM (apparently limited in how many times you can write to it, some sort of E²PROM?) for system configuration, and as such it doesn't actually have an RTC, but rather maintains a 'soft clock' which can obtain a time from the server (using additional software, not by itself unfortunately). How will this cope?
Any Arthur / RISC OS machineNo 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, <=2020 ; (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
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.
A flippant attitude to the potential "Millennium" problems back in the eighties left us picking up the pieces of a pontentially expensive operation at the turn of the century. There's another potential problem lurking... On Windows (practically any 'modern' version):
There you will find an option along the lines of:
When a two-digit year is entered, interpret it as a year between...with the span being 1930 to 2029. Well, what happens in 2030?
This isn't to pick on Windows, nor RISC OS, but rather a comment/complaint that four-digit date entry should be enforced over two decades ago, and the limitations of the system calendar should be an unfixable mathematical overflow or absolute limitations in the hardware that records the time and date; namely ~2108 because that's when time runs out, or something...
ConclusionOlder Econet systems would have already suffered their rollover, in 1996, before the issue with the millennium came to media attention.
There were no forseeable problems that would have occurred as a result of the passing into the 21st century.