Simon N Goodwin

SIMON N GOODWIN reports on three +3 Pascal Compilers, the 007 Disassembler, returns to the topics of the Tech Tape, ZipZap, and Multiface RAM upgrades, and exposes yet more ROM bugs!


+3 owners have a wide choice of alternative programming languages, which I intend to survey in future columns. This month I compare three impressive implementations of the Pascal Language.

Pascal was invented in 1970 by Niklaus Wirth, an outspoken Swiss professor. It is designed to be efficient and expressive, while forcing the programmer to think out a clear design before coding starts. This makes it popular with academics and methodical people, and hated by hackers who like to make things up as they go along. You can learn a lot by writing large programs in Pascal; it’s more of a science and less of an art than, say, BASIC or C.

I looked at two compilers from Spectrum stalwarts HiSoft — Pascal +3, which runs on a standard +3, and Pascal 80, which runs under +3 CP/M. The third package is ProPascal, from Prospero Software, which runs on all Amstrad CP/M systems, including the latest Spectrum.

These are powerful compilers, rather than the cut-down subsets that often appear on micros. They support PEEK, POKE, IN and OUT, CASE... ELSE/OTHERWISE, 16-bit integers, 32-bit single precision floating-point, CHARs, BOOLEANs, VAR and value parameters, arrays, records (including variants), files (including random access), sets, hex constants, pointers, enumerated and subrange types — plus all the standard Pascal commands and functions, of course.

The table summarises the differences between the compilers. Both HiSoft packages have an integrated editor so you can swap back and forth quickly between compiling and editing. They also work much faster than ProPascal — mainly because the HiSoft compiler is a one-pass 20K program, whereas Prospero’s compiler scans three times through the source, using a total of 102K of code in three programs, plus another 16K for the linker!

You really need a second disk drive to run ProPascal, although I did manage to run tests, rather laboriously, using an unexpanded +3. If you’re planning a very big program, ProPascal might turn out to be almost as fast as the HiSoft compilers, because you can compile files in sections and need only recompile the parts you’ve changed, before linking old and new parts with the linker.

Compilation controls are much the same for all three compilers: you can turn break, overflow and subscript checks on or off, control listings, and include other source files. Prospero have a couple of extra options — one rejects everything except strict standard Pascal, while the other tries to produce condensed code, trading speed for size and typically reducing file sizes by about 10%.

The manuals were clear and comprehensive: the ProPascal one was easiest to read, while the HiSoft manuals were the best looking. The HiSoft compilers came with laser-printed loose-leaf A5 manuals in ring binders. The ProPascal manual was spiral bound and daisywheel printed on expensive paper — it included an index and tutorial, both notably absent from the HiSoft manuals. HiSoft make up for this, to some extent, with five and seven page contents lists, and suggest that you buy a separate tutorial if you’re new to Pascal.

All the +3 compilers can handle programs larger than the maximum size for one file. The first file you compile with HiSoft’s compilers can ‘get’ text from other files. ProPascal goes even further, by allowing that file to call up text in another, and the other to call upon a fourth file, if necessary.

ProPascal includes commands to rename, append, erase and check filenames inside your program. You can’t do this in Pascal +3, but Pascal 80 includes a general purpose routine that lets you call CP/M functions from inside a Pascal program. All three let you ‘chain’ execution from one compiled program to another.

There was little to choose between the speed and size of generated code — all the compilers did a good job of writing Z80 code. They were rather vague about errors, as Pascal compilers tend to be — sometimes they produced rather a lot of spurious error messages after one silly error in a file. HiSoft give you the option to swap back to the editor and fix the problem as soon as one error is found.


These are all good Pascal compilers, with inevitable trade-offs. Pascal +3 is best suited to the +3. but programs compiled with it won’t run on other machines and the editor is rather clumsy, reminiscent of an old-fashioned BASIC editor.

