jtb@dhw68k.cts.com (John Gibbons) (07/21/90)
For quite some time now I have had a lot of trouble with my Amiga 2000's
built in clock. Well actually to be more exact, the built in clock is fine,
but once the software gets ahold of it I am in trouble.
In order to relieve you of the hassle sending back the obvious responses
I will let you know now that it is NOT any of the software I am using on my
machine. I have made sure of this by booting off a floppy which does
nothing more than open a shell, I just Installed it with the cli install
command. Therefore it is another problem. I will attempt now to explain the
problem as best I can. (also I have used 1.3,1.2,1.3arp setclocks with the
same result)
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. The following is a buffered command line test I
performed while typing this post. All text in [Brackets] are my comments.
$ setclock opt load
Saturday 21-Jul-90 06:08:41 [this is the correct time]
$ date
Saturday 21-Jul-90 06:08:50
$ date
Saturday 21-Jul-90 06:08:53
$ date
Saturday 21-Jul-90 06:09:00
$ date
Saturday 21-Jul-90 06:09:30
$ date
Saturday 21-Jul-90 06:09:43
$ date
Saturday 21-Jul-90 06:09:46 [Still the correct time]
$ date
Saturday 21-Jul-90 06:08:43 [Aha! The clock has gone crazy!]
So as you can see after about 1 minute the clock decides to go back 1
minute and will keep screwing around like that forever no matter how many
times I reload the battery backed clock. I have no intentions of dcron
setting the clock every minute or doing it manually. I just do not know why
it is happening or what it could be.
I do, however feel it would be a good idea if I were to list all my
hardware that could perhaps be the cause of the problem.
Amiga 2000 (B2000) V4.3 motherboard
Commodore 2090A Hard Disk controller (Conner 40mb SCSI hd)
2 floppy drives, (monitor, modem, printer etc..)
If this is of any importance I do not know, I run my machine 24 hours a
day and rarely if ever shut it off. But seeing as how the problem with the
clock will begin as soon as I do a setclock I doubt if that matters.
If anyone can give me any advice or solutions I would be forever
greatful, please either send email to one of the addresses below or simply
post it here as I am sure I am not the only person to have this problem.
Also if this has already been discussed here, sorry I must have missed
it and you CAN'T get mad at me for seeking help. (Well I suppose you could
get mad, so if you do, /dev/null would be a nice place for any flames.)
Thanks a million
--
John Gibbons
Internet: jtb@dhw68k.cts.com UUCP: ...{spsd,zardoz,felix}!dhw68k!jtbcollins@Alliant.COM (Phil Collins) (07/22/90)
I didn't see your complete post. Did you say that the clock works ok w with workbench and the the clock problem starts when running a program that requires a clock? If you clock is messing up when running a external program then the power supply could be at fault. The power supply generates the tic signal and is a 60 hz.
hull@hao.hao.ucar.edu (Howard Hull) (07/23/90)
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
daveh@cbmvax.commodore.com (Dave Haynie) (07/24/90)
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. The problem is that the "software clock", part of one of the 8520 chips that uses a 60Hz/50Hz line frequency to give you time while the machine is running, is bad. I had very much the same problem about two years ago; my clock would count for about 70 minutes, then jump back. Amusing to watch, but it certainly sends "make" and other date dependent tools to the funny farm. The proper solution is to have the offending 8520 CIA chip replaced. There is a chance simply swapping the two 8520s would solve your problem without creating another problem, since there's not much chance of the TOD counter being used in the other part, assuming it's only the TOD counter that's at fault. When mine died, I replaced the 8520 (I will admit a much easier job if you keep a few in your parts bin at home like I do). >John Gibbons >Internet: jtb@dhw68k.cts.com UUCP: ...{spsd,zardoz,felix}!dhw68k!jtb -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy The Dave Haynie branch of the New Zealand Fan Club
rsbx@cbmvax.commodore.com (Raymond S. Brand) (07/24/90)
In article <13387@cbmvax.commodore.com>, daveh@cbmvax.commodore.com (Dave Haynie) writes: > 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. ... > The proper solution is to have the offending 8520 CIA chip replaced. There is > a chance simply swapping the two 8520s would solve your problem without > creating another problem, since there's not much chance of the TOD counter > being used in the other part, assuming it's only the TOD counter that's at > fault. When mine died, I replaced the 8520 (I will admit a much easier job > if you keep a few in your parts bin at home like I do). Actually, both TOD counters are used, the one on ciaA for the timer.device's time keeping and the one on ciaB is used by graphics.library for tracking the horizontal pixel position (or something like that). > > >John Gibbons > >Internet: jtb@dhw68k.cts.com UUCP: ...{spsd,zardoz,felix}!dhw68k!jtb > -- > Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy > The Dave Haynie branch of the New Zealand Fan Club rsbx ------------------------------------------------------------------------ Raymond S. Brand rsbx@cbmvax.commodore.com Commodore-Amiga Engineering ...!uunet!cbmvax!rsbx 1200 Wilson Drive (215)-431-9100 West Chester PA 19380 "Looking" ------------------------------------------------------------------------
consp13@bingsuns.cc.binghamton.edu (Marcus Cannava) (07/25/90)
In article <13387@cbmvax.commodore.com>, daveh@cbmvax.commodore.com (Dave Haynie) writes: |>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. |> |>The problem is that the "software clock", part of one of the 8520 chips that |>uses a 60Hz/50Hz line frequency to give you time while the machine is running, |>is bad. I had very much the same problem about two years ago; my clock would |>count for about 70 minutes, then jump back. Amusing to watch, but it certainly |>sends "make" and other date dependent tools to the funny farm. |> Dave, Any chance that this is also a problem in my BRAND NEW A3000? It refuses to keep time after a reboot (also loses time during a long run, preferences seems to set fine, but the clock doesn't hold the time!) Help, please! \marc === 'I do not fear computers.. I fear the lack of them' -- I. Asimov RNM