REVIEWS COURTESY OF ZXSR

HiSoft Devpac
HiSoft
1983
Crash Issue 50, Mar 1988   page(s) 62,63

(Simon N Goodwin owns the copyright to this review. Please visit http://simon.mooli.org.uk to find original articles and updates, much new material and his contact details.)

SOFT BUT STRONG

Power to the programmer from software tools

OLD-TIME QUALITY FROM +3 DEVPAC

Hisoft's DevPac is a golden oldie. It was arguably the first 'serious' machine-code assembler for the Spectrum when first released in 1982; since then it has been revised several times, and has outlasted all competitors. And as far as I know it's the only Spectrum assembler still being marketed and developed.

It may be that most assembler programmers have graduated to other machines. Spectrum Z80 machine code is tricky stuff, with lots of restrictions and inconsistencies, especially when you compare it with the machine code of the 68000 processors in more recent machines.

But Spectrum programmers who want speed must still write in Z80 code, and they should have quality utilities.

DevPac is a pair of programs: GENS and MONS.

GENS is an editor/assembler - it lets you type in machine code programs in mnemonic (shorthand English) form, and then converts the text into binary code that the processor can understand.

MONS, the monitor/debugger, lets you test machine code interactively.

DevPac 5.1 is supplied on one 3-inch disk, like HiSoft BASIC it's easy to make a backup copy on another disk, as all the files will fit on the RAM disk.

Version 4.1, for earlier Spectrums, is much the same as 5.1 but works with microdrive or cassette rather than disk, and ignores the extra RAM of a Spectrum 128K.

DevPac does not come with any example files; the manual includes a worked example illustrating the use of GENS, but no example explaining MONS.

PAINLESS EDITOR

GENS, the program-generator, lets you type in up to 30K of program text in one lump on any Spectrum. This is enough for between 2K and 5K of machine code, though you can compile larger programs from disk, as explained later.

There's no fixed relationship between the size of an assembler program in text form and the corresponding machine code. The ratio depends on your programming style, and whether or not you include comments so you can understand what you've written when you come back to it after a few months.

Editing is fairly painless if you're used to line editors in the style of CP/M's ED or Microsoft BASIC's EDIT. Lines are stored in numeric order, and can be edited individually by moving a cursor back and forth along the line in a variety of modes. This is no substitute for a screen editor, but it's not too hard to get used to and doesn't need much code, leaving extra space for text.

The display can use standard 32-column text or a compact but readable 51 characters per line. Assembler programs are written in five columns - line number, label, instruction, operand and comment - so I prefer the 51-column display even though it's a bit slow, taking about four seconds to redraw the whole screen. Groups of spaces are compressed into a single byte when a line is stored, saving memory.

The cursor keys have rather arbitrary effects - the right arrow is a tab key to skip between columns, but the left arrow throws away the entire line. The up and down arrows don't appear to have any effect at all!

The editor includes a full set of multiline commands, including automatic line-number generation, renumbering, searching for text - you can replace it with something else - block printing, deleting, saving and loading. Files can be stored and catalogued on disk, tape and RAM disk.

SLOW ASSEMBLER

GENS can translate your completed program into code at about 50 lines a second, if the program text is already loaded. That may seem rather slow, but it won't bother you if you only assemble a few hundred lines at a time.

If you want to assemble a big program you must split the text into several files and tell GENS to read the text from disk rather than from RAM. This slows things down even more, especially as GENS has to read the entire text twice. Version 5.1 assembles about 309 lines a second when reading text from RAM disk, and 20 lines a second from floppy.

If you're really prolific you can spread a program over two drives and the RAM disk, so there's virtually no limit on the size of program you can assemble if you're willing to wait a 16K program could take about 7 minutes.

The assembler has some professional facilities. You can use macros with parameters: in other words, you define new symbolic commands that stand for a group of instructions of your choice, saving typing and text space. Whenever you write a macro name GENS inserts the whole group of instructions, plugging parameters in as required.

You can also imbed calculations and conditions in the code, so that a change at the start can turn any part of the code on or off. This feature, known as 'conditional assembly', is useful if you want to maintain one file of code for several slightly different systems or need to switch features on and off easily

LIMITATIONS, FRUSTRATIONS

Unfortunately, you can't refer to other macros inside macro definitions, or put conditions within conditions. These are serious limitations, because they make it hard to take a consistent, structured approach to your work.

It's also very frustrating that GENS ignores characters after the first six when comparing names in your program, and insists that you TYPE INSTRU IN CAPITA LETTER (type instructions in capital letters). Ugh!

GENS produces a detailed listing when assembling, with page headings and code values. The actual code can be stored in RAM or a file. GENS may issue error messages during each of two passes from the beginning to the end of your program; but I'd prefer to have all the reports at one time, in order.

Errors are reported by number, rather than explained in English. This is frustrating at that, but at least it leaves extra space for your program.

TESTING PROGRAMS WITH MONS

You use MONS when you've written your program and want to test it. Assembly language gives you a great deal of freedom of expression, so it's easy to end up with a program that assembles perfectly but won't work as expected.

The Spectrum can execute almost a million machine-code instructions in a second. Inappropriate instructions usually crash the machine, and you must then reset and reload all the memory before trying again. It can be very hard to track down the errors in machine code, and that's where MONS comes in useful.

MONS stands for 'monitor' - it lets you analyse machine code and step through it at your own pace, checking the effect of each instruction. MONS shows you the contents of memory and registers (stores inside the processor) so you can tell exactly what's going on at any time.

The program lets you search, move and edit memory, in the form of text or numbers. Numeric RAM contents are always shown in base 16, known as 'hexadecimal' or 'hex'. This means numbers appear as a mixture of digits and letters A to F! You can enter values in decimal or hex.

HiSoft's Andy Pennell defends the fixed hex output, saying 'it's a common bug in humans, not having the right number of fingers...'

The +3 can handle two 'screens' internally, and MONS switches between them so that the monitor doesn't mess up your program display. This works well, though it would be nice to be sable to turn the switching off - it sometimes causes a lot of flicker.

MONS will disassemble code properly, translating the code into a program text file that you can reload into GENS (the file will have labels but no comments). This is useful if you want to edit someone else's routines.

MONS always uses a standard 32-column screen. Other Spectrum packages have managed to work with more columns, and some users are accustomed to more information when debugging a Spectrum program. The MONS front panel looks cramped, but it works.

The monitor lets you step through programs line by line, or skip routines, or run quickly up to a certain 'breakpoint' when the monitor screen reappears.

Version 5.1 of MONS fits in the +3's extra RAM, using only 160 bytes in the normal 48K program area. It lets you switch through all the Plus Two memory configurations, so you can examine all the memory of the system, but you can't select 64K RAM modes - because MONS uses routines in the Spectrum ROM.

HiSoft says that people who want to use the 64K modes, designed for the CP/M operating system, will have to wait till Locomotive Software puts CP/M on the +3 (See CP/M & BASIC in A +3 Pack in this section) - then you'll be able to run the 64K CP/M version of DevPac. You'd do well to look at other CP/M assemblers at the same time.

DEVPAC - THE VERDICT

DevPac is a well-thought-out package, but it's showing its age.

To be fair, the only Spectrum package I've seen that is clearly more powerful is the 128K version of Laser Genius, originally from Oasis but now unobtainable.

Even so, there's room for a Spectrum assembler that's simpler and more friendly than either.

But DevPac seems to have the market to itself at the moment. And DevPac 5.1 has all the features you need to develop large machine-code programs, though assembly can be rather slow and structured programming is not encouraged.

HiSoft's address is The Old School, Greenfield, Bedford MK45 5DE.


REVIEW BY: Simon N Goodwin

Transcript by Chris Bourne

All information in this page is provided by ZXSR instead of ZXDB