The same editor is used in the £25 cassette version of HiSoft Pascal, for earlier Spectrums. The tape compiler is similar to Pascal +3 but won’t compile such large programs and lacks refinements like file handling and variant records.

If you’ve got CP/M Plus you can use the much better ED80 editor supplied with Pascal 80 and other HiSoftCP/M languages, at £29.95 separately. ED80 is easy to configure and use, and does everything a good program editor should. It handles large files very quickly, although scrolling is rather slow and un-formatted disks can make it crash. HiSoft also include three useful new CP/M utility commands that improve on PIP, ERASE and DIR.

Pascal 80 programs are portable to other machines, notably MSX, Tatung Einstein, and Amstrad CPC and PCW systems, but you lose access to Spectrum graphics and sound.

ProPascal is the most expensive compiler, at £57.50, but the most comprehensive. Formerly Amstrad ProPascal sold for £300, and it was used to write the entire ProPascal and ProFortran system. ProPascal implements the full ISO standard, without quirks, and has lots of well thought-out extensions — nine digit 32-bit integers, 16 digit ‘double precision’ maths, strings with dynamic lengths up to 255 characters, and error trapping.

The snags are the lack of an editor and the need for a second disk drive. The first problem is minor; any ASCII editor will do. The second may be more crucial. I’d be very interested to hear from anyone who’s connected a standard 3.5 or 5.25 inch drive to the port on the back of the +3.

PRODUCT NAMEPascal +3Pascal 80ProPascal
MANUAL SIZE92111182 (A5 pages)
MAX SOURCE FILE SIZE32K52KDepends on your editor
MAX SET SIZE2562562039
  • Turtle graphics
  • BEEP
  • 51 column display
  • Inline code
  • Integrated editor
  • Disassembler
  • Full screen editor
  • CP/M utility commands
  • Inline code
  • Disassembler
  • Integrated editor
  • Generalised CP/M call
  • String operators
  • PROC & FN parameters
  • Error traps
  • 32-bit & 16 digit maths
  • ISO standard
  • Extra file commands
  • Linker, Xref & librarian utilities
  • Crude editor
  • No editor supplied
  • Need drive B


About 800 Tech Tapes have been sold in the last couple of months, so I’m rather disappointed not to have been sent any hacks or enhancements yet. Anyhow, here are a few things I’ve discovered...

The ‘error trapper’ on the tape detects ZX BASIC errors including Break, but you need a BASIC routine to handle the error. The Zip 2 compiler has its own Break scan, which checks 50 times a second to see if SHIFT ENTER is pressed when compiling or running compiled code. These keys stop the program at once and return you to command level — very convenient when you’re developing programs, but annoying if you want to produce a crash-proof final version.

Another problem is that the scan used the Spectrum Mode 2 interrupt, so you can’t use Zip code at the same time as any utility — such as a sprite package — which uses that interrupt.

Both restrictions can be removed with a couple of POKEs. The Break scan is turned on in two places — at the start of the compiler itself, and in a routine normally copied to the start of each compiled program. If you type POKE 54301, 75, programs compiled from that point onwards will not turn on the Break scan. POKE 54301, 71 to restore normality.

If you use this POKE you can still Break into compiled code after compilation, because the compiler will turn on the Break scan as soon as you start to compile any program. The program is not Break-proof until you reset the computer and load the compiled code on its own, without calling the compiler.

To turn off Break checks when compiling, type POKE 33336. 75 immediately after loading Zip 2, and before you compile your first program. This means you won’t be able to interrupt compilation once it’s started, but that’s not a big restriction as Zip 2 works very quickly. Break checking will still be turned on when you run any compiled program, unless you also used POKE 54301, 75 before compiling it.

A few people have run into problems using the Tech Tape code in high memory areas. A bug in the +2 and +3 means that you should not load code into the top 220 bytes of memory, or the NEW or LOAD commands will corrupt it.

