The "Millennium" Bug wrap-up
Created | Updated Jan 28, 2002
As reported elsewhere in the guide this millennium started in 2001, not in 2000. The First Century AD started with the year 1, remember.
This in turn was largely due to the Roman numerals popular at the time lacking a zero, which is another story entirely.
Bugs were real creepy crawlies that fried themselves in the Vacuum tube valve-based computers of Grace Hopper's era. Back then Peter Pobgee was at the NPL trying to make reliable memories with ripples in mercury delay line troughs before moving on to cylinder and drum magnetics.
No, the non-Millennium thing was anticipated even in its inception, as you will hear.
Back in the 1970s, microcomputer "clocks" were usually electrical ticks that naggled a microchip's clock input pin to make the machinery inside whirr satisfactorily. Think of it as turning the handle on a mechanical toy.
Synchronous logic worked best with 2-phase clocks whereas ripple logic pretty well guaranteed that it would glitch. If you wanted to tell the time, you used a wristwatch that was probably dumb analogue and had to be wound. Well, that's all I could afford then on an engineer's wage with two kids and a mortgage.
However one company made an alarm clock chip that could be read (sort of) by a computer. I forget the details, it's a long time ago, but the problem was that this thing would fling the data out without a pause, and this frequently tripped up the computer reading it. After all it was just a variant on an alarm clock chip.
This company was National Semiconductor Corporation of Santa Clara, California, and their applications engineers became aware that the world was getting very interested in these "Real Time Clocks" for computers.
It seems obvious now, but in pre-IBM PC days computers were (mostly) mainframes or toys. Mainframes were big, and needed only one 'real time clock' per umpteen users, so no chip demand there. And toys didn't need a wristwatch, did they?
However (as we know) a palpable demand did exist, and in the way of corporations, the mighty NSC set to designing not one but two RTCs. One in California for the embryonic computer market, and one in Greenock, Scotland for the 1980s European smart TV market (Que?). This caused some friendly rivalry. Remember, this is in the days before desktop CAD so it was all hand-designed and hand laid out with tools that Leonardo would recognise.
For completeness their part numbers were MM58174 (Scotland) and MM58167 (Santa Clara). As if you cared.
A downy-bearded lad with a young family was in a meeting where the Santa Clara design team put their proposed approach to the assembled application engineers. The year was probably 1978, and the registers in which the date and time appeared were discussed, including the fateful register that held the Year number. It was agreed (not without some laughter) that two digits was fine, since there were twenty two years before it became a problem. Ah, youth.
In context, most of the silicon chip makers were not much more than five years in the big time, and besides, in 22 years this thing would be bound to be replaced, wouldn't it? Big grins all round.
Besides, any fool could trap for year rollover in software.....
Well, the Scots were out first with their simple but functional 58174, and Santa Clara followed on with their all-singing 58167 that was nonetheless kept as lean as possible to reduce size, improve yield and maximise profit. No space therefore for an unnecessary extra year digit......
This Californian 58167 was (wisely) chosen by IBM for the first PC, and as a consequence of its success was perpetuated for all time in endless chip revisions and (eventually) in the 'Jungle' PC chips.
Over subsequent years these jungles gradually reduced the many chips in an IBM-derived PC to a mere handful.
Warts and all, the 58167 registers are likely still in there somewhere, because todays PCs are direct lineal descendants of the original, spavined 8088-based PC thing.
So it's not a bug, people. It's a _design_feature_!
And besides, any fool would have trapped the year rollover in software design. Many did, and their software ran smoothly.
Did yours?
So what about the next millennium?
That's too far away to worry about, isn't it?
Isn't it?