Machine code monitor comes to your aid
A SOPHISTICATED ROM-based machine code monitor, AID, in common
with other monitors, incorporates:
• A full disassembler
• Memory move and alteration
• String search
• Register display and alteration
• Stack manipulation
However AID offers additional features far in advance of other
monitors.
For instance, AID enables you to interrupt machine code programs
as they run, either at predefined positions or after each instruction.
CLI and VDU commands may be used during such interrupts.
In addition, AID allows you to relocate programs, data or both,
with jump and data addresses being changed accordingly.
One unique facility is its ability to leave the program screen
display unaffected when displaying AID information.
These features, together with the fact that it is ROM based,
make AID a very powerful monitor.
My immediate impression of AID was that it was a very professional
product. Despite the monitor's complexity, after a short familiarisation
period, I found it easy to use, particularly as the User Guide
is very thorough and accurate.
For example, the fitting instructions for the eprom left me
in no doubt where and how to install it.
When I switched on and typed *AID, an aesthetically pleasing
Mode 7 display appeared, much better than the stark black and
white display often associated with machine code monitors.
I quickly went through the usual monitor facilities of hex dumping,
disassembling, memory modification, register changing and string
searching, finding them satisfactory.
I also found AID friendly to use with its two letter commands,
sometimes followed by hex digits, and helpful error messages and
responses.
Next, I decided to experiment with a small machine code program.
I used AID's "single cycle" facility which enabled me
to watch the effect of each machine code instruction on registers
and flags.
Whenever I wanted I was able to look at any area of memory and
still come back to do the next instruction with all the flags
and registers unchanged.
If I desired, these registers, flags and memory locations could
be changed before executing the next instruction.
I wish I had had something like this when I first started dabbling
in machine code!
I then used AID's "break points", which are BRK instructions
inserted in place of an opcode so that the machine code program
is interrupted at a specified point.
Up to 12 such break points can be inserted at any one time.
When the machine code is run, AID handles the break points by
giving the usual display of registers and disassembled code. At
this point it is then possible to interrogate and change memory
and registers as desired before continuing.
In fact, any of AID's commands can be invoked at this stage
as well as VDU and CLI commands. Provided the command does not
cause a reinitialisation, then the program can be resumed from
the break point as if the break point were not there.
The break points can be removed on request and the original
opcode restored.
The next facility I used was relocation of code and data. The
instructions seemed daunting at first, but it was really quite
simple once I realised what was going on.
It is all a question of informing AID what you are going to
move, from where and to where, and whether jump and data addresses
are to be changed. In this latter case, the old and new address
range needs to be quoted.
I was able to relocate ROM based code into RAM by moving it
first and then changing the jump addresses. This enabled these
routines to be scrutinised by single cycling or by introducing
breakpoints.
The last facet I explored was the dual screen facility, which
is perhaps the pearl of the system.
To test this facility I loaded a machine code program that plotted
direct to a Mode 5 screen. I then initialised the dual screen
facility so that the AID screen did not interfere with my Mode
5 program screen.
I also introduced a few break points so the monitor would interrupt
my program.
When I ran it, it started drawing on the program screen, then
the AID screen appeared as a break point was reached. I then typed
the command for viewing the program screen, and there it was —
still in one piece!
I was able to switch between program screen and AID screen at
will and use VDU commands from the AID screen that affected only
the program screen. When I allowed my program to continue, it
did so as if no interruption had occurred.
Later I loaded a program consisting of Basic and machine code
that plotted on a Mode 5 screen — and which I knew to have a bug
in it.
I was able to run the program in its entirety, using AID to
keep an eye on the machine code sections and I successfully found
the bug.
If I had been debugging the program without using the dual screen
facility I could not have run the program
properly, due to the program screen being corrupted each time
I investigated memory or registers.
This would have meant a much longer process of testing each
section separately and then checking the correctness of parameters
passed between sections.
Having read this far you must be thinking: "AID can do
anything!"
Unfortunately this is not quite true. For instance, AID will
not output to a printer so there is no hard copy of disassembled
code.
AID requires 1.5k of user RAM when the dual screen option is
in use. This can pose a problem but, since it can be located anywhere
between &E00 and the bottom of program screen memory, there
is usually room for it somewhere.
A problem can arise if a DFS is fitted, as this occupies an
area of RAM from &E00 to &1900 - this is for an Acorn
DFS - as the default setting for the dual screen is &E00.
An attempt to use the DFS after initialising the dual screen
may cause the system to hang up.
However I was able to successfully use discs by ensuring the
dual screen memory was above &1900 and that the disc system
had been reinitialised by typing *DISC.
AID also uses the RS423 buffers as workspace and variable storage.
Consequently the RS423 port cannot be used with AID.
Something that I miss in the AID screen display is the value
of the interrupt vector which most monitors show.
Similarly the hex dump format allows only four bytes to be displayed
per row
instead of the usual eight, though this gives an easier to read
dump that includes an Ascii character dump.
I did encounter a few problems when using AID but these were
largely due to unfamiliarity with the system.
For instance, I found that calling AID by typing *AID when I
was already in AID caused the way back to Basic to be lost. Basic
could only be recovered by *BASIC or control break.
Similarly, pressing break while in AID caused AID to warm start
as a language ROM even if it was being used as a service ROM.
Basic is abandoned when AID is used as a language so that *BASIC
or control break is the only way back to Basic. When used as a
service ROM, control can be passed back to Basic from where AID
was called.
A related problem resulted when I was debugging my program that
called machine code from Basic. I placed break points in the machine
code expecting AID to handle them when I ran the program.
Instead, the break points caused weird error messages because
Basic was in control and had no means of handling the breaks.
The correct way to allow AID to control the machine code called
from Basic is to call AID instead and tell it where the code is
located.
In conclusion, AID seems a must for the serious machine code
programmer and a very useful learning aid for the novice. It is
a highly professional product in every way and could prove to
be the standard by which others are compared. It costs £28.
Part of a typical
AID screen display
Eric H. Crisp
