Msg: 2399 *Conference*

04-17-92 13:16:30

From: LEX JENKINS

To : RICK HANSON

Subj: GREMLINS

Hi, Rick,
 
I've run across some gremlins in using UR-II this week and wonder whether
you've experienced or heard of these critters.
 
While merging comma-delimited data files (created with T-Base) into T-Word
files, I'm pushing T-Base to maximum capacity, but staying well within the
limitations specified in the manual: i.e., observing the 255 character limit,
minus number of fields, description lines, etc.  I've used all of UR-II's
features for several months and am pretty familiar with them.  (And, knowing
one of your pet peeves, I researched the manuals THOROUGHLY!!!)
 
When I DISPlayed (F4) merged files prior to printing, and when I printed files,
everything worked normally.  However, when I used the PLOT (F2) option, the
first plotted "screen" scrolled partially and then an "Out of Memory" error
message appeared and the laptop locked up, but didn't cold start.
 
Neither BREAK nor F8 (Menu) would unlock it, so I'd have to press reset.  The
UR-II menu would appear and I could continue working as if nothing had
happened.  Or so I thought.  When I examined the .DO files GRPH and CODE
characters had been randomly substituted for alpha-numeric characters.  In the
worst "crash" pressing reset sent me all the way back to the standard menu and
EVERY file (.DO, .BA and .CO) had swapped filenames!  All the files were
intact.  All filenames were intact.  They'd just played musical chairs!
 
After a while, even straight text files (no merging) wouldn't operate properly.
When I'd press the DISPlay or PLOT keys it'd jump back to the UR-II menu rather
than going into the document.  Most of these incidents resulted in a few
randomly substituted garbage characters.
 
This occurred on both my 102 with Booster Pak and my "stock" 100 with extRAM,
using UR-II on both.  I cold-started the 100 and gave UR-II a test run, without
trying any complex merging.  It worked OK.
 
However the gremlins have continued on my 102.  I killed UR-II, cold started
the RAM workspace and tried again: same problems.  I finally decided to kill
and reformat the entire RAMdisk on the Booster Pak and start over.  Same
problems, plus a new one: when I entered CLEAR 256, MAXRAM to clear HIMEM
(which I've done many, many times without problem) the 102 either locked up or
cold started.
 
Let me summarize my questions:
 
1. Is crashing while trying to PLOT-preview a merged document one of those
hidden "features" of UR-II you've alluded to?
 
2. Can crashes of this type write data to addresses above and below RAM which
could compound problems?  I recall you and Tracy Allen have mentioned that
certain ROMs - Multiplan and some of PCSG's ROMs - can write data to the
laptop's ROM space during NORMAL usage.  Unless I misunderstand the concept, it
seems possible that ROM-based programs could write data (even meaningless data)
above and below user RAM during ABnormal circumstances.
 
3. Can crashes write data to, or delete data from, EPROMs?
 
4. Would errors of this sort be unaffected by cold starts?  Would they defy the
usual attempts at de-gremlin-ing?
 
5. Does this sound like a hardware problem, possibly in the UR-II ROM?  Is
there a utility, similar to RAMTST.BA or RAMCHK.BA, to test the integrity of
ROMs?
 
Finally, wouldn't you rather be enjoying a lovely Easter weekend?  I know I
would.  I'll be playing in the dirt in the garden this weekend.  Anything to
get my face out of this screen for a while!
 
<Lex>