It has come to my attention that several JLO SAFE users have been having some trouble using the new SAFE “MERGE” command under certain conditions. This note will detail the results of my investigation into this problem, as requested by several Oliger Disk System owners.
I have had reports from a few users that indicated a problem may exist in SAFE causing the MERGE command to sometimes not work. The users reported that SAFE would act like it had MERGED the Basic code, return with an “OK” report, but when they would LIST to look at the additional code it would simply not be there. Repeated attempts to MERGE the BASIC into the same program would give the same result. However, when asked for a sample disk that contained the programs that resisted MERGE, nobody could provide me with the sample for one reason or another. Repeated attempts to cause the problem myself would always fail. I couldn’t get it NOT to work!
Finally one customer called with a report of the problem, and he had it doing it right then, before our very eyes (and ears)! He told me he would make a copy of the disk having the problem and get it off to me to work with.
I recieved the disk and quickly went to work. The main program on the disk contained Bill Jone’s (are you listening Bill?) “SMART DAISY” Basic program, and the Basic code to MERGE was a ten line or so eprom programming subroutine that started at line 9980. The last line in SMART DAISY was line 9520. I loaded the main program and then tried to merge the programming subroutine. As reported, the drive and SAFE ACTED like it had been merged but I sure couldn’t see it there!
Further investigation found that I could not get a good merge after Smart Daisy was loaded even after the CLEAR command was used and even when Smart Daisy itself was removed using the DELETE , command!!! I found that <PRINT FREE> would return only 38289 bytes free after SMART DAISY had been loaded and then removed with CLEAR and DELETE , but on power up before any loads the computer had 38652 bytes free. I had somehow LOST 363 bytes of memory by loading SMART DAISY and then getting rid of it!
After running HOT Z AROS to find out just what was going on, I found that the pointers to the variables area and program area were not the same as they are when the computer is first powered up. Looking at where the computer thought the program was showed a lot of gibberish and portions of one of the screen copy routines used on the cassette supplied with the Oliger Printer Interface.
I checked out several copies of Bill Jone’s SMART TEXT and found that EVERY ONE of them from the very first was missing those same 363 bytes. They ALL had the same gibberish where there should have been program lines at the end of the basic.
Evidently somewhere along the line (very early) Bill’s program had been corrupted, either through glich, cassette data error, stray POKE(s), or whatever. The MERGED code is actually there, but Basic can’t find it to LIST or RUN because the gibberish before it in memory confuses it.
Although all of Bill’s Smart Text series programs seem to have this same corruption, there are likely to be other programs found that are also like this. Because of the way Basic programs are stored, saved, and loaded on the 2068, once something like this occurs and the program re-saved (using either cassette or disk), it will forever exist because as far as the computer is concerned it IS a part of the Basic program, even though it can’t use it or LIST it.
I hope I haven’t bored everyone to sleep by now. I’ve attempted to go through the entire process of how I try to resolve a problem like this reported to me. Sometimes I beat my head against the wall all day long and never get a problem solved. If you have a real strange problem with a certain command or function in SAFE just some of the time, PLEASE put it on disk as a sample and send it with your letter. It can REALLY be a big help!
So, how do you know if a program has this problem? If you cannot use the SAFE MERGE command with it then it is very likely. But the REAL test is to use the command <PRINT FREE> immediately after power up and again after the program is loaded and the removed using <CLEAR :DELETE ,>. If the numbers don’t match you can be fairly certain that the program does contain corruption (unless it had self-run and used the CLEAR N command). I will now detail step by step how to fix this:
1) FIND AMOUNT OF PROGRAM MEMORY CORRUPTED:
A) Write down result of the statement <PRINT FREE> immediately after computer power-up. (38652 on standard 2068 w/o any cartridges installed)
B) Load corrupted program. Save variables to disk with the command <SAVE /”vars” VAL>. Clear both program and variables from the computer with the command line <CLEAR :DELETE ,>. Now write down result of the statement <PRINT FREE>. (38289 for Smart Text)
C) Subtract the number written down in 1B above from the number written down in 1A. Write this number down. (363 for Smart Text) This is the amount of memory corrupted.
2) FIND CORRECTED BASIC VARIABLES POINTER:
A) Re-load corrupted program and remove the variables again with the <CLEAR> command.
B) Enter the command <PRINT PEEK 23627+ PEEK 23628*256>. Write down this number.
C) Subtract the number obtained in 1C from the number you just wrote down in 2B. Write down the result.
3) FIND NEW VALUES TO POKE:
A) Divide the number obtained in 2C by 256. Round down to the next whole number and write this down. (MSB)
B) Multiply the number just written down in 3A by 256. Subtract this product from the number obtained in 2C. Write down the result. (LSB)
4) SET THE VARIABLES POINTER CORECTLY AND CLEAR THE CORRUPTION:
A) Set the variables pointer with the command <POKE 23627,LSB: POKE 23628,MSB> with “LSB” and “MSB” replaced by the numbers written down in 2B and 2A respectively.
B) Clear the corrupted memory by using the <CLEAR> command again.
5) GET IT ALL BACK ON DISK:
A) Re-load back in the old variables with the command <LOAD /”vars” VAL>.
B) Re-save the repaired file with the regular <SAVE /”Filename”> command.
The “cleaned-up” program should now allow MERGE to operate and be shorter to boot!
John L. Oliger 2/88