close@cacilj.UUCP (Diane Barlow Close) (04/15/89)
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! I had the same problem when I got my new hard drive. It does, indeed, seem to be a problem with the clock-setting software (I use Supra software even though my drive is a Micropolis 1335 with a BMS 200 card). 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). 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)); } That's it. Try it out and see if it works. Run it *after* you've run your setclock program. -- Diane Barlow Close {uunet, crash, ucsd}!cacilj!close close@cacilj.uucp Free Canada -- Trade Mulroney
silvert@cs.dal.ca (Bill Silvert) (04/19/89)
I appreciate John's information about the clocks, but I remain a bit
confused about what is happening. The Paul Close program that his wife
posted gives me separate readings for three clocks when I boot with the
Supra clock-reading program: the TOS clock, set with a gemdos call, is
correct, supposedly set by the Supra program. The BIOS clock reads 1
Jan. 2048, which is what Word Perfect comes up with. The supposed
keyboard clock reads 1 Jan. 1900! When I run a program to set all of
the clocks which reads the TOS clock with a gemdos call and sets the
BIOS clock with xbios(22/23) (I forget which it is at the moment), all
three clocks report the same time. So what is Kgettime() reporting? Or
is this related to the bug that John reports?
--
Bill Silvert, Habitat Ecology Division.
Bedford Institute of Oceanography, Dartmouth, NS, Canada B2Y 4A2
UUCP: ...!{uunet,utai,watmath}!dalcs!biomel!bill
CDN: biomel@cs.dal.CDN BITNET: bs%dalcs@dalac.BITNETclose@cacilj.UUCP (Diane Barlow Close) (04/23/89)
In article <3237@cs.dal.ca> bill@biomel.UUCP, biomel@cs.dal.CDN writes: >I appreciate John's information about the clocks, but I remain a bit >confused about what is happening. The Paul Close program that his wife >posted gives me separate readings for three clocks when I boot with the There are only two clocks. The MWC routines have two ways of reporting and interpreting the keyboard clock. One way returns a value of 1900, and the other returns a value of somewhere in the year 2000. One routine (gettime) ``reads and returns the intelligent keyboard's setting of the current time. It returns a 32 bit mask whose bits indicate'' various things. The other routine (Kgettime) ``reads the time from the intelligent keyboard's clock ... and returns a pointer to the structure tm_t, which it initializes.'' *That's* the two are different values. Kgettime converts between time as encoded in tm_t and the IKBD clock, while gettime directly manipulates system time. It's a slight difference that had me confused at first, and convinced that the ST had more than two clocks. Now I'm set straight, and I hope you are too. My husband's program won't, by the way, freeze the keyboard clock 'cause it only *reads* one clock and writes the other--the freezing problem happens when you write both clocks. -- Diane Barlow Close {uunet, crash, ucsd}!cacilj!close close@cacilj.uucp Free Canada -- Trade Mulroney
john@stag.UUCP (John Stanley) (05/02/89)
[close@cacilj.UUCP (Diane Barlow Close) writes...] > There are actually 3 clocks in the ST. They are the keyboard clock, the > TOS clock, and the BIOS clock. Almost (but not quite) right. There's a Gemdos clock but no "TOS clock" and no seperate "Bios clock"... There are really only 2(!) clocks on the ST. The Gemdos clock and the keyboard clock. The "bios clock" is really just two routines in the bios for reading/setting the keyboard clock. (The Gemdos clock determines what time and date get stamped on files.) > Some hard drives set only one clock. My BMS card sets only the TOS clock. (The following applies to cartridge and under-the-rom style clocks too.) It's not normaly the hard drives themselves that "set" the ST clocks, it's usualy the hard disk boot code (rare) or a read-the-time program in the auto folder. What this means is that the hard drive companys can (and I hope "will") fix this problem with their systems by releasing a new readtime program or boot-code module. > 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). Correct... That's the year (I think it's 2054) that the keyboard clock shows if it has never been set correctly since power on. (Note, power on, not reboot. If you set the keyboard clock once, it survives reboot very nicely. Some auto folder programs use this to only prompt you for the time and date once after power on and you don't have to enter it after a reset.) ** Programmer information warning ... :^) The keyboard clock will freeze under some situations when setting it. I haven't been able to figure out exactly what causes it, but I do know that the order of reading and then setting the two clocks does effect it. Not enough time between reading and then setting the keyboard clock is the most likely cause. As far as I can tell, this only occurs when you read the keyboard clock and then set it. If you only do one or the other, don't worry about it... I'm only mentioning this to let those who write programs that set the keyboard clock know that they should, when writing their programs, test the results very carefully and rearrange the function calls (to seperate the read keyboard clock and set keyboard clock system calls as far as possible), if necessary, to remove the problem. ** End of programmer information ... John STanley --- John Stanley <dynasoft!john@stag.UUCP> Software Consultant / Dynasoft Systems