The internal battery always preserves the ram contents as long as it's a
working battery.
Reset can happen fairly easily from crashing software, but it requires
some sort of software error, IE either a bug in the software or a
corrupt copy of the software from a bad serial transfer.
Merely using the serial port, even with dead batteries that die right in
the middle still doesn't cause a reset or lost data.
Old caps can do it though because they make the entire machine generally
unstable, resulting in random corrupt activity inside itself just for
normally ordinary operations like just accessing rom or ram on the bus.
That affects all things and could cause a reset at any random time not
just during serial port usage, but one thing I think the serial port
does different from most other things is draw a little from the negative
power rail, so maybe VEE is weak and marginal, good enough to keep the
machine running most of the time but the serial port just pushes it over
the edge?
But it's definitely a thing that happens from software and not normally,
just from a bug or corrupt copy, so suspect all software that hasn't
been proven by decades of use already, and that does include REXMGR if
it's not an old proven version. I believe REXMGR installs timer
interrupt code that runs all the time even when you aren't in REXMGR. I
might be wrong about that, Steve would have to say.
To diagnose, just remove the REX# entirely, reset, load a known-good
copy of TS-DOS in ram and just do a bunch of transfers. Or even better
do a bunch of plain TELCOM traffic with no other software at all
installed. Normally, even trying to overload the machine by using
too-high of baud rate that it can't keep up with, and pasting a 100K
text file into the terminal on the pc side etc, doesn't cause it to
crash or reset reset, you just collect a bunch of corrupt data until ram
fills up, but still no crash or reset.
Then only proceed from there. If that still crashes, then you have a
hardware problem. If it doesn't then add one variable back in, like
install the REX# physically but don't install it's software yet (don't
call 63012), and test again like that. Then install REXMGR and test
again. If it doesn't fail until after installing REXMGR, try flashing
the REX# back to an older version of it's firmware. If it never fails
again, only *then* try using whatever other software you were trying to
use originally (whatever that was, since you didn't say, ts-dos? telcom?
rexmgr loading rom images or backups? some other unknown
serial-port-using app?)
But you'll have to go methodically from the ground up like that if you
ever want to figure it out. Start with nothing but the stock machine,
and then add a single variable at a time back into the mix.
--
bkw
On 2/6/23 12:38, Cedric Amand wrote:
Hello,
While trying to help Stephen testing new REX software, I've been
investigating crashes of both my M102 and M200 (unrelated to REX)
It seems that when using batteries that are "bit low" (but the red light
does not turn on), together with anything using the serial port
(transfers, TPDD,etc) again the light does not turn on, but I have
system crashes that wipe the memory (basically equivalent to
CTRL-BREAK-RESET)
My systems comes back empty, date in 1900, you know the drill.
Am I alone ?
Is this indeed related to using serial, or maybe just to low battery ?
Why doesn't the backup battery protect my work (they are brand new) ?
What can I do to avoid those "memory wiping crashes" ?
Could it be related to the fact both systems have a REX# ? (I doubt it -
but hey, I also doubt these things wiped their memory twice a day back
in the day)
It's super frustrating because each time they occur I loose a bit of
faith in my ModelT's, and you don't want that.
If I could at least investigate a possible cause, that would help me.
--
bkw
