TECH TIPS #31 - CRASH JULY 1988Simon N Goodwin
reports on three Plus Three Pascal compilers and the 007
Disassembler, returns to the topics of the Tech Tape, ZipZap, and
Multiface RAM upgrades, and exposes yet more ROM bugs!
THREE PASCAL COMPILERS
Plus Three 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
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 Plus Three, and Pascal80, which
runs under CP/M on a Plus Three. The third package is ProPascal,
from Prospero Software, which runs on all Amstrad CP/M systems.
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
Plus Three. 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
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 per
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 looseleaf 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 5 and 7 page contents lists, and
suggest that you buy a separate tutorial if you're new to
All the Plus Three 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
Pascal80 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
These are all good Pascal compilers, with inevitable trade-offs.
Pascal+3 is best suited to the Plus Three, 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 Pascal80 and other HiSoft CP/M languages, or
£29.95 separately. ED80 is easy to configure and use, but
does everything a good program editor should. It handle 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.
Pascal80 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. Before 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, as 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 Plus Three.
TECH TAPE TWEAKS
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 uses 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 Plus Two and Plus
Three 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 of Prestatyn 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 in 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 to 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 Plus 2. It should work with the older Spectrum
Plus 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.
Multiface 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
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 8K 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 three places - 1272, 1305, 1311, 1326. In each case I've
given two adjustment factors - one gives a 20 per cent speed-up,
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 Crash-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 Ian
Logan. Odd things happen if you try to move left - with CHR$ 8 -
from AT 0,0! POKE 9597,201 eradicate 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
SCREEN$ 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 Frank 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...
YET MORE AMSTRAD BUGS
The Plus Three 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 Plus Three seems to gets
confused when you enter the SPECTRUM command to switch from Plus
Three BASIC to 48K BASIC. Rather than the expected OK message, or a
copyright notice, you end up with the obscure text 'OUT 7,I'
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 Plus Three 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:
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 always arrange that the total of all the values in
each ROM is exactly divisible by 256; this makes it easy to detect
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 Plus Three 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 Plus Three, whereas you'd
RANDOMIZE USR 24700
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 Plus Three
keyboard, but you must be careful when using it - 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, according to HiSoft star programmer and Spectrum/QL
scribe Andy Pennell.
The latest problem to come to light is two years old, so it affects
the Amstrad Plus Two as well as the Plus Three. 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 if writing utilities to be stored in high memory - unless you
avoid those addresses your code won't survive a NEW command.
Amstrad are not looking after the Spectrum market very well. It's
a pity they don't let Tech Tips test new models before release!
There also seem to be some interesting hardware quirks in the Plus
Two and Plus Three. Apparently the Plus Two 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 Plus Two menu.
I hear reports that the effective speed of the Plus Three 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
In practice this timing is cut very fine on the Plus Three, 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
The Amstrad CPC 6128 suffered from a similar problem if the drive
was misaligned, but it used slightly faster code than Plus Three
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 Plus Three to play with, so I'd be interested to
know whether or not its speed is typical. I find that the
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 (0932 228649) 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 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. A while ago 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
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
Multiface 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 on
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
Three versions of the program are recorded on the tape. One loads
into display memory, as explained, while the other two load 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
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,
007HEAD, 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, 29
Chadderton Drive,Unsworth, Bury, Lancs. BL9 8NL. It's simple but
I've found it useful.
DON'T STOP NOW
I was hoping for more space this month but didn't get it, so I've
still got a large backlog of programs for review - particularly new
and converted programs for the Plus Three, most of which I listed
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 dis-assembler, 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
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! My
Simon N Goodwin,
PO Box 10,
TECH TABLE: SPECTRUM PLUS 3 PASCAL COMPILERS COMPARED
Product name Pascal +3 Pascal 80 ProPascal
Publisher HiSoft HiSoft Prospero
0525 718181 0525 718181 01 741 8531
Operating system +3DOS CP/M CP/M
Price £34.95 £49.95 £57.50
Manual size 92 111 182
Compilation 1360 1250 560
Min Compilation 4 8 40
Compiler size 22K 20K 102K
Max. object 40K 61K 61K
size (code & data)
Max. source 32K 52K Depends on
file size your editor
Max. identifier 8 8 255
Max. set size 256 256 2039
Other goodies Turtle Full screen String
graphics. editor. operators.
PLOT & DRAW. CP/M utility PROC & FN
BEEP. commands. parameters.
51 column Inline code. Error traps.
display. Disassembler. 32 bit & 16
Inline code. Integrated digit maths.
Integrated editor. ISO standard
editor. Generalised Extra file
Disassembler. CP/M call. commands.
Main snags Crude editor - No editor
Need drive B
Copyright © 1988-2003 Simon Goodwin, all rights reserved.
First published by Newsfield Limited