IF you’re frustrated by the limitations of Spectrum BASIC and you’d prefer a larger, more structured set of commands, Betasoft’s BetaBASIC is probably the answer. It’s a massive package, so this is just a brief summary.
BetaBASIC is a £16 extension of ZX BASIC rather than a new interpreter. It adds more than 100 new commands to Sinclair BASIC, and speeds up some of the old ones — such as GOTO, GOSUB and FOR loops. It runs on any Spectrum apart from the +3, though there should be a special version for that machine later this year.
But BetaBASIC is BIG! It consists of 18K of code on a 48K Spectrum, leaving you with about 22K for your program. The extra commands for the Spectrum 128K take up another 7K, leaving you only 15K. The compensation is that often one BetaBASIC command can do what would otherwise have taken dozens of lines. (You can also store up to 70K of array variables and routines in the 128’s instant-access RAM disk.)
The BetaBASIC editor is a fast, improved version of the 48K Spectrum editor, rather than the slow, clumsy screen editor that normally runs in 128 BASIC. You can type commands in full, use an extended version of Sinclair’s keyword-entry scheme, or mix the two — entering the commands you can remember as single-keypress keywords, and typing the others in full. User-defined keys are also allowed.
You can renumber, move, delete or copy any section of a program. There are search and replace facilities, and you can join and split lines easily.
Procedures and functions allowed, with no restrictions on parameter-passing or local variables other than available memory. Block IF THEN ELSE and DO LOOPS are allowed, but there’s no SELECT or CASE statement other than the old-fashioned and error-prone ON GOTO and ON GOSUB.
Array commands let you sort, search and shuttle entire arrays or slices very quickly. There are 30 new functions to convert, combine and format numbers or strings.
BetaBASIC’s graphics commands are faster and more flexible than ZX BASIC’s. Besides using faster versions of the standard commands you can define windows and FILL any shape; graphics operations are particularly fast in the 128K program. Flexible scrolling and new character sizes are supported.
A souped-up BEEP command for 128-users lets you use the full potential of the AY-3-8912 Sound chip. Sounds are queued, so your program carries on running while a tune or sequence of sound effects is played. This is a vast improvement on Sinclair’s weedy PLAY command though it’s a bit harder to use. And PLAY, like all the other Sinclair commands, is still available if you want it.
Since Tech Niche last reported on BetaBASIC, the software has been improved to trap errors generated by the Disciple and Plus D disk systems as well as BREAK and other standard reports.
Software-designer Andy Wright says he’s been encouraged by ‘lots of post’ about the +3, and intends to get down to work on a new version soon. He plans to implement serial data files on the + 3 disk, and ideally random-access files as well, but he can’t think of much else that isn’t already done by BetaBASIC 4.
+3-OWNERS can soup up with Spectrum CP/M and Mallard BASIC, steaming in soon from Locomotive Software. If all goes well, there’ll be a March launch for the £30 disk package including Spectrum CP/M — a version of the original micro operating system — and Mallard BASIC, the ‘business BASIC’ supplied with Amstrad-designed computers.
Mallard BASIC is more like Microsoft’s MBASIC than Sinclair BASIC — it’s typically two or three times faster than ZX BASIC, with comprehensive disk-filing commands, error-trapping, and rare goodies like real-time event-handling. That means you can tell the computer to call a specific subroutine after a certain delay, or every so often, while running another program.
Mallard BASIC leaves around 30K of memory for programs and data. The interpreter and CP/M system fill the rest of the +3’s 128K.
BetaBASIC still has the edge in terms of structured programming and editing commands, though it will be much easier to convert Mallard BASIC programs to run on other computers.
Once CP/M runs on the Spectrum literally hundreds of new languages will be available. Mallard BASIC will still be important, because it’s a good language supplied with every copy of CP/M; I hope to have tested the whole new system in time for next month’s Tech Niche.
AT £29 HiSoft BASIC 1.2 is slightly more expensive than version 1.0, but it boasts disk commands and other improvements. The generated code is no faster, but that’s no surprise — it’s still the fastest integer BASIC compiler on the Spectrum, with ZIP second. And HiSoft BASIC is second only to MCODER 3, a much simpler product, when it comes to floating-point maths.
Both the minor bugs in version 1.0 have been fixed in the new version.
The first enhancement of version 1.2 is an improved VAL function, similar to that of HiSoft’s other compiler, The Colt. Version 1.0, like most Spectrum compilers, only allowed you to take the VAL of a string of digits, whereas the interpreter can work out the value of any expression — even if you include function calls and references to variables in the string.
If a compiled program handled VAL like the interpreter it would need to compile the expression every time VAL was called. This would be horribly slow and clumsy — you’d need the entire compiler loaded, along with the temporary data it generates when allocating space for variables, whenever VAL was going to be used. And as soon as you’d generated the code for each call you’d have to execute it and then throw it away!
HiSoft doesn’t go to that extreme — this compiler calls the Sinclair BASIC interpreter’s VAL routine from compiled programs. VAL is as slow as ever after compilation, but no extra code is needed to work out the value of functions, calculations and variables.
The snag is that variable and user-defined-function names used in VAL refer to the current ZX BASIC program variables not to variables in the compiled program. The new VAL is an improvement over version 1.0 but still a compromise of speed, conciseness and compatibility.
For some reason Amstrad didn’t put any facilities to handle text files in +3 BASIC. You can SAVE and LOAD individual arrays, but you can’t handle files that won’t fit in memory (there’s no such restriction if you’re using microdrives or third-party disk systems such as the Disciple Discovery, Plus D and Swift Disc).
But HiSoft has fixed this +3 limitation in its BASIC compiler. You can OPEN and CLOSE text files, and then read and write them with INPUT, INKEY$ and PRINT. The syntax is simple and standard.
There are limitations — you can’t wind back and forth in a file, though +3 DOS theoretically allows random access, and you can’t detect the end of a file unless you read the data one character at a time with the slow INKEY$ function. INKEY$ returns an empty string when the end of a file is reached. File-handling only works if you run the compiled program on a +3 and load the few hundred extra bytes of code supplied in a file called RUNTIME. Programs that don’t use files will run independently on any version of the Spectrum.
+3 HiSoft BASIC is very easy to me, with a menu of single-key compilation options.
The compiler and menu fit into the parts of the 128K memory which are not normally available to BASIC, leaving 42K of space on drive M and about 40K for your original BASIC and the compiled code. If you’re really pushed for space you can compile the code and DATA separately; this is a fairly painless process on a disk system.
Version 1.2 comes with the same demonstration programs as 1.0, plus two simple but neat BASIC arcade games. The games are limited graphically, as they rely on redefined character graphics, but they’re a good starting point for learning how to write games.
The first game, a Pacman clone, starts life as 6K of slow BASIC and compiles into 9.6K of machine code in 9 seconds. The compiled code draws the maze eight times faster than the ordinary BASIC game, and moves the man and the monster about 6.5 times faster.
The second example, a 7.5K BASIC Frogger game, compiles into 10K of code in just 8 seconds. The speed-up is smaller, as Frogger reprints most of the screen regularly, but it still makes the difference between a slothful game and a playable game.
These results are quite impressive, though you shouldn’t read too much into ratios for a couple of programs. Code that relies on integer arithmetic, rather than relatively slow graphics, can go hundreds of times faster after compilation. But at the opposite extreme trigonometrical calculations are hardly accelerated.
HiSoft BASIC was highly recommended for the old Spectrum. On the +3 it’s even better — if you program the new Amstrad Spectrum in BASIC, get version 1.2 for faster programs.
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 Z8O 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 GEMS, but no example explaining MONS.
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.
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 embed 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.
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. GEMS 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 first, but at least it leaves extra space for your program.
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 able 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 6.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 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.