Master 512
Forum by Robin Burton
Beebug Vol. 9 No. 10 April 1991
In this month's Forum we'll look at another query which has been raised by several members, another matter which previously has been avoided for reasons mentioned last month.
However, there are other 512 topics which have also been neglected, but for different reasons. I have one or two points to make about future Forum topics, in the hope that you'll make your views known to me in due course.
512 BBCBASIC
Many of you will by now have a copy of this software which, nearly two years ago, I offered free to members who sent a blank formatted disc with return post and packing (in total I've now supplied nearly 400 copies). This particular 'message' therefore applies to the rest of you – that is, those who for one reason or another didn't avail yourselves of the offer before.
Some of you will no doubt have The 512 Technical Guide, published by Dabs Press last September and reviewed recently in BEEBUG by Bernard Hill. Accompanying the book is an optional programs and examples disc containing numerous items which should be of interest to 512 users. One of the items on this disc is a copy of 512BBCBASIC.
I'm therefore giving notice that my offer of a free copy of 512BBCBASIC is finally closed. I've continued to receive occasional requests for it right up to the present, the latest only last week, but it seems to me that the offer, held open for two years, was surely long enough to be considered fair by everyone.
When the original offer was made, the package wasn't generally available from any source – but now it is. From now on, if you want a copy of Richard Russel's excellent BBCBASIC package for the 512 send your request for the 512 Technical Guide examples disc to Dabs Press with the appropriate fee.
VALID TOPICS
That leads me on nicely to another package supplied on the examples disc, the A86/D86 machine code assembler-debugger. Included on the disc are numerous examples of source machine code aimed at helping you to learn how to write your own programs. Clearly writing machine code isn't everyone's idea of having fun with their 512, and that means it's also perhaps not the most obvious subject for the Forum. However, the book and its disc do allow you to have a look at what's involved for a very low cost and apparently a number of you have been doing so. One result of this is that I've received a few more queries.
The reason for mentioning this is not that I think everyone should immediately take up machine code programming. It might widen the range of possible topics for the Forum, but my purpose is to make the point that a certain minimum amount of knowledge about the 512 and its internal workings is needed if you're going to understand the answers to some of your queries.
For those who have wondered why previous suggestions for Forum topics haven't appeared I can only say two things. Firstly space is limited, and secondly, as a consequence, the appeal of items should therefore be as wide as possible. This means that some subjects simply won't be covered unless there's evidence that enough of you are interested. To properly understand this month's main topic, for example, you need at least a basic idea of how the processor works. The technical guide and disc are a source of this information, but the Forum isn't because there isn't enough space.
I've had a few suggestions, virtually ever since the Forum began, that more technical topics should be included, at least some of the time. Previously I have mainly discussed particular but non-technical operational aspects of the system, so this mild 'complaint' is understandable. I hope therefore that the following redresses the balance a little. Naturally if you'd like more of this sort of thing (or less) I need to know, so drop me a line; the majority view will rule.
MYSTERIOUS MESSAGES?
I've had a few requests lately for a bit of information about one display I've never before mentioned in the Forum (but which unfortunately virtually everyone sees from time to time). It's an error in the form shown in figure 1. The questions are, what do all these figures mean and what use is the information?
|
|
Figure 1. Fatal
error message display |
At the simplest level the meaning is obvious. A program instruction has been encountered which the 512 doesn't like for one reason or another, and the program has been abandoned.
The first point to make, perhaps, is that if this sort of display appears when you're running a program for which you have no information except operating instructions there's really not much you can do. However, if you have details about the program's structure and what it's doing, which you will have if you wrote it yourself, this display can often tell you exactly what's wrong and where it happened. Let's look at each part of the display in turn and examine it in a bit more detail.
The first line is straightforward, though there are other error messages I'll mention in a moment. This one shows 'Invalid Opcode' (by far the most common display) which defines the error type. In this case it means an 'illegal' or perhaps a nonsensical instruction code has been encountered.
There are numerous possible reasons for this, but a couple of the more obvious ones are that the program is corrupt, or it might perhaps have been written for a different processor. For example, a program written specifically for a '286 (or '386 or '486) based machine, or for those with a maths co-processor chip, will produce this sort of display very shortly after loading.
Another possibility, especially in your own code during development when errors are virtually unavoidable, is that your program has jumped to an incorrect address or has somehow corrupted its code. It might mean that the program is attempting to execute data as instructions, or perhaps that (originally) valid instructions have been destroyed by being overwritten in memory, both of which might give the above result. To illustrate this article, for example, I produced the sample display simply by copying a text file to a file called 'PROGRAM.COM' and executing it.
The next part of the line, 'Error from' is precoded, and the name of the program causing the trouble of course follows it as the last item on the line.
ERROR TYPES
I'll now try to explain (briefly) all the possible error types in this part of the display without getting too involved, but some of them will necessarily be pretty meaningless unless you've done a lot of serious '86 programming (and made some pretty serious errors). The full range of errors supported by the 512 in DOS Plus is:
Divide Error: means register overflow after a divide instruction. This error is most often caused by division by zero.
Single Step Int Error: means the trap flag was set. This is used by debuggers to trap certain conditions they otherwise could not handle. It's not a 'real' program error.
NMI Error: means a Non-maskable interrupt error has occurred. This is generally a hardware failure and is not recoverable. It is not a program error.
Break Point Error: an interrupt 3 was executed which allows the system to return control to a debugger in single step mode.
Overflow Error: an 'INTO' instruction has been executed, which causes an interrupt 4 if the overflow flag was set.
Range Error: means a 'bounds' instruction has failed.
Invalid Opcode Error: as explained above.
ESC Opcode Exception Error: in the 512 means an unknown or unexpected error condition has been passed from the host.
Register Dump Error: is the result of a deliberate interrupt Off, which causes a register dump.
Unsupported IBM XT ROS call Error: means a call has been made to an IBM PC internal function which isn't supported by the 512.
Unexpected Interrupt Error: is the least helpful of the lot because it covers anything that didn't crash the 512 and which isn't dealt with by one of the preceding messages.
FLAGS AND REGISTERS
The second line of the display, starting with 'Flags', indicates the contents of the processor's status register at the point of failure. In all processors, one register is set aside to record the resulting status from program operations. For example, after a test for zero, the zero flag is set if the condition was met. In our example display, as shown by the letter 'Z' in the middle of the flags, the zero-bit of the status register was set.
The next part of the display, the third and fourth lines, are read together and show the most useful information. You'll need to understand '86 memory addressing to appreciate the information, but if you do, this data tells you exactly where the problem occurred and the contents of the processor registers at the time.
I don't intend reproducing extracts of the technical guide here, so if you want to know how memory is addressed and what the 81086 processor registers are used for I can only direct you to chapter two of the book (it would in any case occupy about 5 complete issues of 512 Forum). Suffice it to say that the figures under CS:IP point to the failed instruction, where CS is the code segment and IP is the instruction pointer. Likewise, the figures under 'SS:SP' show the stack segment and stack pointer at the time, while the remaining parts of the display show the contents of the other registers at the point of failure.
THE PURPOSE
Obviously, given the error type and the code segment address of the failure, you will be able to see immediately if it was within your program. If so, you can tell precisely which instruction caused it.
On the other hand, if the code address is clearly outside your program area you can (usually) deduce quite easily if the instruction was within the operating system, in which case you have probably made an invalid interrupt call or have supplied incorrect parameters to one. If this doesn't seem likely the next thing to check is if the address looks completely meaningless. This usually indicates that corrupted code or data has resulted in an effectively random program jump, which could 'land' almost anywhere in memory. Whatever the case, one way or another the display gives information which helps a programmer to sort out what went wrong and where.
For the less technically inclined, or if you didn't write the program yourself, probably all that you need to know is that DOS Plus is telling you that the program in question isn't going to work and that the system has protected itself (and perhaps you and your data) by trapping the problem and ending the program. So long as you get a normal prompt back after the display you should be able to continue using the 512 without re-booting.
Of course, the 512's error trapping isn't perfect. Sometimes the operating system itself can get into knots, especially when an incorrect segment register value in a program accidentally changes some of DOS's working data or code by executing a mis-directed move or arithmetic instruction.
In this case you might see a non-stop repeated display, like the one above but continuously scrolling up the screen with no way to break in. Shift-Ctrl stops it temporarily, so you can note the figures. Alternatively, you may not get any prompt back after the display, but the other option, which I'm sure you've all seen, is a completely uninformative hang-up with no display at all. In all these cases the only option is to re-boot the system.
NEW IDEAS
Since the Forum started there has been a considerable change in support for Acorn micros. The 8-bit BBC micro continues to take more and more of a 'back-seat' in Acorn publications with the exception of BEEBUG. 512 users are a pretty independent bunch, they have to be, but I'd like to keep the Forum true to its title, so let me know the direction you'd like the Forum to take in the future. Don't just think 'It's been OK so far, I won't bother.' because one day I might run out of ideas. If you've ever thought, "Why doesn't he ... ?" why don't YOU tell me about it.
I've had some ideas for future Forums. One suggestion is a regular spot to investigate the more obscure DOS error messages. Another is a regular 'machine code corner', while another is to publish addresses for those who'd like to hear from other users. What do you think? If these or other ideas appeal write to me (c/o BEEBUG) saying what you'd like to see.