home *** CD-ROM | disk | FTP | other *** search
- From: dal@syntel.UUCP (Dale Schumacher)
-
- [close@cacilj.UUCP (Diane Barlow Close) writes...]
- > In article <3229@cs.dal.ca> silvert@cs.dal.ca (Bill Silvert) writes:
- >>- I asked about a bug I have run into, and they hadn't run into it --
- >> have any of you? My date function doesn't work, it always generates a
- >> date on Jan. 1 some year in the 21st century (which year I forget).
- >> The guy I spoke for said it works for him. Perhaps it involves my
- >> clock-setting software -- I use the clock that comes with the Supra
- >> 60-Meg hard drive, which seems to work fine for everything else.
- >> Anyone have any idea what the problem might be? It would be a very
- >> useful function if I could get it to work!
- >
- > There are actually 3 clocks in the ST. They are the keyboard clock, the TOS
- > clock, and the BIOS clock. Some hard drives set only one clock. My BMS card
- > sets only the TOS clock. If I remember correctly, I think WP uses the BIOS
- > clock (a leftover from PC days, perhaps?). Since the BMS clock only sets the
- > TOS clock, my time and date in WP are screwed up (Jan 20 20??, way in the
- > future).
-
- I don't think there are really 3 clocks in the ST, only 2, but you're on
- the right track. The Supra SUPCLKRD program reads the clock in the disk
- drive and sets the GEMDOS time accordingly. The GEMDOS time (or system
- time) is reset on even a warm-boot and defaults to some time in 1985.
- This is the time used to time-stamp files when they are created and is
- the most often used time reference. The BIOS time (or keyboard time) is
- maintained by the processor in the keyboard and is independent of the
- system clock. It also retains it's time setting through a warm-boot, but
- not through a cold-boot. On cold-boot (power off), the keyboard clock
- defaults to the 20xx year value described above.
-
- > To fix this irritating problem, my husband wrote a small program in Mark
- > William's C that sets the BIOS clock. Since it's a small program, I'll
- > include it here:
- >
- > /* set all clocks according to TOS time */
- >
- > #include <time.h>
- > #include <osbind.h>
- >
- > main() {
- > tetd_t td;
- >
- > td = ((long)Tgetdate()<<16) | (unsigned)Tgettime();
- > Settime(td);
- > Ksettime(tetd_to_tm(td));
- > }
-
- There are a number of MWC specific features here, like Ksettime() and
- tetd_to_tm(), so I'm not certain what this is really doing, but I assume
- that it "does the right thing" when compiled with MWC. From the operating
- system level there are a set of GEMDOS functions for reading/setting the
- system time, they are:
-
- #define Tgetdate() (int)gemdos(0x2A)
- #define Tsetdate(date) gemdos(0x2B,date)
- #define Tgettime() (int)gemdos(0x2C)
- #define Tsettime(time) gemdos(0x2D,time)
-
- ...and there are a couple of XBIOS functions for reading/setting the
- keyboard time, they are:
-
- #define Settime(time) xbios(22,time)
- #define Gettime() xbios(23)
-
- The parameters for these calls differ considerably, so you should look
- them up before trying to use these calls. I expect that the problems
- of the original poster were due to using the XBIOS calls and thus refering
- to the keyboard clock, which wasn't being set properly.
-
- ...AND NOW FOR SOMETHING COMPLETELY DIFFERENT... A BUG REPORT!
-
- There is a nasty bug that crops up when you are working with both clocks
- at the same time. If you read the system date and time, then read the
- keyboard time, and immediately set the system date and time, the KEYBOARD
- clock will stop counting and seems to set itself to an unusual value.
- If you read the keyboard clock first, then the system, and then set the
- system tim Hdre is a program which handles all of thes% problems correctly, sets
- both clOck, works nicely from the /AUTO/ folder and is fairly intelligent
- about determining good defaults vor the time.
-
-