rouaix@inria.UUCP (Francois Rouaix) (10/08/87)
I have somebody here on my BBS who asks this question: he has a Franch Amiga (french voltage 220v, 50 Hz) He bought an Insider 1Mo expansion RAM with a permanent clock in the States. The problem is that the clock is always late. Is this related to the fact that the american voltage does not have the same frequency ? Can anything be done to it ? Thanx for your help. -- *- Francois Rouaix / When the going gets tough, * *- USENET:rouaix@inria.inria.fr \/ the guru goes meditating...* * SYSOP of Sgt. Flam's Lonely Amigas Club. (33) (1) 39-55-84-59 (Videotext) *
wtm@neoucom.UUCP (Bill Mayhew) (10/12/87)
In article <540@inria.UUCP>, rouaix@inria.UUCP (Francois Rouaix) writes: > > I have somebody here on my BBS who asks this question: > he has a Franch Amiga (french voltage 220v, 50 Hz) > He bought an Insider 1Mo expansion RAM with a permanent clock in the States. > The problem is that the clock is always late. You are correct in your assertion that your friend's Amiga gradually looses time becuase european power is 50 Hz, rather than 60 Hz. The time-of-day on the Amiga appears to be incremented by an interrupt service routine that is triggered by a 60 Hz sqare wave from the power supply. When the power supply is excited by 50 Hz, fewer interrupts per second are generated, thus causing the clock to lag behind the proper time. The battery backed-up Insider clock derives its time base from a crystal oscillator. When the Amiga boots, a program called by s:startup-sequence reads the Insider's clock chip and sets the proper time. --so,... the time should be pretty much correct when the computer is turned on, and then gradually get behind the correct value. There are a number of corrective steps that you can take: The most severe step would be to europeanize the Amiga and outfit it with 50 Hz video chips and firmware. Obviously, this would also entail getting a PAL monitor. Likely, this is not a cost-efficient alternative. A second approach would be to modify the interrupt service routine. You could normalize the amount the time-of-day register gets incremented so that 50 interrupts per second would suffice. You'll have to consult with the ROM Kernel Manual to figure this one out, as this is a bit much for my level of expertise. An alternative might be to read the Insider for each interrupt, but this would prbobly use up a little more CPU time. A third approach would be to generate your own 60 Hz reference and substitute it for the signal provided by the power supply. You can use a National Semicondutor MM5369 17-stage oscillator/divider and American TV 3.579545 MHz color reference crystal to make a 60 Hz square wave source. See page 4-3 in the 1978 Edition of the National Semiconductor CMOS Databook. The 60 Hz signal is supplied to the motherboard on the pin of J-14 that is closest to the rear of the machine (probably a gray wire). At least this is true in fairly old versions of the A-1000. Since I'm an EE, the third way would be easiest for me. For software Gurus, the second choice would probably be best. I'm sure there are probably better methods of solving the clock problem, but these are the ones I thought of. Bill (wtm@neoucom.UUCP)
leekil@athena.mit.edu (Lee S Kilpatrick) (10/14/87)
My Amiga 2000 clock seems to be somewhat fast. Could this be a result of my local power, an incorrect clock chip, or just a poor clock?
grr@cbmvax.UUCP (George Robbins) (11/15/87)
In article <729@neoucom.UUCP> wtm@neoucom.UUCP (Bill Mayhew) writes: > In article <540@inria.UUCP>, rouaix@inria.UUCP (Francois Rouaix) writes: > > > > I have somebody here on my BBS who asks this question: > > he has a Franch Amiga (french voltage 220v, 50 Hz) > > He bought an Insider 1Mo expansion RAM with a permanent clock in the States. > > The problem is that the clock is always late. > > > You are correct in your assertion that your friend's Amiga > gradually looses time becuase european power is 50 Hz, rather > than 60 Hz. The time-of-day on the Amiga appears to be incremented > by an interrupt service routine that is triggered by a 60 Hz sqare > wave from the power supply. When the power supply is excited by 50 > Hz, fewer interrupts per second are generated, thus causing the > clock to lag behind the proper time. Sorry, this explanation doesn't cut it. The Amiga software is supposed to automatically sense whether the line frequency is 50 Hz or 60 Hz and adapt accordingly. It also senses separatly whether the system contains a PAL or NTSC Agnus chip and sets up the appropriate window/screen size parameters. From the description, it sounds like the clock oscillator in the "Insider" simply needs to be adjusted a little bit so it keeps correct time. Look for some sort of trimmer capacitor near the crystal that controls the clock frequency. I hope this answers the question, there are a fair number of ambiguities here... -- George Robbins - now working for, uucp: {ihnp4|rutgers|allegra}!cbmvax!grr but no way officially representing arpa: out to lunch... Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
duc@csd4.milw.wisc.edu (Duc Minh Tran) (01/24/89)
-In article <463@csd4.milw.wisc.edu> duc@csd4.milw.wisc.edu (that's me) writes: ->Anyone out there with a Michigan Software Insider? The clock on mine ->cannot seem to store the correct date; it always runs one day or 24hrs ->late. Here is how I set the Insiders clock: - -I now have the new version of RTClock. Now if I type the 'date' command -after RTClock the date and time displayed would be correct. But the DAY -displayed is two days fast. Can anyone confirm this new bug? Are the -people at Michigan Software using a Chinese calendar again? ;-) - The bug I reported above seemed to have disappeared (yea, that's the ticket!). I appologize to Michigan Software for reporting this bug and in actuality my Chinese calendar is is the thing that's buggy. The new version of RTClock works with no problems so far. ---------------------------------------- | I'm a schizophrenic! | "Internet" duc@csd4.milw.wisc.edu | The opinions expressed are not mine. | "UUCP" ihnp4!uwmcsd1!uwmcsd4!duc ----------------------------------------