The bug is discussed in more detail later in this month’s column, but if you’ve run into problems loading Tech Tape code to the default address at the top of memory there’s a simple cure that requires no technical knowledge — Just type CLEAR 65315 before loading and running the Tech Tape loaders, so that they avoid using the very top part of memory.


Simon Owen has written in with a tip for Multiface owners who have been unable to make their interface work with RAM in place of the normal ROM. In the December issue I printed Paul Cook’s tip which explained how you could customise ZX BASIC by copying it into Multiface RAM, after adding an extra chip to the Multiface. Since then several readers have reported problems — but Simon Owen has the answers.

The newer Multifaces have an internal switching facility which is intended to make them invisible to commercial software. Unfortunately this also makes it impossible to switch on the Multiface memory with a command like IN 159, which Paul used. The Multiface won’t listen until someone presses the button on top.

The button also diverts the processor from running the current program, into the Multiface ROM. Unfortunately Paul’s other bright idea was to unplug that ROM and replace it with RAM. The RAM contains random values — because nothing has had a chance to write it! The processor crashes when it tries to run the ROM routine and finds RAM instead. It seems we’re stuck.

Simon’s technique seems rather odd, but logical. He has tested it on the old Spectrum 128 and the +2. It should work with the older Spectrum+ as well, but I haven’t got one to try it on — my six-year old Issue 1 48K machine (complete with ‘dead cockroach’ modification) has no reset button, and that turns out to be vital. Connect your Multilace in the usual way, then turn on the power. Reset the computer in the normal way. Then HOLD IN the Reset button on the side of the computer, and wait half a second. Still holding the Reset button down, press the ‘magic button’ on the Multiface. and hold both down for another half second. Then release the computer Reset button, wait half a second, and finally release the Multiface button. This sounds more difficult than it is — the timings aren’t critical, just the sequence.

You end up with the machine reset in 48K mode, with 128K memory (if fitted) and the Multiface still available. The next step is to copy the ROM into the 16K of RAM you’ve fitted in the Multiface, as explained in December.

But Simon has also discovered three POKEs that fix bugs in the copy of the ROM. It turns out that the standard Spectrum ROM contain two routines which write to the ROM area — and these corrupt BASIC if it is held in RAM.

Writing to ROM has no effect; it appears to be a bug that one of the routines overwrites ROM, harmlessly, but the other deliberately uses ROM as a convenient place to put a value it doesn’t need.

At address 3372 in ZX BASIC the editor is told to scroll 24 lines of the display. In fact there’s no point scrolling the top line up, because it disappears — but in fact the program still copies that line into the previous area of memory — the ROM character set. You must type POKE 3372, 23 immediately after copying the ROM into Multiface RAM, or some characters will not display properly later.

Later in the ROM, a routine for skipping over values in a table uses STK-CONST to discard each value. STK-CONST normally copies the value to the address in register DE, but the codes at 13308 and 13309 tell it to dump it at the start of the ROM, avoiding the need for a separate LOSE-CONST routine.

Simon Owen solved that problem with POKE 13308, 170 and POKE 13309, 4 which together make the routine dump the values in a safe place — on top of an outdated routine that was accidentally left in place when Spectrum BASIC was developed from the ZX-81 BASIC. Simon wins this month’s £40 software prize.


Once you’ve fixed the ROM bugs, you can speed up cassette loading by subtracting 8 or 14 from the value at address 1487. To SAVE files at matching speeds you must subtract either 12 or 21 from the values in four places — 1272, 1305, 1311, 1326. In each case I’ve given two adjustment factors — one gives a 20 per cent speedup, the other gives 50 per cent — 2,250 baud.

I’ve worked out that POKE 109, 40 should bring the ‘magic button’ under the control of your own software. It brings the ‘unused’ system variable NMIADD at 23728 and 23729 to life, correcting a ROM bug so you can intercept Non Maskable Interrupt signals (magic buttons, in TECH-speak!). You POKE the address of your own machine code ‘magic’ routine into NMIADD.

