The Commodore 64 is noted for sophisticated graphics and good sound but has no in-built facilities for handling them. So when a schoolboy, David Simons, produced a new Basic enhancement package that substantially extends its range of commands, Commodore jumped at the chance to cover its oversight and marketed his Simon's Basic worldwide as a cartridge.

David Simons had got his C64 remarkably early; so did Brian Candler, another schoolboy. He's done the same thing, calling his version B-C Basic. Simon's Basic is now well-known; B-C Basic is cheaper. So how do they compare?

A glimpse through the list of commands available shows that Simon's Basic (SB from now on) has more commands than BC-BASIC (BCB). And since the most-used commands are likely to be in the area of graphics and sound, that is where we will start looking.

There are two basic graphics modes on the C64. The normal high-resolution mode gives 320 horizontal points and 200 vertical; but there's a limite of only one colour in each 8 x 8 cell on the screen. And then there is multi-colour mode which reduces the horizontal definition to 160 but allows more colours.

SB changes the co-ordinate range to match the mode being used, BCB retains the same range regardless. There are arguments in favour of both methds; the former is more logical, but the latter does at least allow a hi-res program to be changed to multi-colour with ease.

The normal text display has a second mode in which each character can have a different background colour (this is known as the extended background mode). BCB uses MODE n to select the appropriate graphics mode; SB uses commands such as HIRES, MULTI and BCKGNDS, with NRM returning to text mode - the plotting colours are set as parameters to these commands.

Because BCB doesn't set colours as part of the mode selection, there are additional commands such as SETCOL, GCOL, BORDER, PAPER and INK for that. SB has colour selection commands for setting border and screen colours and to amend the graphics colours once they have been set.

Plotting points and lines are the minimum capability of any graphics system. Both packages provide for these, although they differ in their co-ordinate systems.

Most graphic plotting assumes that the origin (x=0,y=0) is at the bottom left of the screen, which it is in BCB but in SB it is at the top left, which means an additional Basic calculation to turn it up the right way.

There are several ways that a point can be plotted. The simplest is to put it at the given coordinates in the currently selected colour; but it may be necessary to invert the point, clear it or set it in some other way. And of course there are the different multi-colours to be selected. All of these are catered for in both packages.

Points are not the only things that may be plotted - there are lines, circles, part of circles, boxes and text. SB provides them all, together with BLOCK (which is a filled-in block) and ANGL (which draws an angled line, defined as the radius of a circle) SB also provides an 'area fill' command and a DRAW command for generating shapes set up as control strings.

BCB provides only for text and simple line drawing, but at least it remembers the last point plotted; and it has a DRAW TO command, something which SB lacks.

It is possible to have two screen areas available for graphics work on the C64. BCB provides an easy way of selecting either of the two; and because the screen is cleared only by the CLG command, it is possible to set up two screens of graphics data and flip between them.

Both packages allow the character set to be transferred into RAM so that it can be altered: SB does this with one simple MEM command. BCB provides two commands - CHARSET, which tells the C64 that the character set (and screen, if you want it to) has moved, and a COPY command which then copies some or all of the ROM character set into RAM.

Once this has been done, characters can be redefined. SB uses the DESIGN2 command, followed by the RAM start address of the character to be defined. This is followed by eight consecutive program lines of character definition using decimal points as blanks and 'B' for dots.

This is awkward and could make for a very long program is a complete character set needs to be set up. BCB adopts a rather different and more versatile approach, with a DEFUSR command that takes the character code (so there is no need to calculate RAM addresses) and the row number, followed by the binary image of the row. Because this image is a number it can be in decimal, binary or hex; and the data could be read from DATA statements or from disk or cassette.

Sprites (or Moveable Object Blocks - MOBs - as Commodore prefers to call them) are one of the great graphic attractions of the C64 and both packages provide a good range of sprite commands.

In fact, sprites are quite complicated things to set up: there are several parameters required to handle them. There is theoretically space for 256 sprite definitions, but only eight 'active' sprites are allowed at a time. This means that, once a sprite specification has been set up in one of the 256 definition bocks, each active sprite needs to be assigned one of these definitions. By doing this, the C64 allows a single sprite to have its definition change very rapidly, simply by altering the pointer to the definition.

As well as the definition block, each sprite needs to be assigned a colour, a priority over the normal screen characters (that is, whether it should go in front of or behind any normal screen data), and a sprite type (high-resolution or multi-colour).

SB sets all these parameters in the MOBSET command, which also turns the sprite on - MOBOFF turns the sprite off. BCB has individual commands for these functions.

Although multicolour sprites can be set up as normal sprites, with pairs of dots being used to define the colours, it is extremely laborious to do. One advantage of SB is that multicolour sprites are extremely easy to set up: the letters B, C and D are used in the grid (which for a multicolour sprite is only 12 dots wide) to determine which colour should be used.

Both packages allow sprites to be positioned on the screen. But this can be a little tricky when sprites are being moved off the screen as a glance at the user manual will show. BCB has looked after all these problems and even accounts for the difference between machines on either side of the Atlantic, where the necessary calculations will be difference.

Moving sprites in Basic is extremely slow, and so both allow sprites to be moved as part of a single command. SB only allows one to be moved at a time, and pauses in the program until this is complete. BCB allows all sprites on the screen to be moved; and because this is done under interrupt control, the program can continue execution *while they are moving*.

