Newsgroups: comp.sys.nsc.32k
Path: utzoo!utgpu!jarvis.csri.toronto.edu!turing.toronto.edu!funke
From: funke@turing.toronto.edu (Mark Funkenhauser)
Subject: Re: Fix to ICM3216 w/ UoTBSD4.2 clock problem
Message-ID: <89Jan26.203842est.4327@turing.toronto.edu>
Keywords: BSD ICM clock fix
Organization: /usr/local/lib/organization
References: <509@hocpa.UUCP>
Date: Thu, 26 Jan 89 20:38:42 EST

 In article <509@hocpa.UUCP> rusty@hocpa.UUCP (M.W.HADDOCK) writes:
 >
 > ... it appears that I've found a fix for the rtc_clock.  My patches
 >are for the file "/usr/sys/16k/clock.c" and you'll need to recompile/relink
 >your kernal!  The symptom I was seeing (yours might differ but I can't see
 >how) was the console displaying
 >
 >		rtc_clock: Off by 86400 seconds!!!
 >
 >Anyhoot, here's the patch to /usr/sys/16k/clock.c (or /sys/16k/clock.c).

 >====
 >
 >% diff clock.c.old clock.c
 >151c151,152
 >< 	*rtc->rtc_csr = RTCCSR_24HOUR;
 >---
 >> 	/* *rtc->rtc_csr = RTCCSR_24HOUR;  I know SysVR2R2 does this too
 >> 			but it doesn't seem necessary since we do it RSN */

   Yes it does!  See below.


 >154c155
 >< 	*rtc->rtc_csr = RTCCSR_24HOUR | (gmtp->tm_year % 4);
 >---
 >> 	*rtc->rtc_csr = RTCCSR_24HOUR | ((gmtp->tm_year & 3) << 2);
 >243c244
 >< 		tim = (365 * y) + ((y - 1) / 4);
 >---
 >> 		tim = (365 * y) + ((y + 1) / 4);
 >253c254
 >< 		tim += (((i + 1) * 306) / 10) - ((y & 3) ? 64 : 63);
 >---
 >> 		tim += (((i + 1) * 306) / 10) - (((y+2) & 3) ? 64 : 63);

 =====

 I concur (well almost).
 I spent last night fixing it  ( sans the SysVR2R2 src ).
 I would have fixed it sooner but I wanted the data sheet on the clock chip
 before changing the code.

 You almost got it right.
 Line 151 (see above) MUST REMAIN.  (i.e.  *rtc->rtc_csr = RTCCSR_24HOUR; )
 DO NOT comment it out.
 The data sheet for the clock chip says that
 you cannot set the 12/24 hour clock mode in the csr register at the 
 *same* time as setting the leap year stuff.
 Therefore you must write to  *rtc->rtc_csr  twice!
  (* There's a lesson here somewhere *)


 Since RTC_CENTURY and RTC_STARTDATE are defined and used, 
 I prefer the following so that you can see how the algorithm works 
 and that if if these constants are ever changed (not too likely),
 the bug won't re-occur:

    tim = (365 * y) + (( (y + (RTC_STARTDATE & 3) - 1) )/ 4);
  and
    tim += (((i + 1) * 306) / 10) - (((y + (RTC_STARTDATE & 3)) & 3) ? 64 : 63);



 >Oh, in case there are source code differences, I bought my
 >BSD (binary license #2) around Feb-March of 1987 so it's possible that newer
 >versions of the distribution tape (WERE THERE ANY???) may already have this
 >fixed.  If so, please let me know about that too!

 I don't think there was more than 1 distribution tape.

-----------

 By the way, does anyone shutdown their system on a regular basis ?
 (i.e. every nite) and if so, has anyone had trouble with the date 
 when the machine is rebooted ?
 I have, and it looks like the 12/24 hr bit in the csr register toggles 
 on power-off (or power-on).
 Unix sets it up to be 24 hr mode, but on power-up, the chip is in 12 hr mode.
 It could be the battery but all the other data in the chip registers seem ok.


-------------------------------------------------------
Mark Funkenhauser          {decwrl,ihnp4}!utcsri!funke
CSRI                       funke@csri.toronto.edu
University of Toronto  
-------------------------------------------------------