[Coco] DS1216

[Gene Heskett]

On Tuesday 22 September 2015 01:00:09 George Ramsower wrote:

> On 9/21/2015 11:33 PM, K. Pruitt wrote:
> >>  The system clock keeps HORRIBLE time. Drivewire would have to
> >> update the system clock at LEAST every five or ten seconds. So,
> >> this may not be an option.
> >> George R.
> >>
> >>
> >> --
> >
> > Does your PC keep horrible time? Your drivewire time will be the
> > system time from your PC. I'm not sure how often drivewire updates
> > the time, but it seems to stay pretty accurate for me. But my
> > hardware clock doesn't lose time either, so your experience may be
> > different.
> >
> > When I boot in to drivewire I utilize the software clock When I just
> > boot in to the CoCo without drivewire I use Robert Gault's SWRead
> > program to pull in the time from the clock chip and keep the system
> > time updated.
> >
> > As I recall, booting in to drivewire with the NitrOS-9 boot file set
> > to utilize the clock chip will result in a system hang-up. This may
> > have been fixed though, I don't know.
> >
> > I'd can try and alter the disassembled source code for getclk and
> > see if I can change it to accept a parameter. No guarantees as it
> > may exceed my skill level, but I can give it a shot.
>
>   Oh! I should specify on these matters. This PC keeps excellent time
> and once a week, it updates from WWV.
>
>   The coco keeps terrible time without the smart watch but for what
> I'm doing, I have to use getclk about every  five or ten seconds or
> the software clock in OS9 will lose about one to two seconds over a
> period of about thirty seconds. This is okay for normal use as a few
> seconds won't matter.
>   I have a B09 procedure running in the background with a priority of
> 10. So normally, it will update the system clock about every20
> seconds. Not an issue unless accurate time is necessary. The I change
> the priority to 128. At that priority, it will update about every five
> seconds which is acceptable. That's while running the application for
> the mechanical clocks. Without that overhead, the routine to run
> "getclk" is a lot faster and again, the priority of 10 is plenty fast.
> If it gets off by a couple seconds or more, then monitoring a pendulum
> becomes impossible to determine if it's swinging as it should. So time
> is critical when doing this. If I could do it on this PC, I would but
> I have no idea how, nor do I know how to even monitor the pendulum
> with a PC. Coco is KING for me and my learning abilities are very
> limited since I had my accident a bit more than two years ago. I'm
> still slow on the Coco. Some things used to be a snap and now, I have
> been dog-earing the pages in my  OS9 books. When I find what I'm
> looking for, it's always..."Darn!! I knew that!!". I guess the
> interface to the hard drive in my head now has a bug in it.
>   It could be a problem with the "refresh" cycles.... see the previous
> paragraph.
>
>   I'll keep my fingers crossed for you, Kevin. Good luck modifying
> "setclk".
>
> George R.

The coco/os9 arena has been plagued by poorly written clocks since 
forever.  The hardware clocks available, supported by clock drivers from 
the hardware folks, do NOT have a good history at my place.  My first HD 
was a 30 megger, RLL style running on a B&B XT-RTC interface.  The clock 
chip whose name & number I have happily forgotten, that was the RTC in 
the B&B kit, needed to have a 16 bit password serially shifted into it 
before access to read the time from it was granted.  I could not 
download anything with rzsz without megatons of errors even at 300 baud 
because it did this every minute on the minute, taking so much time that 
the download suffered framing errors because the IRQ's are locked out 
during this access time.

I finally rewrote that clock to only get the chips time at bootup and 
noon/midnight.  But in those days, any sizeable download needed to be 
scheduled so it could be completed before one of these reads.

Then, because my B&B kit was seriel #1 (maybe 2), and made filesystem 
mistakes that cost me dearly to recover from, I finally bought a disto 
4n1 and a 120 meg maxtor drive.  And that clock driver had a coding 
error in the access that caused it to lose time only when the coco was 
running. About 10 seconds an hour. I eventually fixed that of course, 
but neither fix was ever uploaded and shared as in those days we didn't 
have anyplace but RTSI to publish that sort of thing to and I don't 
recall if I ever put it out to the public even there.  If I did, it 
would have been before RTSI was hacked and a good share of our software 
was deleted to make room for the hackers stuff.  The recovery from that 
was incomplete, so my early stuff may be gone forever.  Way too much 
water under the bridge since those days 20+ years ago.

The disto clock also had no noise protection during the power up/down 
transitions and could become totally bogus at random bootups. The only 
fix for that might have been a better switching circuit, but it was 
random enough to tolerate in comparison to the effort needed to find 
that.

That has totally not been a problem since I retired the 4n1 in favor of 
one of cloud9's TC^3 scsi controllers with the rtc option, it has Just 
Worked(TM) once I figured out how to make it boot from an HD.  Its 
currently managing a pair of 1Gb Seagates pushing 20 years old when its 
powered up.

I don't recall now, but I know George has told me, what he has for a 
clock and drive controller, but its possible that its old enough to be 
in the above category, but it sounds as if its a 50 hertz clock maybe, 
IOW wrong clock module in the first place.  But would that not make it 
run fast?  Puzzling...

Cheers, Gene Heskett
-- 
"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>