Amiga 4000 real time clock oddity

[arttu80]

Hello!


Would be super nice if someone here have any idea what is happening with my RTC..

Here is this case; when I turn on computer with internal HDD connected (no matter if it's real IDE or CF card), system does not see the clock (just checking by running SysInfo program). But when I run "SetClock Save" command or run SysInfo second time, this apparently turns on RTC. Is it possibble to narrow down as to what may cause this?

Ofcourse battery has eaten some of motherboard traces, which I repaired. Using multimeter continuity check and resistance checks, following this fine guide ---
http://amiga.serveftp.net/RTCrepair.html
Also used Amiga PCB Explorer ---
http://www.amigapcb.org/

All measured within this guide spec.
Replaced RTC chip with new one (socketed this time), also installed new 74HCT174 (U177) chip.

Also running CR2032 battery with diode in place of R179 resistor. The voltage on pin 18 U178 about 3,0V when power is off. Still RTC isn't holding time when computer is turned off or reset is made (again only when internal HDD is connected).

I probed pins on U177 (74HCT174) chip with simple led test and I noticed that all Address line and Data line pins are switching rapidly but Q3 (pin 7) is stuck HI, but anyone here to tell is it supposed to or not? D3 (pin 6) is switching..

Here is short video of my problem. Apologies for shakin camera and all.

[ Show youtube player ]


If I boot from floppy or Buddha IDE card, clock is working fine and holding it's time when rebooted or power off.

[cdh]

I had a similar problem with an Amiga 2000 that I restored. As you probably know, the Oki MSM6242 is used on the Amiga 2000 instead of the Ricoh RP5C01, which was used on the Amiga 3000 and 4000. In my case, I had ordered replacement parts off eBay, but somehow managed to get the clock working before they arrived. I'm not sure of the exact sequence, but think it involved using a memory editor to write all 0xff values to the clock registers (at 0xdc0000), followed by all 0x00 values, followed by a CLI "setclock reset" and then a "setclock save"

In your case, your computer is acting differently depending on whether you boot from IDE or floppy. I can only guess the difference is one of the programs run during boot is affecting your result. Please keep in mind that the OS only loads the time from the RTC at boot, and if it can't find it there I think it will resort to pulling a timestamp off the filesystem. When you use the "date" command, the time is coming from the system time maintained by the running OS and not the RTC.

I wrote a program (rtc_watch) which will report both the RTC time and the current OS system time. It supports both the Oki and Ricoh parts. This might be useful for your debugging.

[arttu80]

Thank you for your reply!


I think I understand your point, but as I said the clock is working flawlessly as long as I don't use internal IDE port for HDD action. For now I resorted using Buddha IDE card and machine is ticking fine. I for that reason suspect hardware related problem, like those flip-flop chips (maybe U907) or even Gary chip...

I got so fed up with this dilemma, and disassembled state of my A4k, so for now I assembled Amiga and enjoying it as it is. And it is great!

[cdh]

Sorry that the RTC doesn't work for you when booting from the internal IDE. I'm sure the Buddha gives you much better performance anyway.

Just curious, does rtc_watch show that your RTC is ticking when booted from the Buddha? I've never had the opportunity to run my program on a 4000, just the 1000, 2000, and 3000.

[arttu80]

Yes it's ticking great!

[ Show youtube player ]

By the way, I see virtually no improvement in HDD speed with Buddha (It's only Z2 card afterall). But I use it so RTC isn't messed up. Planning to buy faster IDE card anyway.

[cdh]

Thanks for trying out the utility. It shows that your RTC is definitely ticking. My guess is that when booting off the internal IDE, either a clock register is getting corrupted by an errant program or the MMU is remapping/write protecting the 0xdc0000 region.

Puzzling for me is that in your first video, you show what appears to be a freshly booted 3.1.4 system which hasn't run the Startup-Sequence (I assume booted from the IDE). As far as I know, there wouldn't have been the chance for any non-ROM code to run. So that makes my theory less explainable, unless the OS might load some modules (68040.library?) from LIBS: on its own...