POKE 2611,24 fixes the ‘cursor left’ movement bug, first mentioned on page 190 of ‘Understanding Your Spectrum’ by lan Logan. Odd things happen if you try to move left — with CHRS 8 — from AT 0,0!

POKE 9597, 201 eradicates the obscure SCREEN$ bug. Without this POKE calls to SCREEN$ produce two temporary results when they should only produce one. This leads to problems if you use SCREEN$ in expressions, like this:

PRINT AT 0,0;"*";"!" + SCREEN$ (0,0)

You’d expect this to print the asterisk, then the exclamation mark and another asterisk, read from screen memory by the function. In fact, you get three asterisks, because the second result from SCREENS gets in the way of the "!". Weird, eh?

An error of one part in four billion in mathematical calculations can be avoided with POKE 12800, 218. This fix to the division routine is well worth it if you like to divide by two in your programs. Believe it or not, a Spectrum thinks 1/2-0.5 is 0.0000000023283064 until you fix this bug!

Machine code enthusiasts can work out lots of other interesting ROM POKEs by looking through a copy of Ian Logan and Prank O’Hara’s ‘Complete Spectrum ROM Disassembly’ — a classic when it came out in 1983, in the halcyon days when no-one worried about ROM bugs because everyone had the same ROM and programmed around the few well-known flaws as a matter of course. Life was simple, before disks, but we enjoyed ourselves...


The +3 is a year old now but fresh bugs are still creeping out of the woodwork. Amstrad are apparently about to produce a new ROM, with corrections for the errors in the COPY routine mentioned in previous issues, and hopefully fixes for other bugs besides.

Some readers have noticed that the +3 seems to gets confused when you enter the SPECTRUM command to switch from +3 BASIC to 48K BASIC. Rather than the expected ‘OK’ message, or a copyright notice, you end up with the obscure text ‘OUT 7,1’ printed at the bottom of the screen. This doesn’t stop 48K BASIC working as normal, but it’s an odd effect and shows how little AMSTRAD tested parts of the +3 ROM.

My spies report that the bug was added just before the ROM was sent off for duplication. The OK message should be generated by this sequence of code at the end of one of the ROMs:

DEFB 255

but Amstrad assumed that the 255 was an ‘empty’ ROM value, as is usually the case, rather than a report code for the RST 8 error routine. Amstrad arrange that the total of all the values in each ROM is exactly divisible by 256; this makes it easy to detect duplication errors.

They can make sure that this works by adjusting the value of one byte, and there’s usually no shortage of unused bytes to tweak. The odd message appears because they changed the report number, thinking it was an unused byte — which shows fairly basic ignorance of the way ZX BASIC works!

One new quirk that actually seems quite useful concerns the way the ‘calculator’ has been bolted on to 128 BASIC. The calculator functions work even when you’re programming in +3 BASIC, so you can type a sum at any time, without a PRINT statement, and the result will be printed on the next line. Try entering 2+2 as a direct command in BASIC to see this effect.

You can use any of the BASIC functions in such calculations, which means that you can enter calls to machine code without having to put RANDOMIZE before the USR call. For instance, USR 24700 will start a Pascal program loaded into a +3, whereas you’d need:

or PRINT USR 24700

on an earlier Spectrum. A command starting with USR works as if it had PRINT in front of it and a semicolon afterwards.

This is a neat trick which saves typing on the slow +3 keyboard, but you must be careful when using it. According to HiSoft star programmer and Spectrum/OL scribe Andy Pennell, the calculator relies on the value of the processor’s IX register being unchanged after the call, and the machine may crash if the code you call alters IX.

The latest problem to come to light is two years old, so it affects the Amstrad + as well as the +3. It’s quite common to use CLEAR to specify the top address available to BASIC, and then load machine code above the address — error trappers, printer routines or whatever.

Unfortunately the code at address 471 in the Amstrad editor ROMs sets to zero the two bytes at addresses 65316 and 65317 whenever you type NEW or load a new program, whatever space you have reserved with CLEAR. This means that NEW can corrupt machine code, character sets and other data stored in ‘protected’ memory.

