Obsession II Y2K problems in detail
The information in this post is provided to assist in troubleshooting. Perform work at your own risk. ENSURE ANY POWER FROM DEVICES HAS BEEN DISCONNECTED BEFORE SERVICING ANY EQUIPMENT. If you do not feel comfortable performing the work, please contact us or your local service center. Be aware that ETC and its Affiliates are not responsible for any damage or injury caused by service of our products by anyone other than us or our authorized service providers, and such damage is excluded from the product’s warranty.
There is a bug tied to the "CMOS is BAD" message that started appearing on all Obsession II systems on January 1st, 2000.
Here's the details:
The CMOS verification code in the Obsession program looks for very specific settings. One of them is 32 Meg of RAM only and another is a date code with a year earlier than 2000. If the CMOS checking code sees more than 32Meg of RAM (needed for 4600 channels or for running any version of 4.3) or if it sees a date on or after 1/1/2000, it will be seen as invalid. We were aware about this bug since November 1999, but were told that it would not effect the operation of the console and that we should ignore it. The CMOS checking code will not be repaired until version 4.3. By itself the "CMOS is Bad" message is does not affect the operation of the program.
Here's the problem with versions 4.0 to 4.1.2.
After the CMOS checking code returns a "CMOS is Bad" message, it writes a file to disk called "badcmos.txt". When this file is written a call is made in the Obsession program to "close ALL files". One of the files closed is "cache.$$$" which is used to store data for portions of large showflies that don't fit in the nonvolatile RAM during powerdowns. The loss of this file generates a "checkpointing failed" error and can lock the system up. Or potentially cause corruption of a large showfile.
Option 1: Preferred Method
Have them upgrade to 4.2. In 4.2 they will still see the Bad CMOS message but the "close ALL files" call is not made and they should not get the "checkpointing failed" message.
Option 2:
If 4.2 isn't an option (due to timeframe, etc.) - The corruption only occurs at boot up. That being the case, exiting to DOS and running isa960qa will flush the SRAM. You can then run obs.exe and the application will run properly. In the case of a GPF, it may be necessary to break to DOS using "Control C" on boot up.
Option 3:
Reset the date - If the show is starting in five minutes and the show hasn't loaded correctly, the least preferred work around is to set the date in Obsession to 1999. Then exit to DOS. Once in DOS type [del badcmos.txt] and press [enter]. Do this for both PU's if they have a DPS system. They should now be able to boot the console normally.
Please note that Options 2 and 3 are a temporary fix. The customer will need to upgrade to 4.2 in order to fix the problem. They will need to coordinate a time when the upgrade can be performed in a normal manner.