Path: utzoo!attcan!uunet!mailrus!ncar!hao.hao.ucar.edu!hull
From: hull@hao.hao.ucar.edu (Howard Hull)
Newsgroups: comp.sys.amiga
Subject: Re: Serious amiga 2000 clock problems!
Summary: Damaged 8520A IC
Keywords: bad timer register parnet parnet.handler parnet-dnet parnet.device
Message-ID: <8058@ncar.ucar.edu>
Date: 22 Jul 90 20:10:05 GMT
References: <1990Jul21.142922.959@dhw68k.cts.com>
Sender: news@ncar.ucar.edu
Distribution: na
Organization: High Alititude Observatory/NCAR, Boulder CO
Lines: 77

In article <1990Jul21.142922.959@dhw68k.cts.com> jtb@dhw68k.cts.com (John Gibbons) writes:
>...
>    If I at ANY time do a "setclock opt load" the correct time and date is
>loaded in perfectly without problem. However within 1 minute the current
>time will be incorrect.
>-- 
>John Gibbons
>Internet: jtb@dhw68k.cts.com       UUCP: ...{spsd,zardoz,felix}!dhw68k!jtb

Ah, you have the infamous Amiga clock hickup syndrome!  Rather than missing
60Hz ticks, the problem is more likely that you have blown one of the Commodore
general purpose programmable I/O/timer/fuse devices, otherwise listed as
Commodore/MOS Technology part number 8520A-1, two each of which are found in
every Amiga computer.  Since there are two of the 40-pin critters, you can
check them by merely swapping them.  If the caps key goes into flash mode,
dats the problem youse got.  The symptoms are caused by a bad timer register.
I don't know exactly how the timer gets damaged (a good bet is that your
neighborhood took a hit from a lightning bolt in a passing thunderstorm),
but more on that later.

As an aside, there was someone about 1E3 csa articles ago who complained of
caps lock flashing; I think in his case I would suspect that he was using
TrackSalve1.0 on a ver 4.2 motherboard, and needed to upgrade to the newer
version released to the net a couple of weeks ago; that is, his problem is
the same as the one I had with the first version of TrackSalve.  I could
run for anywhere from one to four hours before the keyboard would go nuts
generating a stream of random input all on its own.  It could be cured for
a time by unplugging it and plugging it back in.  The problem went away when
I upreved the TrackSalve program.

The way I blew away my A2000's 8520 was through over-enthusiasic provisioning
of the signal grounds in the DNet/ParNet cable.  A net article said to put
grounds on pins 18 through 22.  That's five pins.  I had these other three
left over, so after checking the A2000 manual, I decided it would be ok to
put them on 23 through 25.  Well, that was ok for the A2000, but (as I wasn't
looking at the A1000 docs at the time, and CBM didn't want to confuse anyone
by hinting in the A2000 docs that they ever did anything differently in the
past) the A1000 I plugged the cable into had +5 Volts on pin 23.  As it was
a 50 foot cable with 24 ga. wire, the boiler-plate power supply in the 1000
hardly even flinched.  Things appeared normal (the Dillon parnet even worked
ok, though it came up with write errors on the A1000 side).  However, the
next time I booted the 2000, it hung in a Wait.  No matter what I did (except
control D) the startup sequence couldn't get past the wait.  I reckon what
happened was that the 1000 supplied the current taken by the long loop short
out to the 2000 and back, _but_ it gave the 2000's 8520 a -2.5v logical low
on several of the lines and cooked the substrate protect diodes over there.

When I discovered the problem, I removed the three grounds in the cable and
replaced the 8520A with a part I had ordered the last time I blew away the
A1000's 8520A chip (when I the grabbed mouse after shuffling across the rug
one cool dry winter morning).   After that, things seemed normal with the
possible exception that the max I could get out of the parnet-dnet.handler
was only 2860 bytes per second.

As there were reports of noticeable performance degradation for cables longer
than 35ft (especially shielded cables such as one really should use to keep
from bombing the neighborhood with EMI) I though nothing much of it.  Under
these circumstances, the primitive ParNet was much faster than the parnet-dnet
handler; even so, the parnet-dnet handler was never a lot faster than the DNet
serial baud rate, a matter which was, to say the least, rather suspicious.

I had been using the 5-wires-grounded cable until parnet.device (2.0), after
which I rewired the cable to provide for pins BUSY (11), POUT(12) and SEL(13)
as per the new instructions in the Cable.doc file included in the distribution.
After I upreved, for my long cable the performance went up to 17800 bytes per
second.  Some others on the net who had reported up to 29000 bytes per second
found that things slowed down when they went to 2.0 but I think they were using
very much shorter cables.  I'm glad I never had time to cut my cable (it was on
the list of things to do).

In any case, the extent of my experience with the 8520A points out that the
8520A is quite a lot more fragile than a real RS232 spec'd line chip would
be under these "typically" abusive circumstances, anyway.  :-)  So watch out
for them critters a little more than usual, folks...

						Howard Hull
						hull@ncar.ucar.edu