Time not advancing in U1M/SDX

[+MacRorie]

Installed the newest firmware in an Ultimate 1M tonight and all went well until I happened to notice that the time was not advancing.  It does not advance in the Ultimate BIOS screen or in SDX when I turn TD ON.  If I power cycle the machine, it retains the time, but it does not advance, even the seconds remain the same.

 

That seems odd.  Any suggestions?

 

Thanks

-M

[flashjazzcat]

Clearly not a software issue (even if there was a firmware bug, which there is not, the fact ULTIME.SYS does not read the clock absolves software, regardless of whether you registered the issue before updating the firmware), so you need to check for installation faults, bus stability issues, etc. Does the coin cell battery work?

[+MacRorie]

33 minutes ago, flashjazzcat said:

Clearly not a software issue (even if there was a firmware bug, which there is not, the fact ULTIME.SYS does not read the clock absolves software, regardless of whether you registered the issue before updating the firmware), so you need to check for installation faults, bus stability issues, etc. Does the coin cell battery work?

Well, I am presuming that if the U1M is retaining the time, then the battery is working.

 

Here’s an interesting thing:  if I boot into SDX via the Side2 cart on this machine, time progresses as normal.  Again, this is SDX on the Side2 which is many many iterations old.

 

Just out of curiosity: Isn’t the time supposed to advance in the BIOS screens as well?  That is independent of ULTIME.SYS, right?  The time should advance with power off, right?

[flashjazzcat]

17 minutes ago, MacRorie said:

Well, I am presuming that if the U1M is retaining the time, then the battery is working.

Of course: overlooked that.

 

Anyway: hardware fault. Try a different U1MB in the same machine. The usual troubleshooting steps in which you will be well-versed.

[+Nezgar]

3 hours ago, MacRorie said:

Well, I am presuming that if the U1M is retaining the time, then the battery is working.

Maybe it wouldn't hurt to try a fresh battery anyway, just to rule it out completely? I remember in my R-Time 8 days it would start doing strange things when the battery voltage was borderline...

[+MacRorie]

On 11/7/2019 at 1:31 AM, flashjazzcat said:

Of course: overlooked that.

 

Anyway: hardware fault. Try a different U1MB in the same machine. The usual troubleshooting steps in which you will be well-versed.

 

On 11/7/2019 at 5:00 AM, Nezgar said:

Maybe it wouldn't hurt to try a fresh battery anyway, just to rule it out completely? I remember in my R-Time 8 days it would start doing strange things when the battery voltage was borderline...

 

Thanks for the suggestions, folks!  Tried the battery, but that was not it.  Did some R & R.  No joy.  Did some testing on the XL without success.  Shouted curses at the 8-bit gods and they caused me to release the magic smoke from a CD4050BE.  Made obeisance to the 8-bit gods and genuflected my way to removing, socketing and replacing said 4050.  Pulled all of the base RAM (4564s of varying manufacture) and replaced it with 4164s.  Made an offering.

 

Installed U1M.  Time advanced.  All other things appeared stable.  Did a 24 hour burn-in and all seems well.  Did a proof of life video, all went according to Hoyle.  Boxed it up and sent it to my friend.

 

Whew!

[Mclaneinc]

Close, that could have needed a sacrifice...

[+Nezgar]

Good to hear you had a succesful conclusion!

 

Thinking back to a 130XE I had with 1 bad DRAM in the extended bank, main 64K good. my SIDE2's clock would reset the RTC to 0 when used in that system, even with a CONFIG.SYS with USE OSRAM. For some reason the bad extended RAM was still affecting the SIDE2 clock...

 

That and another 130XE that had an extended 64KB that checked out fine (after replacing 1 bad dram) but when swapping one end of R110/R111 to swap the base and extended 64K, sys-check would intermittently freeze when checking the OSRAM area. Swapping it back it was fine... chalk it up to marginal RAM with poor timing issues. Atari may have also observed and addressed this as XE's often had 1 different brand dram, which maybe improved the timing of the rest..

 

tl;tr - good idea to swap the RAM as a troubleshooting step!

[+MacRorie]

1 hour ago, Nezgar said:

Good to hear you had a succesful conclusion!

 

That and another 130XE that had an extended 64KB that checked out fine (after replacing 1 bad dram) but when swapping one end of R110/R111 to swap the base and extended 64K, sys-check would intermittently freeze when checking the OSRAM area. Swapping it back it was fine... chalk it up to marginal RAM with poor timing issues. Atari may have also observed and addressed this as XE's often had 1 different brand dram, which maybe improved the timing of the rest..

Yeah, this one had a real mishmash of DRAM. One was even from Apple!  

1 hour ago, Nezgar said:

tl;tr - good idea to swap the RAM as a troubleshooting step!

Thanks! I figured it couldn't hurt.