[Coco] Unknown error

[Gene Heskett]

On Friday 20 December 2013 11:17:16 Robert Gault did opine:

> Bill Gordon wrote:
> > Sometimes when I'm using a DW distro of NitrOS-9 and I try to use the
> > setime
> > 
> > command, I get an error that says:
> >>> Clock Initialization Errors <<
> > 
> > The clock seems to be correct, but what is that error?
> > 
> > 
> > 
> > Thanks
> 
> Bill,
> 
> That error message comes from the setime command. It would be called if
> there is an error with the os9 F$STime syscall. If the returned error
> is not $EA, non-existent module, then what you see is sent as a generic
> error. You can look at F$STime in level2/modules/kernel and see that
> the only reported error is generated by the os9 F$Link call.
> 
> Since we have excluded a missing module, the remaining errors would be
> module busy and defective module header. Module busy is the only
> reasonable choice.
> 
> Probably Setime should be changed so that F$Time is tried twice to
> compensate for a Busy error. You could also change Setime so that if
> the error is $D1, module busy, it gets reported. At least that would
> test my reasoning.
> 
> Robert
> 
I suspect thats tied to the actual clock2 module in use, as its an error I 
have not see in a decade of using the clock in a TC^3.  Haven't used it all 
that many times though, usually at the spring/fall time switch.  Had to use 
it twice this fall though, I'd forgotten the date so I came back to this 
machine which is updated by ntp & stays within 10 milliseconds of Boulder 
and reset it correctly.  The TC^3 keeps good time.  The original disto  
clock did not until I re-wrote the gettime call, Tony used a call that 
froze the clock while it was being read, so it lost time when running but 
not when shut down.  Probably close to 20 years ago that I fixed that, and 
no clue if that fix ever made it into the nitros9 repo.

Hard to tell now.  I called it clock ed 11 at the time.  Eddies blob 
stopping clocks were clock edition 9, but those are all about 20 years back 
up the log.  Now its all broken out into a main module and a submodule to 
handle the hardware.  The disto clock, while it could keep good time, all 
to often got knocked plumb out of kilter by bus noises on powerdowns and 
powerups.  Good quick access, but no protection from bus noises at all.  

The B&B-XT-RTC OTOH needed a serially written 32 bit password to gain 
access to it, which had to be written non-stop, with the IRQ's locked out 
of course, so it was absolutely and totally worthless the instant you 
dialed up and went online because that lockout time meant you missed at 
least 2 characters even at 300 baud.  It originally updated the coco's time 
packet at 1 minute intervals which was a major PIMA at the time, so I kept 
re-writing it, got it to do it only at noon and midnight, and eventually 
said screw it and only updated the coco's time from it at boot time or 
anytime you did a "date t".  That way I could choose to do it when I was 
offline.

Fixing poorly written (IMNSHO of course) clocks has had a "colorful" 
history, with liberal sprinklings of profanity laced genealogy mutterings 
that are best forgotten, here at the WV places my hat has hung since 1984.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

Go 'way!  You're bothering me!
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
         law-abiding citizens.