Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!uwvax!daffy!cat17.cs.wisc.edu!pochron
From: pochron@cat17.cs.wisc.edu (David Pochron)
Newsgroups: comp.sys.amiga.programmer
Subject: Is OS supposed to zero the TOD clock registers intermittently?
Summary: Subject says (mostly) it all...
Keywords: Intuition TOD clock bugs race condition
Message-ID: <1991Mar21.175806.23729@daffy.cs.wisc.edu>
Date: 21 Mar 91 17:58:06 GMT
Sender: news@daffy.cs.wisc.edu (The News)
Organization: U of Wisconsin CS Dept
Lines: 72


In my (apparent) never-ending quest to figure out why my clock keeps going
haywire when I drag windows around, I decided to look at the 8520 registers
$BFD800, $BFD900, and $BFDA00 (CIAA-eventLSB, eventMid, and eventMSB for
those who remember mnemonics)  and see what happens to them when this "blessed"
event occurs.

What I found is when start banging madly on the drag bar, depth gadgets, and
resizer gadget before the window finishes refreshing, something (Intuition?
GfxLib? Layers? Timer.device?)  resets these registers to zero.  Why?


Now I did notice that the OS (Kickstart 1.2), resets these registers every
time whenever they reach a count of 65536.  Funny thing is, the OS designers
used a VBI to check when the registers reach that count and didn't use the
built-in 8520 TOD alarm interrupt.  Any reason for this?

This still doesn't explain why banging on the windows should reset this
count before it reaches the 65536 mark.


It looks as if the OS commands to read the time and date get it directly
from these registers, since you can POKE them and see the clock (CBM v2.22)
respond immediately.  They must also have a software structure also, though,
as I assume that when the VBI occurs and finds the count to have expired, it
updates the software structure and resets these hardware registers to zero.


The "haywire" effect doesn't happen too often with just Workbench icon windows,
but the Clock program (v.2.22) that comes on the Workbench disk seems to cause
it to happen much more often. (Esp. in analog mode.)  SID 1.06 causes it all
the time, but I tend to discount SID since Enforcer tells me it bangs on just
about every illegal memory location in the system! (Talk about bugs!)
It happens often while dragging the VLT review and CONMan console windows also.


So what does everyone think to problem is?

1) Programs that are stomping on the registers by accident?
   (Except that it has happened to me while using a right-out-of-the box
   KS 1.3 update disk, with no other programs running except Workbench.)

2) A real OS bug - probably a race condition when reading and updating the
   hardware/software structure clock values?

   Or perhaps gfx or layers is accidentally banging on the eventMSB register,
   causing the VBI to update the software clock structure at the wrong time.
   (POKEing eventMSB manually creates a VERY similar "haywire" effect!)

3) A hardware problem - A2630 timing problem, faulty 8520?
   I don't think it is a hardware problem though, since the 8520 seems to work
   fine, and the error is easily reproducible on my system.  Don't want to
   think about a problem with the A2630...


I am thinking of writing a "protector" for those locations, as it is very
easy for any program to accidentally write to them, and mess up the TOD clock.
If someone from Commodore responds to this message and says that window drags,
etc, etc. should NEVER reset these registers, then I can go ahead and write
a VBI to keep spare values for these registers and fix them if necessary.
If not, then patching the problem becomes much more complex...

This TOD clock thing is really messing up "make" and other time-dependent
utilities!

Thanks in advance...

-- 

       -- David M. Pochron   |
                             | Canada: One of the world's greatest mysteries..
pochron@garfield.cs.wisc.edu |