Fractal footnote Dean Cracknell has written a coda to his three-part fractal feature to aid those who had problems getting it to work. Ever since I first typed-in a program from a listing published in ACU many, many years ago, I have disliked multipart listings, mainly because after hours of typing, you have to wait until the next issue before you can run the fruits of your labours, and then only after several more hours typing. To make matters worse in my fractals series the glueware to bring the two parts together was missed out. Here is the missing glueware: Use the following program to combine the two halves of machine code, “FRA-A.BIN” and “FRA-B.Bin” to produce “FRA-CODE.BIN”: 1000 MEMORY &90FF
1010 LOAD “fra-a.bin”,&9100
1020 LOAD “fra-b.bin”,&9767
1030 SAVE “fra-code-.bin”,B,&9100,&C00
1040 PRINT “All code saved”
1050 ENDTo merge the two BASIC programs, “part-1” and “part-2”, insert the disc with both halves on it in the drive and
type the following commands from the keyboard:NEW
LOAD “part-1.bas”
MERGE “part-2.bas”
SAVE “fractal.bas”If you have all the code from both articles, and have successfully merged everything together using the listings above, your Landscape Generator program will now run as I had intended it to.The programs were published with their proof-codes, for use with the proof reader program that was reprinted on page 58 of the February 1990 issue of ACU. To further aid the typist, line checksums were added to each data-line of the machine code loaders, these act as a double check as mistakes are easily missed when reading lists of hex-numbers. So if the proof-reader codes agree with each line that you have typed, but running the program produces a message like Keith Jones's “ERROR in Final C/SUM” from the letters page Feb 90, even though the staff of ACU assure you that all the programs work correctly, what could have gone wrong and how do you fix it? The only way to debug a program is to attack it logically, the approach is more or less the same each time, however the actual steps taken are determined by the particular line that contains the error. The message is printed in line 1150 if (and only if) 'CSUM' does not equal 'CCSUM'. There are three possible reasons for message to be printed: 'CSUM' is wrong; 'CCSUM' is wrong; or line 1150 is itself wrong. The proof reader says that line 1150 is correct. 'CCSUM' is read from the last line of the program (line 5050) and the proof reader says that is correct as well, so it must be 'CSUM' that is in error. One advantage with using Basic over compiled languages such as Pascal or C is that when the program stops with an error message, the program data is still in memory and can be inspected from the keyboard. This means that we can print the value of 'CSUM' that caused the error using: PRINT HEX$ (csum)The correct answer should be “4ABC”. Line 2030 calculates this value by adding-up all the line checksums 'LSUM'. Each 'LSIJM' is checked by both the proof-reader and the program itself, so they must also be correct, therefore the only possible cause for the error is that not all the 'LSUM' values have been added together, or to put it bluntly, some lines must be missing from the typed in program. To prove this, “PRINT (5050-Lnum)/10” from the keyboard, will tell you how many lines have skipped. If you are having a similar problem with the “FRA-B” program, then the final checksum should be &0F2A and the line count (Inum) should be 4790.Another common error message displayed by the machine code loader programs is TYPE MISMATCH IN 1100'. None of the readers who reported this error said they used the proof reader, and as I cannot think of a way that this message could be printed by a program that had been checked, I must assume that it was not. Line 1100 is a multi-statement line, but the only statement that will give this message is the VAL() statement. For an indication of what the data was that has caused the error, print the string 4a$\ What you should see is a line of characters that are made from the numbers 0-9 and the first 6 letters of the alphabet, any other characters in this line are wrong and should be corrected in the DATA line, whose program line number can be determined by printing the line counter variable LNUM.
However, if what you see is the group of four characters (i.e. ####) from the last line of the program, then these should match the group of four characters in line 1080. If they do not, then change them so that they do. If they do, then check that line 1080 is syntactically correct. All of the practical causes for this error that 1 have listed here would have been caught by using the proofreader program. As you can see from the two examples above the proof-reader is an invaluable debug tool if the program that you are typing in has the proof-codes printed along side it, even when all the proof-codes are correct and the program still does not run. However, even this is not totally infallible, if you look at line 3590 of “RRA A,BAS” (Dec '89), whose proofcode is [48], you will see that a small exoskeletal invertibrate creature has crawled under the typeface and preventing some of the ink from being deposited on the paper, this has caused the [48] to look like [18] -entomologists call these creatures insects, programmers call them bugs. Finally, I have been asked how you load the landscapes saved by the program with all the correct colours. Well the simplest way is to copy Subroutine 2 from the main BASIC program listing (Lines 1620-1660), which sets the ink colours, and then load the screen image file from disc or tape using: MODE 0
LOAD “!s0000'.scr”,$C000With a small amount of ingenuity you should be able to put together a short program that will display a series of frames in sequence, much like a slide viewer. |
