Re: bizarro pmax clock handling

Never mind.  I found the (bizarro!) answer.  Apparently pmax PROM resets
the date if it is not 1972 or 1973.  WTF were they thinking?

    -- Garrett

Garrett D'Amore wrote:
> As far as I can tell, pmax uses a standard mc146818 clock chip.
>
> Yet, what is bizarro, is this code in inittodr (and similar in resettodr):
>
>     /*
>      * The clock lives in 1972 (leapyear!);
>      * calculate seconds relative to this year.
>      */
>     dt.dt_year = 1972;
>     dt.dt_mon = ct.mon;
>     dt.dt_day = ct.day;
>     dt.dt_hour = ct.hour;
>     dt.dt_min = ct.min;
>     dt.dt_sec = ct.sec;
>     yearsecs = clock_ymdhms_to_secs(&dt) - (72 - 70) * SECYR;
>
>     /*
>      * Take the actual year from the filesystem if possible;
>      * allow for 2 days of clock loss and 363 days of clock gain.
>      */
>     dt.dt_year = 1972; /* or MINYEAR or base/SECYR+1970 ... */
>     dt.dt_mon = 1;
>     dt.dt_day = 1;
>     dt.dt_hour = 0;
>     dt.dt_min = 0;
>     dt.dt_sec = 0;
>     for(;;) {
>         time.tv_sec = yearsecs + clock_ymdhms_to_secs(&dt);
>         if (badbase || (time.tv_sec > base - 2 * SECDAY))
>             break;
>         dt.dt_year++;
>     }
>
> I can only conjecture why this is here.  The mc146818 certainly can
> store a year.  So why are we doing this?  Is this for compatibility with
> some busted old other OS?   Ultrix?
>
> Pray tell.  Because in all other respects this looks like an otherwise
> normal mc146818 based system.  I'd much, much rather gut this weird
> code, but I would like to understand why it is here.
>
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191