Issue 11, February 1985 - Error Trapping
| Home | Contents | KwikPik |
 | |||||||||||||||||||
| Error messages on the Speccy never seem to account fully for their sudden appearance. John Durst has come up with an interesting piece of code that'll use the error handling routine in ROM to give control to the user's program in the event of overflows, keying errors and the like. | |||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Here come two ways of making the Spectrum 'error' routine do something more
useful than simply drop hack into the
command mode, with appropriate
message. Before using either of them, it's as well to make sure that the program is not going to generate any real errors; that is, it should be properly de-bugged, so that any 'errors' are ones that can be dealt with by the program itself. This limits the possible errors mainly to Break effects - or perhaps, overflows, keying errors, undefined variables and the like. The reason for this is fairly obvious. If your program generates a really serious error, the appropriate message is the best possible response; that way you have a chance of doing something to stop it happening again. Any 'automatic' response is likely to push you deeper into the mire. CHANGE OF ADDRESSThe easiest way of changing the error response is simply to alter the address in ERR_SP and make it point - say - to the start of a routine (a menu, or something similar). This works pretty well with an all- machine- code program and I've used it to send any kind of Break back to the main menu - usually a Break during LOAD, or SAVE, or a pre-programmed Break key input. Unfortunately, it doesn't work at all well from a Basic program, tending to do nothing at all, or execute NEW.A more elaborate system, which will work from a Basic program involves the old idea of making changes to the Interrupt mode. By altering the Interrupt mode from one to two, you can arrange for ERR_NR to be scanned at each interrupt. If the routine finds anything other than FF (which means 'all clear'), it does a jump to a routine which sets up the data for a command - such as 'GO TO 10' in E_LINE - and then executes it. This seems virtually fire-proof, except that - occasionally - it's possible to overcrowd the editing space. The Spectrum gives a mighty burp (from indigestion?) and comes up with the message 'GO TO 10' (or whatever) in the lower screen. However, if you press Enter, it does what it's told, as good as gold. The answer is very simple - 'GO TO 10' consists of nine bytes, as follows: EC 31 30 0E 00 00 0A 00 00 |
EC is the token for 'GO TO'; 31 and 30
stand for '10' in ASCII; 0E indicates that
a number follows; and the last five bytes
hold the number ten, in integer form
(0A).
ERROR OPERATIONSThe remainder of the routine carries out four operations; it restores ERR_SP to the 'OK' condition, by making it FF; it clears the editing area by using the ROM routine SET_MIN at 16B0; it makes a nine byte space in the editing area by using another ROM routine, MAKE_ROOM, at 1655; and finally, it loads the nine |
prepared bytes, which make up the
command, into the editing area and then
jumps back to the ROM at 12E2, to execute.
You'll also need to enter the two short routines - to alter the Interrupt mode and then to change it back again. Just for laughs (and for convenience) I've put them into two UDG positions, so you can call them with the commands, USR USR "M" and USR USR "N". The 'Return to IM1' routine is needed if ever you want to be able to list your Basic program. But, of course, if you are very security conscious, you don't have to tell anyone what key entry will give you RANDOMIZE USR USR "N"! | |||||||||||||||||
| |||||||||||||||||||
| Home | Contents | KwikPik |