[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: No Slot Clock - Damaged?



Supertimer <supertimer@aol.com> wrote:

> My guess is that the data in the chip has somehow
> become corrupted.  As to how to reset the chip, the manual
> says this:
> 
> "The SmartWatch information is contained in 8 registers
> of 8 bits each which are sequentially accessed one bit
> at a time after the 64 bit pattern recognition sequence
> has been completed...bits 4 and 5 of the day register
> are used to control the RESET and oscillator functions.
> Bit 4 controls the Reset (A14 - pin 1).  When the reset
> bit is set to logical 1, the RESET input pin is ignored.
> When the RESET bit is set to logical 0, a low on the
> RESET pin will cause the SmartWatch to abort data
> transfer without changing data in the watch registers.
> Bit 5 controls the oscillator.  This bit is shipped set to
> logical 1, which turns the oscillator off.  When set to
> logical 0, the oscillator turns on and the watch becomes
> operational."
> 
> Ok, maybe someone who understands the above can
> provide a clue on what to do to reset the SmartWatch.

Since I've programmed the things directly (not in the Apple II), I'm
sure I can provide a clearer explanation of these.

As described, the DAY register contains two bits which control the
operation of the SmartWatch.

The "oscillator" bit must be set to zero in order for the device to
count the time.  With this bit set to one, the time will be frozen (but
power consumption is negligible).

The "reset" bit is badly named.  A better name would be "reset pin
enable".   Its purpose is to determine whether or not a specific pin on
the package is used to reset communication with the SmartWatch.

You do _not_ want to enable this feature.

If the reset pin is enabled, then this address pin must remain in the
"not reset" state (high) during the entire 64-cycle identification
sequence and the subsequent 64-cycle data transfer sequence.  If the
reset pin goes to the "reset" state (low) during this sequence, then the
SmartWatch forgets you were accessing it, and you have to start again.

For the DS1216E, pin 1 is reset.  This is mapped to Vpp on most EPROMs,
which should be held high.  For a masked ROM or PROM, as in the Apple II
series, this pin is tied to +5V, so the reset signal should never be
activated, even if the feature is enabled.  (This is the case for the
Apple IIe motherboard ROMs, in any case.  I haven't checked the
situation for the IIc.)

(It is a more serious problem for the RAM-based SmartWatch, since pin 1
is A14: the code accessing the SmartWatch must keep A14 high for the
entire access cycle.)

Assuming the reset signal doesn't interfere, neither of these bits would
prevent software from accessing the SmartWatch registers.  The worst
effect should be a frozen or garbage time if the OSC bit was set to 1.

It is possible that the "Time is Faulty" test is looking for known
illegal values, and the SmartWatch time has been corrupted.  If so, it
should be a simple case of writing the correct time into it, and the
driver should kick into life again.

(While doing some Y2K tests on a SmartWatch, I discovered it was
possible to write nominally illegal dates, e.g. digits greater than 9.
This might be rejected by the No Slot Clock driver.)

-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P O Box 27-103, Wellington, New Zealand