Y2K compliancy

EEA index Intro What is it? Y2K issues The servers Mailing list FileStore MDFS Others Clocks Bridges Interfaces Misc h/w Testing Misc info

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: Offset    Value 4-13 file title 14-17 reload address 18-21 execution address 22 access LWR/WR (bottom 5 bits) 23 date: day 24 date: year since 1981 (4 bits), month (4 bits) 25-27 system internal name 28-30 size of file 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: - date: year MSBs (3 bits), day (5 bits) - date: year LSBs (4 bits), month (4 bits) 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 servers These 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. In addition to allowing dates after 1996, it supports Y2K - up to 2080. A sliding window approach has been chosen, so dates between 81 and 99 are assumed to be 19xx, all other dates 20xx. You can download the patches from the main EEA index (under 'Software').   FileStore E01 Some 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. If you have a ROM image of an E01 that works correctly after 1996, could you send it to me so that I can offer it for download? This will allow people with a non-working E01 to burn a replacement EPROM and revive their machine.   FileStore E01S Tested 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.00 Tested 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 4 Will not be affected - uses the RISC OS time facilities to implement the Econet date.   awServer Will 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. If you can clarify this, especially if you can give versions of ROMs that are known to work/fail, please contact me.   BBC Master / Master Compact / Communicator I 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? If you can clarify this, especially if you can give versions of ROMs/machines that are known to work/fail, please contact me.   Any Arthur / RISC OS machine 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, <=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 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? 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): Control Panel -> Regional and Language Options    (may be called 'Regional Settings' on Win9x?) -> Customize (XP only - and if it knows it is using English    (British), can it please learn to spell 'customise' correctly?!?) -> Date. 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...   Conclusion Older 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.