wales@ucla-cs.UUCP (03/01/87)
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."
tr@thumper.UUCP (03/01/87)
I have had your problem and so have many others. Someone told me that it is a bug that Microsoft has acknowledged but they don't plan to fix it in the near future. The bug appears in just about every version of PC-DOS and MS-DOS. If you do manage to fix it, let us know how. Tom Reingold -- Tom Reingold tr@bellcore.com
wtm@neoucom.UUCP (03/02/87)
The date roll-over problem is a well-known bug in DOS. Virtually all flavors of MS and pc DOS have it. It's been a while since I looked the code over, but it If I remember right, the timer tick interrupt sets a date rollover flag at midnight. Normally, the keyboard interrupt would call code that would handle the flag and make sure that the date got changed. The problem arises if the first operation after midnight is disk I/O, then the state of the rollover flag is lost, and the date gets stuck. Note that you are still gyped if you leave your machine on, but idle over the weekend, becuase the flag will only be set once, and the computer won't be aware that there has been more than 24 hours elapse since the flag was last checked. Basically dumb, but that's what you get from something designed for the business world that only has to be right from 8:00 to 17:00 (grin). --Bill Bill Mayhew Division of Basic Medical Sciences Northeastern Ohio Universities' College of Med. Rootstown, OH 44272 USA phone: 216-325-2511 (wtm@neoucom.UUCP ...!cbatt!neoucom!wtm)
davidsen@steinmetz.UUCP (03/03/87)
If you put the date in your prompt, some of this will go awy (at
least on most MSDOS systems). The date is only advanced when it
is interrogated. Even this solution only works for one day. The
EGA screensaver we got with a Quad EGA cures the problem, and
I'm trying another version for mono/CGA this week to see if it
solves the problem.
Have hope, you are not alone!
--
bill davidsen sixhub \
ihnp4!seismo!rochester!steinmetz -> crdos1!davidsen
chinet /
ARPA: davidsen%crdos1.uucp@ge-crd.ARPA (or davidsen@ge-crd.ARPA)neff@hpvcla.UUCP (03/03/87)
I have the same problem on my genuine "true blue" XT. It seems to me that the date does not advance at midnight while also accessing the hard disk at midnight. This could be my imagination, but it seems that an idle system does advance the date correctly and a busy system sometimes advances the date correctly. I have set the time to be a few seconds before midnight, typed DIR on a long directory, and then checked the date -- its wrong. This has been frustrating to me since I often do very large makes all night long and the dates of the object files get out of wack. I just do a touch (using pc-shell) of the object files the next morning. Dave Neff ihnp4!hpfcla!hpvcla!neff
rde@ukc.ac.uk (R.D.Eager) (03/08/87)
I had this problem on MS-DOS 2.11 on a British PC clone. I also managed
to fix it, but the nature of the fix means that it works ONLY for one
version (and OEM implementation) of DOS.
The BIOS time of day call (INT 1AH) is what DOS uses to get the
time. This is used by the DOS kernel only to get the time of day. The
call returns the time in CX/DX, and a flag (indicating date rollover) in
AX. This flag is nonzero if the day has rolled over since the last call,
and by definition is returned ONCE ONLY after a given midnight.
Now, the real problem is that the OEM portion of DOS may also call the
INT 1AH function, and many implementations do this to provide a timeout
on disk access in order to make up for the lack of door latch status on
IBM style floppy drives. The details don't matter, but a call from one
of these just after midnight clears the rollover flag so that the DOS
kernel never sees it.
My solution was messy (and doesn't handle the case of an idle machine
being left for a weekend), but it does work.
First, scan thru the DOS file IO.SYS or IBMBIO.COM, looking to INT 1AH
calls. Find the one that seems to do something with AX on
return. Figure out from this code (easier than it sounds) the word where
DOS obviously keeps the day number.
Second, write a little intercept (TSR) routine for INT 1AH. Do nothing
on the way in, but on the way out check AX. If it is nonzero, clear it
and increment the DOS day number yourself.
This WORKS. But, you need a different version for different versions and
flavours of DOS (because the day number isn't always in the same
place). It's a good idea to put some checks in to stop it being used on
the wrong version and zapping some other word.
--
Bob Eager
rde@ukc.UUCP
rde@ukc
...!mcvax!ukc!rde
Phone: +44 227 66822 ext 7589john@xanth.UUCP (John Owens) (03/19/87)
Well, I thought I had explained this at length some time ago, but I
can't find the article, so....
There is a mis-design in IBM's BIOS, both XT and AT, such that when the
time-of-day clock passes midnight, the date wrap flag is *set*. This
gives no indication of how many days have passed, just that *at least
one* has passed. Once the time is read, which returns this flag in a
register, the flag is cleared. These have been propagated for the sake
of compatibility.
So, DOS would need to read the time at least once a day, or lose days.
So far, so good, but there was another bug in the device drivers
supplied to IBM by Microsoft. It would read the clock to decide whether
or not a disk might have been changed, but it would not note the setting
of the date-changed flag, so the fact that this flag had been set would
be lost. The next time that the clock driver checks, the flag isn't
set, so the date doesn't get changed.
This bug was fixed a while back. I'm not sure what version, but
certainly the 3's would have it.
So much for the "lose date change while accessing floppies at midnight
bug", but that still leaves the "multiple date rollover bug", wherein
you leave your system idle, over a weekend, say, and the flag gets set
several times. You come back in on Monday, create a file or somesuch,
and it says "Oh - the midnight flag! It must be Saturday now!" This
still exists in PC-DOS 3.2, the "generic" "retail" MS-DOS 3.2, and the
MS-DOS 3.2 OEM kit.
*However*, Microsoft does have a fix for the problem, but it turns out
that the fix breaks something to do with the runtimes for the BASIC
Compiler, so they took it out. I would not be at all surprised if
various OEMs got the original fix or wrote their own....
Disclaimer: All this was discovered through unconscious psychic
communication with the MS-DOS systems software group, and I take no
responsibility for the implications of its correspondence to the real
world. (Whatever that is.)
--
John Owens Old Dominion University - Norfolk, Virginia, USA
john@ODU.EDU old arpa: john%odu.edu@RELAY.CS.NET
+1 804 440 3915 old uucp: {seismo,harvard,sun,hoptoad}!xanth!john