Devpac was the first full blooded assembler for the emergent Arnold. Devpac 80 took advantage of CP/M, and now it has been improved further. Cliff Lawson looks at Devpac 80 — version 2. A couple of months ago Pete Green looked at the new assembler program development system from Arnor -Maxam II. His general conclusion was enthusiastic, but it has to be said that £80 is a lot of money even for the most dedicated hobbyist. I found the package lacked a couple of essential features for "large" program development: For small utilities it is extremely good, but lacking the ability to generate relocatable object modules is a serious drawback. No fixed a-code As the production of relocatable modules is one of the major new features of Devpac 2, perhaps a few words on their significance would not come amiss. For the uninitiated, it is unusual for programmers to write reasonably large programs as just one huge source file. Instead, such programs are usually written in smaller modules. There are two ways to go about this. The first is to tie all the separate sections together at assembly time using an assembler command such as INCLUDE. One main assembler file would contain just a few assembler statements such as . . . INCLUDE INITCODE.ASM
INCLUDE MAINLOOP.ASM
INCLUDE MOVEBASE.ASM
INCLUDE ZAPTHEBA.ASM
INCLUDE EXPLOSON.ASMWhen you assemble this main file, each module is assembled in turn and the code it generates is added to build one big file. This technique is all very well if each module can be assembled and tested separately. But if each relies on functions in another module, you would have to assemble all the files each time one was changed. You would probably get to the point of tearing your hair out long before the point at which it was taking even 15 minutes for each assembly.The missing link The second, far neater, solution is to get the assembler to generate relocatable object modules (known in the trade as .REL files). As changes are made to a single module, it alone needing be reassembled. The resulting .REL module can then be combined with the other modules, prepared earlier in true Blue Peter fashion. This requires a tool known as a linkage editor. All Amstrad CP/M Plus machines are provided with a suitable tool, LINK.COM which is actually designed to be used with the free 8080 assembler. Almost all other "serious" assemblers and language compilers have .REL files as their output so it is easy to combine assembler subroutines with higher level languages. While the new Devpac is designed to run on all CP/M machines - including the CPC 464 - it is difficult to see how anyone without CP/M Plus could make use of the relocatable nature of the assembler when they are missing LINK. Devpac 2 from HiSoft consists of three major parts: - An editor with which you can construct Z80 assembler source files.
- An assembler that takes such a source file and either generates a directly executable CP/M program (a COM file) or produces linkable object modules (which are subsequently LINKed to produce .COM files)
- A "front panel" debugger that lets you see what is happening to the processor / memory as your newly produced program is run.
In fact there are two versions: A totally new version, ProMON, as well as the older MON80. The older version is present for people who might be familiar with it and also because its smaller size might be important when debugging a very large program.
All these can be tied together using a very simple menu system known as HDE which allows you to identify a main file and skip between edit, assemble and debug. I found it easy to work in the way I'm used to, operating editor, assembler and debugger separately. Added goodies The supplied disc contains a simple-to-use file copying program, an equally simple file deletion utility and extended directory command. There are also utilities to convert CP/M .COM files to AMSDOS .BIN files by adding a header or AMSDOS to CP/M by removing the header and a program to take assembler source files from GENA31 (the old AMSDOS version of Devpac) converting them to a suitable form for use with the new assembler. There are source files for the major examples given in the manual. Using the various conversion utilities means that the CP/M based package can be used to develop AMSDOS programs, though you will lose the opportunity to use the debugging utilities. The Editor ED80 is the same editor as supplied with the previous version of Devpac80. It is very similar to WordStar operated in non-document mode, with one or two added features, such as the ability to restore a line that has been deleted with Control+Y. Before starting the editor it is a good idea to use SETKEYS KEYS.WP so that the cursor keys return the usual WordStar values. The text being edited is held in memory rather than being paged from the file on disc. This has the advantage of being very fast when going from one end to the other but has the serious limitation that the maximum editable file size is about 55k. When writing in a modular way this wouldn't be too great a problem except that the .PRN for a 50k source file will almost certainly be two or three times the size and therefore uneditable. The Assembler It is difficult when assessing a serious Z80 assembler not to draw comparisons with the industry standard - Microsoft M80. This is used by many major software houses. If Hi Soft want programmers to switch it needs to offer some compatibility. Unfortunately, there are so many of M80 features that GEN80 doesn't support that the attempt cannot be wholly congratulated. For instance, why on earth does it omit the (presumably) easy-to-implement HIGH and LOW expression operators? And including DEFL but not its synonym, ASET, is unnecessarily limiting. Starting conditionals with either IF or COND is all very well, but why must they end in ENDC when most people use ENDIF? Changing the order or precedence in expression evaluation is very questionable as it could lead to some obscure bugs. Of course, anyone who already has M80 probably wouldn't think of using another assembler, so perhaps I'm being super-critical. Microsoft does charge professional type prices. M80 is well over £100 and does not include an editor. Smooth operator So, what does the assembler offer the new user? Well, obviously it accepts all the standard Z80 mnemonics and all the expected psuedo-ops are there -DB, DEFB, DW, DEFW, DS, DEFS, DEFL, EQU, ORG, END, IF, ELSE, ENDC. These are pretty standard to all assemblers so I won't waste space explaining them here. There are added operations involved with the production of relocatable modules. The choice of whether the assembler is used in absolute mode or .REL file mode is made by an assembler switch. In .REL mode the following psuedo-ops are recognised - EXTRN, PUBLIC, ASEG, CSEG, DSEG, .PHASE, DEPHASE. Because symbols/routine labels may be declared in one module and used in another, you need to be able to tell the assembler not to flag an error when an "externally" declared symbol is encountered. The EXTRN operation is used for this and is followed by a list of any symbols that are not declared in the current module. Similarly, so that other modules can "see" symbols declared in the current module, they may be declared PUBLIC. This, as the name suggests, means that they can then be referenced by any other module. It is when the modules are linked that all these cross-references are tied together. This is of course why the operation is called "linking". Putting things in place When generating relocatable code there is no notion of a fixed origin. It is only when the code is linked that definite decisions are made about where it will finally reside. Because of this, the code in each separate module is written as if it started at 0. More than this, the actual program code is generally all lumped together in one area. The code segment and all the variables and data (DEFBs and DEFWs) are from the data segment. To tell assembler which of the two areas the code applies to there are two psuedo-ops, CSEG and DSEG that are hopefully self-explanatory. If you want to generate code that must be linked to reside at a definite address then ASEG (absolute segment) is used. GEN80 does not support common segment code, though this is rarely used so it's not too great a loss. It is quite possible that you will want to write a section of code that starts its life buried deep within one of your modules but at the end of the day will be block moved to 0C000h say before it is executed. Because of this, you will want all jumps and labels to be offset from 0C000h.
This is easy to achieve in GEN80 using .PHASE 0C000h and can be switched back to normal with .DEPHASE. Making the most of macros The assembler supports a simple form of macros with the MACRO and ENDM psuedo-ops - MACROS is not a small greek island, a macro is an often used bit of code that can be blocked together, given a short name and quoted wherever you would have typed all the associated code. The classic example is how to exchange two of the 16 bit registers. Hopefully, it is obvious that pushing the two registers on the stack then popping them off in the other order will achieve this. So, every time you wanted to do this, you could include PUSH rl, PUSH r2, POP rl, POP r2 in your code. However, by including the following macro definition of the file. xchg MACRO @r1, @r2
push @r1
push @r2
pop @r1
pop @r2
ENDMYou could put xchg DE,IX in your source file if you wanted to exchange DE and IX, similarly xchg IY,AF would exchange IY and AF. When the file was assembled, the assemler would just replace the xchg instruction with the two pushes and two pops each time it was used.The Monitor There are in fact two monitors in the package, MON80 and the new ProMON. Rather confusingly they use different keys in operation so most people will probably stick to using just ProMON which contains more powerful and useful facilities. The keys used in ProMON are also the more obvious of the two sets. Like SID, ProMON is a symbolic monitor. This means that when giving a disassembly, if a .SYM file has been loaded all the symbol references are filled in with their names. So, for example, if you have a message printing sub-routine at address 1234, as long as the routine has a name such as PRINT-MESS in the symbol file any CALL 1234 in the disassembly will appear as CALL PRINT-MESS. It is pretty obvious that this makes following your program about 1000 times easier. The monitor shows a disassembly of about 22 lines of code, the contents of all registers (including the alternates) and a memory dump which can also be made to show the areas pointed to by the main register pairs. In command inputs, the same expression evaluator used by the assembler can is valid. So, for example, you could set the memory pointer (which decides which area of memory appears in the memory display) to DE*3+HL .SHR. 4-217. The contents of a register may be used by including the register name in curly brackets. The monitor supports all the commands that one would expect - fill, move or compare blocks, change registers, read a file, write a file, setup the FCB, search memory, disassemble, set breakpoints and execute code. However, these have some interesting options. When searching you not only have the option of searching for hex bytes and Ascii, but you can also search for an assembler mnemonic given in the same form as the disassembler would generate the line. This means you can search memory for "CALL PRINT-MESS" which is very useful. Miscellaneous breakpoints There are several types of breakpoints that can be set. Not only can you set the usual sort of "hard" breakpoint, you can set breaks that require a pre determined condition to be satisfied for execution to stop. Thus you could put a breakpoint at 0114h with the condition DE=37. Each time execution reaches 114, DE is checked and only if it contains 37 does execution actually stop. A watchpoint placed within a critical loop allows a check to be made on how many times it is executed. Profiling your code in this way can help to streamline it. When it comes to executing the codethere are various options. For example, one form is like a simple single step except that it means "go off and run the following CALLed subroutine at full speed then stop when you get back to the next instruction". Another execution option causes a key-scan after the execution of each instruction. This means that even if an endless loop is entered a key can be pressed to get back to the monitor. Perhaps the best feature of the monitor is the execute conditional command. This is similar to the conditional breakpoint mentioned above except that the test is not made at one set point but after each and every instruction. The ring-bound documentation that comes with the package seems to cover everything, though a little more detail could have been afforded to the more complicated aspects such as the philosophy of why one should want to use relocatable code rather than absolute mode. The manual is really four separate ones "editor, assembler, monitor and tutorial i with cards dividing each section. Though not including an overall index and having continuous page numbering strikes me as a mistake. HiSoft was extremely receptive when I asked about a number of "inconsistencies". This will mean a number of important differences between the review copy and one which you buy in a shop. They will all be improvements. Having had the opportunity to use M80. Max am II and now Devpac 80, the best combination would be to use the editor from Maxam II (essentially Protext in program mode), the M80 assembler and the monitor from Devpac. However, if forced to plump for one package I think you couldn't do much better than this new Devpac. True, the editor could be a bit limiting on very large files but you could avoid generating such large files. The assembler is certainly better than Arnor's offering, but still not a patch on M80. The monitor is very competitive and when you consider that you get all three for just £39.95 it really does seem like a bargain. Existing owners of Devpac 80 can upgrade by sending back their old copy with a cheque for £15. | Having had the opportunity to use M80. Maxam II and now Devpac 80, the best combination would be to use the editor from Maxam II (essentially Protext in program mode), the M80 assembler and the monitor from Devpac. However, if forced to plump for one package I think you couldn't do much better than this new Devpac. True, the editor could be a bit limiting on very large files but you could avoid generating such large files. The assembler is certainly better than Arnor's offering, but still not a patch on M80. The monitor is very competitive and when you consider that you get all three for just £39.95 it really does seem like a bargain. Existing owners of Devpac 80 can upgrade by sending back their old copy with a cheque for £15. |
ACU #8708
| 