This bug does NOT crop up on the original black-boxed Sinclair 128K Spectrum, but whatever your computer, you should bear it in mind when writing utilities to be stored in high memory. Unless you avoid those addresses, your code won’t survive a NEW command.


There also seem to be some interesting hardware quirks in the +2 and +3. Apparently the +2 Reset hardware can be unreliable if you’ve got add-ons plugged into the back of the machine. If you press the Reset button briefly it can reset the processor but not the Logic Array that controls memory, so you end up in 48K BASIC rather than faced with the usual +2 menu.

I hear reports that the effective speed of the +3 disk drive varies a lot between individual computers. The data on each ‘track’ of the disk is stored in nine sections, each 512 bytes long. When a file is saved or loaded the disk software waits for each section in sequence.

The disk turns five times a second, so the maximum possible wait is one fifth of a second. The data should be ‘interleaved’ on the disk so that each subsequent section has turned into the right place, ready to be read, as soon as the previous one has been processed.

In practice this timing is cut very fine on the +3, so that variations between the speed of individual drives can make a big difference. A slow drive can pick up sections without waiting, whereas a slightly faster drive that is still within specification might just miss the required section and have to wait for the disk to go through a complete turn before the section it wants comes round again.

The Amstrad CPC 6128 suffered from a similar problem if the drive was misaligned, but it used slightly faster code than +3 DOS so the problem was very rare. The Atari ST has a very similar fault, which you can avoid by formatting disks to use a different sequence of sections.

I’ve only got one +3 to play with, so I’d be interested to know whether or not its speed is typical. I find that the command: SAVE "A:DOS ROM" CODE 0, 16384 takes 18 seconds on my machine, whereas re-loading the same file takes just over ten seconds. Please try this yourself — using a blank disk to ensure that the file is stored efficiently — and let Tech Tips know the speed of your drive. I’ll summarise the results in a future issue.


Nigel Mercier of Omega Software has written in with details of updates to ZipZap, reviewed in the May issue. The new version has a 16-bit decimal to hex converter and a command to enter text directly into the buffer used and when searching the disk. Both of these changes were suggested in my review! Nigel adds, ‘the other drawback you mentioned was the manual which has since been improved, and is being updated regularly.’


Since the early days of Spectrum computing ZX Guaranteed has churned out newsletters and utilities for Sinclair computer users, from their base in Bury, Lancashire. The boss, G A Bobker, has stubbornly refused to follow the rest of the trade up-market or (more commonly) into receivership, and still runs his business like one of the early hobbyist firms. He used to put his home phone number in advertisements, followed by the warning ‘not while Doctor Who is on’!

ZX Guaranteed tapes tend to address markets that other firms would consider too much hassle to support. They have low prices, photocopied paper inserts, and typewritten or dot-matrix manuals, packed with erratic grammar.

Many of the programs are named after 007 Spy, Bobker’s answer to the problem of copying ‘protected’ cassette files to tape or disk. The latest addition to the range is 007 Disassembler, a £5.95 tape that translates a program in memory into machine code mnemonics that can be understood by anyone who reads Z80 assembly language.

Disassemblers are two-a-penny — they’re usually supplied as part of a larger package, and most machine code programming systems come with one. The main problem with disassemblers is that they tend to get in the way of the program they’re examining. Commercial software usually fills almost all of the Spectrum’s memory, so you have trouble loading the disassembler at the same time as the code you want it to examine.

A year or so ago I reviewed a neat solution to this problem — Genie, a disassembler published by Romantic Robot, makers of the Muttiface add-ons. Genie loaded into the extra 8K of RAM built into a Multiface, and could be called up at any time — even if a program was running — by pressing the ‘magic button on the Multiface. Genie used a small eight line window so that it could restore the screen and re-start the original program when you’ve finished.

