| ★ APPLICATIONS ★ PROGRAMMATION ★ THE CODE MACHINE ★ |
THE CODE MACHINE (Computing Today) | THE CODE MACHINE (Amstrad Magazine) | THE CODE MACHINE (Popular Computing Weekly) | THE CODE MACHINE (CPC Magazine) |
'Unlock the power of your CPC464' (it says here). Picturesque's assembler/monitor gets used and abused — but comes out on top. Some time ago, I reviewed the Picturesque Assembler/Monitor for the Spectrum, reporting that it was much to my taste — so much so that I adopted it as a personal standard. I was therefore delighted to receive a review copy of "The Code Machine", which is the corresponding set of programs for the AMSTRAD CPC464/664, and I have not been disappointed by what I found. Picturesque are not a large organisation, but their programs have a certain completeness that is sometimes lacking elsewhere. I met the team once, and found them both charming and dedicated, seeking perfection rather than quick profit. Martin Ridout provides the technical content, while Mrs Ridout does the rest, the combination providing thoroughly professional results. But I must justify this praise by getting down to brass tacks. THE PROGRAMS The programs are supplied on tape, one copy of each. They are not protected, in the usual sense, and you are advised to make back-up copies. The cassette case even provides space for the copy! However, it is a matter of extreme simplicity to put the copy on disc. The Assembler/Editor and the Monitor can be coresident (sorry — can be in RAM together. Jargon gets to be a habit...) and intelligible memory maps are supplied to show where they are loaded. This, perhaps, is just as well. For example, the Monitor is loaded as about8K of code, but some 1.4K of this is used for relocation purposes, and when it has done its job the area which it occupes is overwritten by zeroes. That is useful information. The instructions for loading and making copies are more than adequate, the processes being eminently simple. When loading the Monitor, you are invited to specify its position in store, but if you have no ideas on the subj ect a default location is used, putting the program as high as possible in RAM. When the program is loaded, it asks whether you want to make a copy. Copying to disk is then entirely automatic, while copying to tape involves only the usual prompts and key depressions. Loading the Assembler is much the same, but the optimum location high in store is selected automatically. The copies differ from the original in that they do not invite the creation of futher copies, which is reasonable. Norarethe copies relocatable, but you can always go back to the original if you want to put the routines in different positions. THE MONITOR The Monitor offers an imposing range of options, as shown in Table 1. Entry to a given option is obtained by pressing a single key though in some cases qualifying data has to be added. A facility for displaying and modifying RAM contents is common enough, but is rarely offered with variants for hexadecimal or ASCII display and input. Block insertion and deletion are less common, but can be useful if you like patching programs. Memory dump and disassembly are more or less mandatory, but most CPC464 versions will not look at ROM. This version does. Conversion in either direction between decimal and hexadecimal is provided.
The breakpoint system, allowing you to run a specified part of a program, and then stop, is backed by a comprehensive ' register display, which shows the contents of all 13 registers, including the alternatives, with the flag states in F and F displayed in binary for clarity. If you want more detail, you can run in Trace Mode, which single-steps through a program, providing an extended register display after each instruction is executed. This includes the top five words on the stack, the locations to which BC, DE and HL point and the four following locations, ROM state, interrupt state, and a sequence of nine specified memory location contents. You can really see what is going on. No less valuable is the precise tabulation of the ways in which the Monitor program modifies the normal operating system action. This is evidence of careful thought planning. Any moans? Well, I would always like to see a disassembler display a blank line after an absolute jump or return, to mark the end of a code block. This makes the listing so much easier to follow. A personal fad, perhaps, but one that has persisted. Otherwise, no complaints. I may not have tested all the possible combinations of commands and data, but nothing has emerged from the woodwork so far, and I would be surprised by any serious bugs. Incidentally, the monitor refuses to disassemble itself, which is understandable. THE EDITOR The Assembler and Editor are combined in AMMAS. I must admit that the Editor took a little time to become friendly, because it has so many options (Table 2). Each line must be numbered, but there are AUTO and RENUMBER facilities for that, and the numbering has advantages. Each command requires the use of the CTRL key with a character key, though qualifiers may need only one key.
There is automatic tabulation from one format field to the next, which debars use of the Editor for normal text, but makes the entry of source code very simple, This leads to a slight snag, in that use of the 'copy cursor' facility does not always act as expected, the copy having only a single space where the original has several, the extra spaces having been produced by automatic tabulation. However, there is a separate copy routine available which does not suffer this problem. The format, by the way, allows for four-figure line numbers (up to 9999), six-character labels, four characters for the main instruction mnemonic, and at least 26 characters for the rest. You can work in Mode 1 or Mode 2, and the mode can be changed in midstream if you wish, the instruction also allowing screen colours to be changed. NEW clears out the source code, but partial clearance, retaining labels, is also possible. SAVE AND LOAD You can save Source Code, object code in binary, or — with discs only — object code as a CP/M 'COM' file. Another disc feature comes into play if you save a file with a name that matches that of a file already on the disc, You are given the option to overwrite the earlier file, turn it into a back-up file, or abort the operation. Thiscanbe very useful, especially if disc space is running short. If you are using a particular file name a lot, you can define it asakeystring, sothatitis always available at the touch of a key. Loading is automatic, in that the file type determines the way in which the data is used. You can load into a cleared source file, with labels preserved if you wish, or append further text to existing source code. Verify, missing in BASIC, is implemented here. Finally, external commands are accessible. The commands EFLA REN and DIR are usable in simpler way than AMSDOS requires, and there are some extra external commands, such as MON to enter the Monitor, and so on. THE ASSEMBLER As was said not long ago regarding MAXAM, an assembler is an assembler is an assembler. . . However, there are possible minor variations. One difference in the present case is that the 'unofficial' Z80 instructions are covered, all 98 of them. These are hidden instructions which were revealed by D. S. Peckett back in February 1981 (in CT, of course!) but never formally acknowledged by Zilog. The Assembler handles these instructions, saving the need to enter them as explicit bytes, but the disassembler gives the HL forms, rather than the IX, IY forms. The usual directives are implemented, but in a less familiar class is DEFL, which can be used to redefine a label, so that it can have different values in different parts of the program. PRNT allows control of output to screen or printer, allowing only part of the assembler output to be displayed or printed. Nothing has yet been said about possible program size. The source code is stored at the top of free space, running downwards, and the object file grows upwards from the bottom of free space. It is therefore difficult to be precise, since the ratio of one to the other is not fixed. The Code Machine manual suggests that 6000 lines of source code might produce 10K of object code, but that would probably be a lot too much for the available space. No matter, the system will set up the source code as a nuber of sections, and these can be read in and assembled in turn, minimising the total space required. Up to 26 sections canbe used, each with 750-1000 lines of source code, so the overall file could run to 20,000 - 26,000 lines, enough to generate some 32K of object code. That should be enough for most purposes. It is also possible to save the source code as itis produced, in 2K blocks — and you could save on tape with the source code coming from disc, or vice versa. COMMENT These programs conjure up a vision of someone sitting at the keyboard for hours on end, finding our what further facilities might be needed, and putting in each facility in turn. If the result is in any way less than satisfactory, the very range of facilities ccan be bewildering at first, depite the clearly-written manual, which runs to nearly 70 A5 size pages. When the controls become more familiar, this problem tends to fade away. When so many half-baked programs are floating around, it is a special pleasure to find offerings like this, handcrafted and polished until they shine. Bill Horne, Computing Today |
|  |
