• Please review our updated Terms and Rules here

Tandy 102 Date/Time/Day issue

AndyO

Experienced Member
Joined
Sep 5, 2020
Messages
141
Location
U.S. East Coast
I have a Tandy 102, which I've been using with a Rex# for a year or so. Great little on-the-go laptop, which has worked mostly without any issues until recently.

The first problem was that it would sometimes crash and need a cold boot - thus losing my data - when accessing the REXMGR software. It would just hang with a blank screen. Then, after the last cold boot, it came back up working as normal, except that the Date/Time and Day were corrupted. Entering BASIC, I used date$, Time$ and day$ to set them, but they still show corrupted.

The line now read ros ??,1923 n)s ??:??:??

A cold boot doesn't change this, and in BASIC, if I enter the correct date$, Time$ and day$, then ?date$ etc, it shows the same data, not the correct data, so it isn't being saved.

I removed the REX#, but the problem prevails.

Any ideas?
 
Definitely a hardware problem. Do you have an oscilloscope? There is a signal you could check.
 
Thanks for responding!

Sadly no oscilloscope. The only thing I have is a multimeter unfortunately. In other respects, the 102 appears to function normally. I loaded TS-DOS via the BackPack drive I have, and that seems to have been successful and functional - I should have check the date stamp on a file I saved just to see, but I think the BackPack has an RTC anyway.

I initially thought the issue was with the REX#, and switched that to my M100 instead. The behavior was the same, so I removed it again. After a cold boot, the M100 date/time/day settings reverted to normal. I take that to mean the REX# retained the settings from the faulty 102, thus carried to the M100.
 
It is working perfectly as far as I can tell, except the date/time/day issue, which unlike the M100 has not reverted to normal after removing the REX#.
 
Ok makes sense. I think ( I should know) that rex# keeps date time in the saved ram image. So yes a bad date time would propagate into a saved ram image and when reloaded would set date time.

So you have an issue with T102 hardware. I've seen something like this happen with a dead 32kHz crystal. A little time with a soldering iron can swap in a new crystal. But hard to say exactly what the issue is.
 
Wouldn't a dead crystal cause more broad issues than this? The thing I find odd is that the 102 otherwise seems quite happy.

I do have a soldering iron, though no recent soldering skills. I'm reluctant to mess if I don't know what I'm doing, but this is my go-to system for document drafting - it being light, instant on, and totally distraction free, with a superb keyboard - so I'm happy to give it some TLC... or get someone else to do it if it's not a job to be trusted to a ham-fisted blunderer!
 
Ah, ok, that would make a lot of sense. So the question would then be if the crystal has failed, or something in the circuit that drives it. Is there any way to test something like voltages with a basic multimeter?

Perhaps I could find a copy of the service manual and see if I can make some sense of that!
 
Temporary as it obviously is, the 102 is now showing an actual date and time. It wasn't earlier, and I was curious how it would deal with the schedule app without knowing what the date was. After I ran that, the (wrong) date showed up on the main menu. But while it was wrong, it was wrong by the correct number of days since I cold booted the system last.

I have entered the correct date/time/day (aside from Y2K, obviously) and it displays correctly.

What on earth could cause that?!
 
What's odd is that after I'd used it for an hour and the date was still correct, a warm boot left it with the corrupted data again. Re-opening the document I had been working in, and then returning to the menu (I'd forgotten to check available RAM) showed the corrupted data, which then reverted to the correct date. It's been showing the correct date since.

Obviously, components can have odd failure modes, but I actually saw the corrupt data revert to the correct date/time/day a second after the main menu came up.

(The Rex# is not installed in the system, and no external devices were connected).
 
Definitely a hardware problem. Do you have an oscilloscope? There is a signal you could check.
To update: After another date/time glitch which lasted a day or two, in early August one morning on powering up, it had reverted to Jan 1 1901 etc. After setting it correctly, it has retained the correct date/day/time through over a month, and multiple uses.

But, as a matter of curiosity, since I do actually now have a very basic oscilloscope, I wonder what the signal is I could check?!
 
you could check for 32kHz signal at pin 12 and/or 13 on M18 RTC chip, and/or see timing pulses on TP at pin 10. Timing pulses are short duration pulses, 256 times/sec.
 
Back
Top