007 Disassembler is aimed at people who want the same convenience but don’t own a Multiface. It can’t use a magic button, so you have to interrupt the loading of a program — as you would to enter POKEs — before you can use 007 Disassembler to examine the code.

007 Disassembler avoids memory clashes by loading and running from the 6K Spectrum screen memory. The first eight lines of the screen appear blank, but in fact matched ink and paper attributes conceal the 2K of machine code that is 007 Disassembler.

The other 16 lines are used for the disassembly, which — as was once fashionable — makes generous use of colour. When you read machine code it’s useful to spot calls to subroutines and the ‘return’ instructions that mark the end of each routine. The disassembler shows calls in light blue and returns in purple: the rest of the code is printed in the Spectrum default of black or white, with a red border.

This may sound garish but I found it clear and quite useful in practice. Characteristically, Bobker’s two packed A4 pages of documentation include a list of POKE commands that let you change the colours to suit yourself, as well as POKEs to customise the keyboard auto-repeat delay and the character used to mark hexadecimal values.

Three versions of the program are recorded on the tape. One loads into display memory, as explained, while the other two use a full-size screen and load near the top of the Spectrum’s memory map — either at 60000 or 63000. All versions are 2K long and load as CODE files. You call them with a USR instruction-for instance, the version in screen memory can be called with: RANDOMIZE USR 16384

There are just six single-key commands. Addresses and other values can be displayed in conventional decimal notation or in hexadecimal — base 16, convenient when comparing values with their binary equivalent. You can swap between these two options by pressing H or D at any time, which causes the border colour to change and the current screen to be re-displayed in the new base. Re-drawing never takes more than a second.

Type S to enter the start address for disassembly, followed by four or five digits, depending on whether you’re entering hexadecimal or decimal addresses. The display re-draws a screen at a time, with no overlap. N calls for the next 12 or 20 lines, depending on the version, and C copies the display to the printer.

The printout relies on the 48K ROM routine, which only works with dedicated Sinclair printers like the Alphacom 32 or ZX Printer. A simple but tedious BASIC routine to COPY to other printers is printed in the instructions. You can swap back to BASIC at any time with the E key, and re-start with a USR call.

There were two minor bugs in the version of 007 Disassembler that I tested. The code did not check the OVER printing option, so the screen got into a mess if you called it while OVER 1 was set. More importantly, the disassembler was confused by the data byte that follows RST 8 instructions in Spectrum programs — it tried to disassemble the data as an instruction, making the next few lines after each RST 8 potentially misleading.

You must know where machine code has been loaded before a disassembler is useful, so ZX Guaranteed include an extra program, 007 Head, which reads standard Spectrum files (but not headerless files) and tells you their size and where they load. This BASIC program is very simple, but worth having if you have not already got a utility that does the same job.

007 Disassembler costs £5.95 from ZX Guaranteed. It’s simple, but I’ve found it useful.


I was hoping for more space this month but didn’t get it, (stop moaning — Ed) so I’ve still got a large backlog of programs for review — particularly new and converted programs for the +3, most of which I listed in June.

Just squeezed out of this issue was a review of Z80 Toolkit, a comprehensive introduction to Spectrum machine code from Lerm Software. The Toolkit includes an assembler, to convert your programs into machine code, a disassembler, to help you analyse other people’s code, and a monitor to tell you why your program still doesn’t work. It costs just £7.99, and I’ll report in much more detail next month.

Of course, Tech Tips still revolves around your suggestions as well as reviews of commercial programs. If you come up with a new tip that can be squeezed into Tech Tips, please write in and tell the world what you’ve done. There’s a prize of £40 of software of your choice for the best original Tip published every month.

I’m keen to hear from you, and I try to answer common questions in this column, but I can’t reply to letters individually. Don’t fill pages saying how much you deserve special treatment — almost EVERYONE does that, so it’s a waste of your time and mine. Tell me what’s new, and I’ll tell the world you thought of it first!