Of course, there's probably not a lot of use in moving sprites unless you can detect if they collide with anything; and both BCB and SB provide fairly easy methods of doing this. Unfortunately, the way that the C64 decides whether a collision has occured makes detecting them rather difficult: neither package has provided any way of getting over the problems.

Both packages allow waveforms to be chosen, the envelope shape to be set and ring modulation or sync modes to be selected. SB does it rather clumsily, though, and the WAVE command is really only another way of POKEing the appropriate control register: so it requires a binary image of this to be set up.

If the pulse waveform is selected, the pulse width value must be set up with a POKE on SB. Unlike BCB, there is no command for this.

Each voice on the C64 must be individually turned on and off in order to generate the sound envelope. SB can only do this by setting and clearing a bit in the WAVE command, and this is extremely messy. But BCB by contrast has ATTACK and RELEASE commands available.

BCB also has individual commands for setting all of the sound parameters quickly and simply, and there's a PITCH command too. Rather surprisingly, SB does not provide these - instead it uses strings to generate sounds. There are set up with the MUSIC command and then played (on the voice) with a PLAY command.

Structured programming has become the trendy watchword for personal computer users, although professional programmes have been using it for quite some time. In essence, it just means abandoning GOTO and GOSUB so that subroutines are known as 'procedures' and called by name rather than line number.

These should have the facility of having data passed to and from then, and the ability to use variable names at a local level (known as LOCAL variables) so they do not affect similarly named variables being used outside the procedure (GLOBAL variables).

SB has the ability to set up procedures and define LOCAL and GLOBAL variables. The (apparently preliminary) version of BCB that I have does not support these, although thenext release will reportedly have them available.

Reading joysticks and paddles is provided for with both packages, but SB only caters for one joystick and one paddle pair - BCB can read both pairs of paddles.

SB has commands for accessing the lightpen input, while BCB allows the user port to be accessed very simply and efficiently.

Input comes from the keyboard as well, of course; and there SB has a range of commands for reading the function keys and assigning strings to them, and for limiting the number and type of characters that can be accepted during input.

The only specialised input feature in BCB is a simple KEY command which will retrieve the ASCII value or character of the key which is currently being pressed.

BCB provides only an INSTR function allowing a string to be searched for another and returning the position where it was found. SB has a variety of string commands that allow one string to be inserted into another, strings to be duplicated many times, and a PLACE string command similar to INSTR.

A unique feature of SB is that it has a range of programmers' aids available, which are there to assist during the programming phase.

These include the usual 'toolkit' facilities - like AUTO to produce line numbers automatically, RENUMBER which renumbers the lines (but regrettably doesn't renumber GOTO or GOSUB references in the program), TRACE which shows on the screen the line numbers as they are being executed, FIND for searching a program for specified characters, and MERGE which reads a program from disk or cassette and sticks it on to the end of the program currently in memory (which is really an APPEND command and is of limited use).

There are a couple of other commands for controlling listings on the screen within SB. For instance, the number of lines displayed can be limited, thereby effectively 'paging' the listing and making it easier to read (except that you cannot abort this and must list to the end of the program before making any changes).

Disk access is available too, using DISK to send commands to the disk and DIR"$" to read back the directory. There are no commands though to read the error channel, nor for direct loading or saving to disk.

Finally, SB has an ON ERROR facility. This will jump to a specified program line as soon as an error occurs; and once there, the line number and type of error can be identified. That can be extremely useful for trapping unexpected errors during program execution, although it does not allow the RUN/STOP key to be trapped.

Looking first at Simon's Basic, I would probably need an article at least as big as this one to describe all the bugs and problems discovered to date. I will not attempt to list them all, but will mention a few general drawbacks that exist.

For one, in many of the commands which use strings there appears to be no consideration of the case when the strings contain no characters (that is, they are null strings). And in those circumstances all sorts of rather unpleasant things can occur.

Little attention has been paid to the case when the screen moves, and any commands which write directly to the screen (or which TRACE is an example) just will not work in this instance. In fact, TRACE continues to put its line numbers into the memory where it things the screen should be - and this could trample all over anything you may have there... which could be your program, some machine code, or other data.

Range-checking on mot of the SB commands is fairly poor, and the DUP command will allow you to make a string which is larger than the maximum 255 characters (it ends up as some odd length).

Simon's Basic keyboards must not appear in any strings in DATA statements unless they have quotes around them, otherwise they will be turned into tokens. This actually applies to one of the example programs in the handbook: it gives a DATA line containing the word "STRALING" and that includes the SB keyword "LIN" - so it will not read back as expected.

There are many other bugs and problems. The result? A package which, although superficially exciting, is actually of very limited use.

In addition, many of the commands are rather badly presented and could have their syntax significantly improved to make them easier to use. Even the handbook is riddled with errors - example programs which will overwrite themselves with sprite data, some commands not described and many errors of fact (including a list of colour codes which are actually for the Vic-20 and not the C64!).

On the other hand, BC Basic is a little more limited in its range of commands. The lack of any programmers' aids tools, for instance, is rather a shame. But BC Basic is very robust and I have been unable to find any bugs or problems with it.

Not only that, but the commands are well thought out; and while they are occasionally a little more complex than some in Simon's Basic, commands in BC Basic are much more versatile and useful in practice.