🚀 go-pugleaf

The SETTIME program posted some time ago by Allan Pratt has a subtle
bug:  When the time is 4:00PM or later, the GEMDOS clock is set correctly
but the IKBD clock is set one day too early.  Then on each subsequent
reboot, the GEMDOS clock ends up one day off.

Since Allan was kind enough to post the sources, I was able to track down
the problem.  Setting the IKBD clock requires packing two int's into a
longword.  SETTIME did it as follows:
            ((long)date << 16) + time
(where in the actual code, "date" and "time" are really calls on the
GEMDOS functions Tgetdate and Tgettime, respectively).  Unfortunately,
if the high-order bit of time is 1, C will sign-extend time when it
converts it to a long integer prior to performing the addition, with
the result that -1 is added to the date.  A fix is to change this code
as follows:
            ((long)date << 16) + ((long)time & 0xffff)

One other thing I noticed that may or may not be a bug:  SETTIME
assumes that the basepage contains a valid argument string with a
count in the range 0..127.  If the number it picks up is not in this
range, it will randomly clobber memory.  I don't know whether that
is a safe assumption or not.

I would be happy to repost the corrected source and .PRG files, but
they are copyrighted by Atari, so I do not think I should do so without
explicit permission of Atari.  Perhaps Allan would prefer to make these
changes himself and repost the results.

--Mike Ficher <fischer@yale.arpa>
-------