Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!ub!acsu.buffalo.edu From: cloos@acsu.buffalo.edu (James H. Cloos) Newsgroups: comp.sys.handhelds Subject: Interesting effect (HP48) Message-ID: <59716@eerie.acsu.Buffalo.EDU> Date: 14 Feb 91 03:23:16 GMT Sender: news@acsu.Buffalo.EDU Organization: State University of New York @ Buffalo Lines: 56 Nntp-Posting-Host: lictor.acsu.buffalo.edu I do not want to alarm anyone, as I have not been able to reproduce this, but Monday morning I was checking out the performance of the SPLINE suite that was posted here, and ran into an interesting problem. I gave the routines the data [ 1 5 14 30 55 91 125 153 171 175 161 125 90 58 31 11 ] [ 3 18 ] and hit the key. After about 5 minutes, I gave up on the program & tried to break out. ATTN didn't work, so I went so far as to try ON-C. This was also non-functional. (Last April or May I ran into a similar problem when I had cleared all of the key assignments & put myself in USER mode; ON-C did not work even though it is supposed to. The next time I tried it, ON-C did work, but that time it did not. I gave up on reproducing that until now.) I ended up taking the foot off and defibrillated it. The screen went blank so I hit ON, which turned it back on & gave me a Do You Want To Recover Mem screen. Of course I hit YES, and soon got that screen back, so I hit YES again & was returned 8 directories (D.0[1-8]) of which the first contained all of the other 7 (named D.0[1-7]) and the others were each of the subdir's I had w/ the exception of the SPLINE dir & its parent (which, interestingly, contined many of those recovered dirs). The '' dir came up as one of the D.... dirs. I did find it interesting that the 128K RAM card I had MERGEd was still MERGEd and the BAK in it of HOMEDIR was unchanged. The clock was also OK. I was able to recover by RESTOREing the BAK from PORT0. What is the moral of this story? I don't know, but this does make 3 times now that I had the calc lock up completely, and the 1st and 3rd were while it was running a strictly userlanguage program. (The 2nd was so bad even ON-A-F didn't work, nor did the defibrillator; only removing the batteries did.) After the first time, I mentioned in a posting that ON-C could be disabled by clearing the assignment of the ON key--asuming you are in USER mode. Someone on the design team (maybe Bill) followed-up that nothing could (in userlang anyway) block ON-C. My subsequent trials agreed with that sentiment, but now it has happened to me again, & I KNOW that I was pressing ON and C real well many, many times. There MAY be an obscure problem, or I may just have gotten a thick spurt of some interference (cosmic rays?) that mucked up RAM just enough to crash. I was given to understand that defibrillating would NOT trash mem, so it looks like trashed mem caused the crash. I would be curious to learn if anyone else has had unexplainable crashes (w/o the use of non-userlang stuff). P.S. I'm currently leaning toward some kind of RAM-affecting interference. P.P.S. FLAMES to /dev/null, bitte; only constructive replies need reply or follow-up. -JimC -- James H. Cloos, Jr. Phone: +1 716 673-1250 cloos@ACSU.Buffalo.EDU Snail: PersonalZipCode: 14048-0772, USA cloos@ub.UUCP Quote: <>