Quick Links:   [Home] [Menu] [BASIC] [TEXT] [TELCOM] [Diff] [Tech Ref] [Files] [Links] [Y2K]

This information revised September 1999.

First off, a little nitpicking. The new millenium does NOT start January 1, 2000 as reported widely in the press. A century is 100 years long and the Anno Domini (AD) calendar started with year 1. Thus, a century runs from year 1 to year 100. The current 20th century runs 1901-2000. The new millenium does not, therefore, start until January 1, 2001. However, the year 2000 (Y2K) problem has nothing to do with the millenium and everything to do with that last year of the century flip from 99 to 100.

The Y2K bug has caused a lot of commotion in the computer industry, and unfortunately much of the information about Y2K is being given by incompetent people. I don't mean to be harsh, but there are too many people that don't know anything about the technical side of the problem giving incomplete and sometimes incorrect information. I will attempt to discuss the issues of Y2K and the NEC PC-8201A in a calm and complete manner.

The NEC issues are identical to the Tandy Model 100 and Tandy Model 102 issues. These machines have the same problems. I will refer to the NEC in this discussion, but my comments apply equally well to the Tandy models.

Let's answer the most important question. The NEC PC-8201A, Tandy 100 and Tandy 102 are not Y2K compliant. However, the noncompliancy issues are minimal and software problems may be avoided.

Now for the gory details. As you have most likely heard, many computer systems and programs will not handle the transition from the year 1999 to the year 2000 properly. Systems that return two-digit years may misinterpret the year 00 as 1900 instead of 2000. Even those systems with four-digit years may have fixed century data. A second problem is that 2000 is a leap year and some systems will not accept 02/29/2000 as a valid date. These issues are collectively known as the Year 2000 bug, known as Y2K for short.

The first NEC PC-8201A Y2K problem is that the DATE$ function accepts and returns only two-digit years. Thus, any program using the DATE$ data might not be programmed to interpret the year 00 as 2000. Each program using DATE$ data will have to be tested to determine its individual compliance. Programs employing a date windowing technique with DATE$ data should handle the Y2K transition properly. Other programs will likely fail.

Date windowing may be accomplished within user-written BASIC programs by interpeting the year portion of DATE$ within a user-selected boundary condition. For example, assume that you choose to split the 00-99 range of DATE$ as 00-59 and 60-99. You would then compare the year portion of the DATE$ response to 60 and either add 1900 or 2000 to the year value. This technique is a fix to make 2-digit year systems Y2K ready. It is not a full compliancy fix since the DATE$ function remains a 2-digit function. However, it will keep your DATE$-dependent code working fine through the rollover. The reprogramming of the system ROM to make DATE$ a 4-digit Y2K compliant function is complex and has very little chance of being implemented by anyone.

The second NEC PC-8201A Y2K problem is that the date on the MENU display includes a fixed 19 in the year. Any two-digit year entered into the system via DATE$ will be displayed in the range 1900 through 1999. This problem is cosmetic only. Since DATE$ operates only with two-digit years, the fixed 19 appears only on the MENU display. Unfortunately, this item is the one people notice. Users mistakenly confuse the "19" on the MENU screen with Y2K compliancy. The problem is a display issue only, and its narrow scope makes it one that users should learn to ignore.

The third NEC PC-8201A Y2K problem is hardly worth mentioning, but I will. The NEC does not recognize any leap years, so it will not recognize the leap day in the year 2000 ... or 2004 ... or 2008 ... etc.

The lack of Y2K compliance does not mean that the NEC will not work past the year 2000. It means that there are certain complications to programming tasks using DATE$ data. It also means that you will need to ignore the 19 in the year displayed by MENU. The problems with DATE$ in programs may be "solved" by using a windowing technique for DATE$ responses -- any two digit year below a certain chosen number may be associated with the 21st century instead of the 20th century.

The NEC PC-8201A's built-in programs will continue to operate fine before, during, and after the Y2K transition. TEXT and TELCOM have no date dependencies. BASIC's only dependency is the 2-digit issues with DATE$. The machine will soldier on as a fine laptop well into the 21st century. Enjoy.

Your Potent Portables webmaster is a member of the Y2K assessment, testing and remediation team for a large energy company. I am directly involved with the discovery and repair of Y2K issues in embedded systems and data acquisition equipment/software. I have the credentials and experience to size up the problems in the NEC. If you don't believe me to give you the full scoop on Y2K on the NEC, M100, T102, etc. I don't know that you'll believe anybody.

I've read a lot of bull regarding Y2K. The hype can be overwhelming to the inexperienced person. It might make you want to dig a foxhole and spend December 31, 1999 with a rifle and 1000 rounds, guarding your creamed corn and baked beans. Don't be that naive. If you need assistance with your NEC, M100, T102, or software applications running on these machines, ask one of the fine people on the Club 100 listserv for guidance. I will respond to personal email as well.

Original author of this page: David Firth.

This page best viewed on ANY browser. This author strongly supports access by persons with limited-capability and text-only browsers. Content is better than flash & dazzle.