WKF2298@RITVAX.ISC.RIT.EDU (Wonko the Sane) (01/10/91)
Alas, I have been writing a large program and as I am approaching the end, strange things began to happen. Just for the sake of brevity, the program basically does a whole series of file manipulations to create a disk structure. To do this, a script is loaded and stored in the graphic page (which is not used) at $2000. The program had been working fine, but last evening I added a few more items to the end of the program. Suddenly, it started breaking down because the script had been overwritten at $2000 and of course, the program crashed. When I checked the location, the whole graphic page had been filled with the contents of a trivial little variable which was used once in the whole program; it repeated indefinitely. To fix it, immediately after the variable was used, I set it equal to "" and that seemed to solve the problem. Today, after adding yet another section to my program, a similar problem occurs where my scripts are being overwritten by garbage. What is really, really odd is that the program does not even run as far as the new material before it crashes! It overwrites almost instantly. Originally, I figured my variables were the culprit, but it doesn't go far enough for that to happen. Granted, the program contains an unbelievable amount of variables, but I frequently drop an x=fre(0) to run the garbage handling rountines. And it is not that my program is too long that it runs into the graphic page. Is there something more that I can check? I've never really familiarized myself with the HIMEM LOMEM commands, but is there something that I can do to isolate that portion of memory from being written to? Also, I may need to use the entire graphic page. . . is that too much to ask? :-) Thank you all very much in advance! I was hoping to have this finished for a project by next week, so any help would be greatly appreciated! Thank you. William K. Fry wkf2298@ritvax.isc.rit.edu
nagendra@bucsf.bu.edu (nagendra mishr) (01/11/91)
try this lomem 16384 himem 8192 that should block off hires page one for variable storage. but it might not let your program grow, so maybe you should move your script higher in memory, himem $6000 and don't do anything to lomem and use $6000-$8000 for your script storage. It's been a long time since I used these routines, 4-5 years, so I'm not sure as to how accurate they are. Try the book "Dostalk scrapbook", really old, but it contains these tidbits. nagendra@bucsf.bu.edu
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (01/11/91)
nagendra@bucsf.bu.edu (nagendra mishr) writes: >try this >lomem 16384 >himem 8192 >that should block off hires page one for variable storage. Don't use himem: 8192 unless your program is really small. I'd also recommend moving your script up and himem: -ing just below it. Todd Whitesel toddpw @ tybalt.caltech.edu
neufeld@physics.utoronto.ca (Christopher Neufeld) (01/11/91)
In article <NAGENDRA.91Jan10111804@bucsf.bu.edu> nagendra@bucsf.bu.edu (nagendra mishr) writes: >try this >lomem 16384 >himem 8192 >that should block off hires page one for variable storage. > That's not legal, at least not in Applesoft BASIC running under DOS3.3. You get an OUT OF MEMORY error if you try it. You can poke the values directly into zero page to force this condition, but then the computer will crash. The way to protect memory from numeric and string variable overwrites is to put the routines which you don't want clobbered outside of the memory range {LOMEM...HIMEM}. If your machine language fragment is at $4000 (16384) and uses 4kB, setting LOMEM:21000 will avoid hitting it, and will provide you with room if your machine language segment grows a bit in future. Applesoft programs, unless they use large arrays, rarely run into memory limitation problems. If your BASIC program is so long that it is threatening to hit your machine language fragment, well you should have written the fragment in relocateable code or you'll have to reassemble it from your assembly listings. You can get around this, the simplest way is to write the machine language fragment to run at $800, then make the following the first few lines of your program: 10 REM PROGRAM MAIN 20 REM THIS PROGRAM LOADS IN AT $1000, LEAVING 2KB ROOM FOR THE 30 REM MACHINE LANGUAGE FRAGMENT LOADED AT $0800 40 IF PEEK(104) = 8 THEN POKE 104,16: POKE 4096,0: PRINT CHR$(4)"RUN MAIN" 50 PRINT CHR$(4)"BLOAD FRAGMENT,A$800" ..... With this setup the program automatically reconfigures zero page space and reloads itself from disk into the right place, then loads FRAGMENT into the safe space below itself, which can never be intruded on by variables without conscious effort by the programmer (there are POKEs to move variable storage here if you're that kind of person). Now you don't have to play LOMEM, HIMEM games, and the Applesoft program can grow as much as it likes without threatening your code fragment. Note that this technique is particularly useful when you have a long Applesoft program which uses high resolution graphics. You move the load address to above the graphics page. The '104' in the code above comes from the start of program pointer at $67,$68 in LO-HI format. The program loads at the pointer+1, and the memory address referred to by the pointer must be set to zero (hence the POKE 4096,0). If you have a particularly long program, and you don't want to reload it as this fragment does, write a four line launcher program like this: 10 REM PROGRAM LAUNCHER 20 IF PEEK(104) = 8 THEN POKE 104,16: POKE 4096,0 30 PRINT CHR$(4)"RUN MAIN" 40 END to run your program "MAIN", run "LAUNCHER" instead, and it will set up memory and run the program. >nagendra@bucsf.bu.edu -- Christopher Neufeld....Just a graduate student | "Shtarker! Zis is KAOS! neufeld@helios.physics.utoronto.ca Ad astra! | Vee do not 'yippee yo cneufeld@{pnet91,pro-micol}.cts.com | kye aye' here!" "Don't edit reality for the sake of simplicity" | Siegfried of KAOS
AABENSON@MTUS5.BITNET (01/11/91)
You could also try loading your basic program ABOVE your hires page. - Andrew. (aabenson@balance.cs.mtu.edu or aabenson@mtu.edu)