[Coco] DS1216

[George Ramsower]

  When I'm doing what requires the system clock to be ON TIME, it is 
important that it be on time. Normally, the accuracy of the system clock 
in not very important, as long as it's pretty much on the same date.
  But... when the clock is required to be ON TIME, then being able to 
keep that smart watch on time is important.
  It would be very simple to set that clock on a scheduled basis and I'm 
looking forward to this improvement to the "setclk". As most of us 
already know, a clock that loses (for example) one second every day, 
then it will lose about 30 seconds every month. When I need more 
accurate time keeping, being able to reset that smart watch once a day 
to advance it by one second, once a day with software, is important 
unless I want to do this manually, on a strict schedule. This can easily 
be done several time a day, if necessary, with some match to calculate 
the timing for resetting the smart watch.
  That DS1216 can also break down the time to milliseconds, providing 
the software is written to do this.
  There's something to ponder!

  I like "easy"!! After all, aren't computers  supposed to make life 
easier? Let them do the work!
  I'm looking forward to an improved "setclk" which will be easy to 
adjust and keep on time.

  Of course, this will only be effective while the computer is on. 
Naturally, if it is off then the smartwatch will do it's thing until 
acted upon.

George R.

On 9/23/2015 12:30 PM, K. Pruitt wrote:
> P.S. The link you provided is the source code for setclk. Shouldn't be 
> a problem modifying setclk to do what George wants it to do now.
> This is awesome. Thanks.
>
>
> ----- Original Message ----- From: "K. Pruitt" <pruittk at roadrunner.com>
> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
> Sent: Wednesday, September 23, 2015 9:54 AM
> Subject: Re: [Coco] DS1216
>
>
>> Thanks Bill.  I'll give that a shot.
>>
>> I'd really like to get this modified for George to solve his issue 
>> with setclk.
>>
>> "But what you described sounded like 6809 being disassembled by 6309 
>> disasm from the wrong entry point."
>>
>> Yep. that pretty much describes what I am seeing. Because not only am 
>> I seeing what I now understand to be 6309 code, but the internal 
>> addressing is off as well.
>>
>> Thanks again.
>>
>>
>> ----- Original Message ----- From: "Bill Pierce via Coco" 
>> <coco at maltedmedia.com>
>> To: <coco at maltedmedia.com>
>> Cc: "Bill Pierce" <ooogalapasooo at aol.com>
>> Sent: Wednesday, September 23, 2015 6:24 AM
>> Subject: Re: [Coco] DS1216
>>
>>
>>> Kelly, if you're using the disassembler from the repo disks, it's a 
>>> 6309 compatible disasm... hence the odd instructions.
>>> Now why is it throwing 6309 code up when it's a 6809 program? It's 
>>> hitting the FCBs & FDBs at the beginning and seeing them as code... 
>>> some are reading as 6309 stuff. That's why you have no data at the 
>>> beginning.
>>>
>>> Try using Sleuth... it will give you the "Entry" address when it 
>>> reads the file in, you can then set the FCB/FDB/FCC/FCS areas, and 
>>> do fake disasms until you get all set... then save it to disk. I 
>>> think you'll get a better disassembly with Sleuth... unless it IS 
>>> actually 6309 code..... But what you described sounded like 6809 
>>> being disassembled by 6309 disasm from the wrong entry point.
>>>
>>> Also, I think the sources are on RTSI...
>>> Try this and see if it's the same program:
>>> http://ftp://os9archive.rtsi.com/OS9/OS9_6X09/SYSMODS/RTC_Disto_RGB_Utils.lzh 
>>>
>>>
>>>
>