Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ucla-cs!wales
From: wales@ucla-cs.UUCP
Newsgroups: comp.sys.ibm.pc
Subject: Date not advancing at midnight on my clone
Message-ID: <4728@shemp.ucla-cs.UCLA.EDU>
Date: Sat, 28-Feb-87 19:35:11 EST
Article-I.D.: shemp.4728
Posted: Sat Feb 28 19:35:11 1987
Date-Received: Sun, 1-Mar-87 17:30:19 EST
Sender: root@ucla-cs.UCLA.EDU
Reply-To: wales@LOCUS.UCLA.EDU (Rich Wales)
Organization: UCLA Computer Science Department
Lines: 37

When I stay up past midnight (something which I do as rarely as possible
:-}), the date on my "turbo" XT clone does *NOT* advance to the next day
the way it should.

My system is a Wugo PCII-AD (marketed by Sun Computers Inc. -- *not*
to be confused with Sun Microsystems Inc., the graphics workstation
people).  It uses the Award XT BIOS (version 2.03) and MS-DOS 3.2.

By poking around in the BIOS with DEBUG, I was able to find what appears
to be the clock interrupt handler.  It manipulates a 4-byte counter in
0000:046C through 0000:046F; when said counter accumulates a full day,
it gets reset to zero, and the byte at 0000:0470 is set to a 1.

I was under the impression that some piece of software was supposed to
look for this flag (resetting it and advancing the date if it was ever
observed to be set).  But evidently this isn't happening on my system,
since the date isn't getting advanced, and DEBUG indicates that once
0000:0470 gets set to 1, it remains at 1 and is never changed again.

Does this sound like a bug somewhere in the BIOS?  In MS-DOS 3.2?  (I'm
going to try borrowing MS-DOS 3.1 from a friend and see if the problem
persists.)  I checked with the people I bought the computer from; they
had never heard of the problem and had no quick fixes handy.

The clock interrupt handler does an INT 1CH shortly before returning.
The default handler for interrupt 1CH is simply an IRET instruction
(i.e., the interrupt does nothing).  Is it possible that I could patch
around the date problem by writing my own handler for this interrupt and
chaining it ahead of the default handler?  If so, where should I look
for the date information in memory?  I realize I can't use the MS-DOS
"get system date" call (Int 21H, Function 2AH) inside an interrupt
handler, so I assume I'll have to modify the date info directly.

-- Rich Wales // UCLA Computer Science Department // +1 213-825-5683
	3531 Boelter Hall // Los Angeles, California 90024-1600 // USA
	wales@LOCUS.UCLA.EDU   ...!(ucbvax,sdcrdcf,ihnp4)!ucla-cs!wales
"Sir, there is a multilegged creature crawling on your shoulder."