streeter@theory.lcs.mit.edu (Kenneth B Streeter) (05/24/91)
I have recently purchased a used Model 100, and have two questions
that I can't find answered in the Users Manual, or Technical Reference
manual:
1) Does the "Text" program require a large portion (~10K to ~11K) of
RAM for the program?
I have a 24K Model 100. When I first start the machine up from
a cold start, the machine shows around 21K free on the menu. If I
enter the "Text" program, create a short text file (say containing
1 character), and exit "Text", I find that around 10K have suddenly
disappeared! If I enter BASIC, type "clear", and return to the
menu, the missing memory has returned. It seems to me that the
"Text" program must be copying itself, or a portion of itself into
RAM for execution. What does this mean if I have less than
sufficient room for this to be done? Does "Text" not work?
2) When issuing the "clear" command from BASIC, sometimes (it seems to
be whenever I have less than about 9K of free memory remaining) the
machine just LOCKS. That is, the "Ok" prompt never returns in BASIC,
none of the keyboard keys have any effect, and the only thing that
"fixes" things is a power cycle. When the power is cycled, the machine
has been completely reset in that date and time are set back to Jan 1900,
00:00:00, and all memory is cleared. What is going on? Is something
wrong? What could I do to try to debug/fix this?
Any help would be greatly appreciated!
--
Kenneth B. Streeter | ARPA: streeter@im.lcs.mit.edu
MIT LCS, Room NE43-350 | UUCP: ...!uunet!im.lcs.mit.edu!streeter
545 Technology Square | (617) 253-2614 (work)
Cambridge, MA 02139 | (617) 225-2249 (home) cameronjames@snoc01.enet.dec.com (James Cameron) (05/27/91)
In article <1991May24.125838.29358@mintaka.lcs.mit.edu>, streeter@theory.lcs.mit.edu (Kenneth B Streeter) writes: >1) Does the "Text" program require a large portion (~10K to ~11K) of > RAM for the program? No. The program executes in ROM only. It allocates memory for the file that you are editing at the time, and for the paste buffer. The memory for the file expansion is allocated in 256 byte chunks, I think. The file is edited in place; TEXT doesn't make a copy of it. The behaviour you describe is not at all what I would expect. Consider possible problems with the RAM chips, or even a doubtful internal power supply voltage. Maybe ask Tandy to fix it? >2) When issuing the "clear" command from BASIC, sometimes (it seems to > be whenever I have less than about 9K of free memory remaining) the > machine just LOCKS. That is, the "Ok" prompt never returns in BASIC, > none of the keyboard keys have any effect, and the only thing that > "fixes" things is a power cycle. When the power is cycled, the machine > has been completely reset in that date and time are set back to Jan 1900, > 00:00:00, and all memory is cleared. What is going on? Is something > wrong? What could I do to try to debug/fix this? The ROM does something intelligent to ensure that the memory is still as it should be after a power fail and restore. It writes a series of values into specific areas, and if those values match, then memory is assumed to be OK. If the values do not match, then the ROM assumes that all of memory is corrupt. It initialises the clock and the pointers in memory that describe the files that exist. The file data can be still there; and can be accessed using PEEK from BASIC with a small bit of programming. I would guess 1) The RAM is sick, and has lost it's ability to retain information in a particular geographic area, 2) The RAM Battery is sick, and so the RAM is not functioning within specifications, 3) The power supply is sick, 4) Something about the address or data bus is sick, causing (especially) the ROM to think that RAM is empty on reset or power up. 5) There is a software flaw in the ROM. For all but 5, get a service type to look at it. For 5, check with other users to see if there are any known bugs in the 100's ROM that have been detected in the past. Did this problem just appear or did it always do that since you got it? Maybe you should try a short BASIC program to test all of memory. The simplest one that comes to mind is; 10 print @0, fre(0); : gosub 10 This will fill available memory with GOSUB stack frames, and the memory display will move towards zero. When it gets close, BASIC will issue an error. On machines with memory trouble, I've found that the program rarely runs through to the end. There is usually some unpredictable behaviour, if the problems are related to power supply, address or data bus. A geographical problem in the RAM could produce predictable results. If you're willing to open the machine, check that the RAM chips are correctly seated/soldered. If you lose one address line, you could (i.e. perhaps/maybe/5%) get strange results like this. -- James Cameron Digital Equipment Corporation (Australia) P/L (cameronjames@snoc01.enet.dec.com)