★ APPLICATIONS ★ PROGRAMMATION ★ ROLAND WADDILOVE'S Variable Dump takes the slog out of error checking ★ |
| Variable Dump (Computing With the Amstrad) | Applications Programmation |
Check your variables to spot your mistakes VARIABLE Dump is a short machine code routine to add an extra command |VARDUMP as an RSX. It simply lists all the variables that have been used by a Basic program. Why would you want to list all the variables? Well, suppose you typed in a listing and it didn't behave as expected when run. It's most likely to be a simple typing slip. One of the features of Locomotive Basic is that it will create an additional variable every time it comes across a word it doesn't recognise. So if the program uses a variable called score and you accidentally typed scare instead it would add scare to its list of variables. By printing all the variables it's easy to spot any that have been entered incorrectly. The program must be run before using IVARDUMP. After each variable name it waits for a key to be pressed. This is to prevent long lists of variables scrolling off the top of the screen. To understand how the routine works we need to know how the Amstrad stores its variables. These are stacked up in the memory starting at the end of the program. Arrays are always placed at the end of the variable stack. All other variables are inserted before these. I'll call the address of the end of the program currently in memory TOP. The value of TOP is stored at &AE85 if you have Basic 1.0, and at &AE68 if you have Basic 1.1. The CPC464 has Basic 1.0 and the CPC6128 has Basic 1.1. The lowest point in the memory which is free I'll call LOMEM. This is the top of the variable stack. Basic 1.0 stores LOMEM at &AE89 and Basic 1.1 stores it at &AE6C. The end of the normal variables and the start of the arrays is stored at &AE87, Basic 1.0 and &AE6A, Basic 1.1. Variable Dump prints the ordinary variable names first, if there are any. These are stored between TOP and the start of arrays. Of course if these two values are the same then there aren't any. When Basic stores the variable it ANDs the characters of the name with &DF to convert any letters to upper case. This has the unfortunate effect of converting any numbers in the name to Ascii values below 31 -reserved for control codes. The last letter of the name is marked by setting bit 7 of the Ascii code. To print out a variable s name the characters are ANDed with &7F, then ORed with &20. This restores the name. The byte in memory immediately following the variable's name indicates what type it is. An integer is 1, string 2 and real 4. A % sign is printed after integers' names and a $ sign after strings. The address of the next variable name is found by adding the space taken up by the variable to the address of the type byte. Integers take up 5 bytes, reals 8 and strings 6. Remember that the actual string is placed at HIMEM. The data in the variable stack is the string descriptor giving the name, length and address of the string. A separate routine is required to handle arrays. The name and type is printed out in the same way, followed by a pair of brackets to show that it is an array. The actual space taken up by the array depends on the number of dimensions and elements there are. The two bytes following the type byte tell us how much space has been reserved. The next variable is stored at the address of these two bytes plus their contents plus 4. If the address of the next variable is equal to LOMEM all the variables have been listed. Program I is a Basic listing with the machine code stored in data statements. Run this and call &A000 to enable the RSX. Program II is an assembly listing of the routine. You should find debugging a lot easier using Variable Dump to list all the variables. Now all we need is a routine to tell us which line the misspelt variable is actually in. Can anyone help?
|
