Personal Computer News


Canon V-20

 
Published in Personal Computer News #095

The advent of yet another MSX machine is no longer big news. But how does Canon's venture into this area of the market measure up? Is MSX the answer to the computer industry's dreams? Kenn Garroch investigates.

Canon's Shot At MSX

The advent of yet another MSX machine is no longer big news. But how does Canon's venture into this area of the market measure up? Is MSX the answer to the computer industry's dreams? Kenn Garroch investigates

The MSX revolution is trying hard to happen. This version from Canon is another of the surprisingly old-fashioned (new) machines.

First Impressions

The first thing that strikes you about the Canon V-20 is, naturally enough, its close resemblance to the other MSX machines. It sports a similar keyboard, an identical Basic, the same interfaces, and the same good old Japanese engineering inside and out.

For £280 you get the Canon itself with internal power supply, a cassette lead with motor control, an aerial lead, and two manuals. It's all packed into a cardboard box just the right size for you to carry it easily out of the shop - more good Japanese engineering.

All that remains to be done is attach a mains plug, plug into the TV and mains, and off your go.

In Use

Switch on and the Canon sits and thinks for three seconds or so as if in shock. Then up comes a message that this is MSX Basic and there are just over 28K bytes free. For a machine that is supposed to have 64K of RAM, this is a little meagre.

On perusing the memory maps in the manual, I discovered that 32K of the RAM is not in fact available to Basic. Curioser and curioser. This memory is hidden beneath the Basic ROM, and appears to be used for the video RAM. Part of this is usd to store the sprite data and with a maximum of 256 8 x 8 sprites, this comes to 2K. The rest must be used for the video display itself, although from the resolutions available, there must be quite a lot spare. The Spectrum fits a 256 x 192 plus eight colours and three attributes into 7K of RAM. The V-20 and presumably all other MSX machines have 256 x 192 with 15 colours and one attribute.

What, we ask ourselves, happened to the other 23K of video RAM? Perhaps it will be used at a later date, running the mythical CP/M system, to give an 80-column screen and higher density graphics, although why they didn't do that as standard beats me.

The V-20 keyboard is of the standard defined by Microsoft, i.e. the same layout as the rest. The resemblance ends here as the function keys are larger and rattle more. I also think they are relatively poorly positioned, though they do come pre-programmed with a selection of useful functions such as RUN and LIST. They can, of course, be reprogrammed using the KEY command but accept only 16 bytes of data.

The other eight large keys are split into two groups. Four are used as cursor control keys allowing full on-screen editing as with the Commodore 64. Again, these are too large to be comfortable. The other four are the stop key, insert, delete, and home/cls. The stop key, when pressed, only pauses the program; control stop actually breaks you out of Basic.

On the rear are the connections for the cassette, audio, video and RF outputs, and the printer port. The latter uses a bizarre plug that is apparently a 14-way Amphenol. This could cause some people problems with interfacing to printers but presumably, if MSX takes off to any extent, they will become more common.

On the front are the two joystick ports. These are the standard Atari/Commodore connections.

The cartridge slots are on the top and the side. The V-20 differs from some of the other machines in this respect as both these slots are cartridge connectors and not edge connectors. This is handy as the peripherals are designed to connect into the cartridge slot and this system should allow you to have both a cartridge and a peripheral connected at the same time without needing a special connector for one or the other.

In general, the machine is solidly built, although it would have been nice to be able to detach the power cable in transit.

The Basic

Most MSX machine reviews have covered the hardware in detail, so let's take a closer look at the Basic.

As its name implies, this is based on the good old standard as used by Dragon, Commodore, IBM and CP/M MBasic. The extensions are a whole host of additional commands to allow control over the fancy bits of hardware, such as the sprite and screen controllers plus a few commands that appear to have been added because it seemed like a good idea at the time.

Altogether 150 commands and functions are available, covering everything from Binary, Hex, and Octal conversions to error handling, sprite, and I/O controls. Unfortunately, this vast array of commands is poorly documented in the Basic reference manual. One particular moan here is lack of details on the sprite handling. Simple things such as how to define them are demonstrated in the explanation of DATA statement which means that you are sent rooting about all over the manual before you get anything done.

Overall, these extra commands appear to be handy and innovative - particularly the interrupt facilities which were previously available only on the Amstrad. The trouble is, they are not implemented nearly as well as the Amstrad, though interrupts can be made to occur on a number of different events such as sprite collision, the joystick fire button being pressed, the timer hitting zero, or a function key being pressed. The commands for controlling them are ON event GOSUB line No., where an event can be any one of the above, and event can be ON/OFF or STOP.

When the event occurs, the program jumps to the subroutine and begins executing it. When it finishes, the main program resumes from where it left off. The only thing to watch is that variable names do not become confused.

The problem with the interrupts is things are not as simple as initially appears. For instance, if you set up an interrupt to occur when a function key is pressed, holding the key down gives repeated interrupts. If, however, you then press another function key, the repeat stops working. This is downright annoying if it is one of the movement controls in a game. I suspect that this is a bug (oh, dreaded word) that will be corrected in a later version.

The question here is why not allow an interrupt for any key on the keyboard instead of one of the ten function keys, five of which need the shift key to access them and all of which are badly placed for game controls?

Still on the subject of the interrupts, when two sprites collide, an interrupt occurs. This sounds great until you realise that the machine will not automatically tell you which sprites collided. You must work it out for yourself. What this boils down to is that if there are more than about four sprites on the screen at once, it's faster to detect collisions by keeping track of them in the program then use the interrupt, since you're going to have to do it anyway.

On the whole, these interrupts are a marvellous idea. It's just unfortunate that they are not better implemented.

One of the better features of the V-20 (or any MSX) is its sprite handling capabilities from Basic.

Sprites are constructed from a series of character code numbers stored in the psuedo array SPRITE$. The numbers themselves are stored in part of the unused section of the video RAM. They can be in either of four sizes depending on the SCREEN mode selected, 8 x 8 or 16 x 16, normal or double-size (enlarged). Since a limited amount of storage space is available, you get 256 in 8 x 8 and (obviously) 64 in 16 x 16 mode. Once defined, it is possible to select any 32 to be on the screen at once. This is a handy way of doing things as it allows easy animation effects to be created.

Unfortunately, there can be only four sprites on any horizontal line at once. If an extra one is put there, it rubs out the right-most one. This causes a problem when writing a space invaders-type game as only the launcher and the rocket can be sprites otherwise there are only three invaders per line which looks pretty silly.

Defining the sprites is simply a matter of setting up eight DATA statements, each with an 8-bit binary number in it, using the BIN commands. A short routine reads these, converts them into decimal and puts the CHR$ numbers into a string array. The resulting eight character string is then placed into SPRITE$(n) where n is the sprite to be defined. Placing the sprite on the screen is fairly straightforward, using the PUT SPRITE command, specifying the sprite number, whether the next position is relative or absolute, position, colour, and sprite image to use number. Obviously this sequence shows that the sprite handling is flexible.

The only read problem is in changing screen modes, as this deletes all previously stored sprite information. You can't have everything, it seems.

Where the MSX machines do score is in their wealth of high-resolution graphics commands including CIRCLE, PAINT and a neat line command. This allows either point-to-point lines, relative to the last position or using absolute screen coordinates. An additional feature is obtained by using the B or BF suffixes. The first draws an outline box, the second does the same but fills it in i.e. an implied PAINT command.

Even better is the DRAW command which allows drawing macros. This function allows a section of commands to be placed within a string, such as U for up, D for down, rotate (A), scale (S) and colour (C). This gives you a simple turtle graphics system. Once the string is set up it is executed with DRAW string.

The screen size is a nice large, logical -32768 to 32767 of which points 0 to 191, vertically, and 0 to 255 horizontally, actually appear onthe screen. So, points can be plotted off the screen without errors occurring (unless the logical limit is exceeded).

A total 15 colours are available plus a transparent option. These are obtained mainly with the COLOR command although what colours are available depends on the screen mode you're in. There are four of these, the first giving 40 x 24 characters, no graphics or sprites, no border, and only one colour. The second is the default, i.e. boot-up screen giving 32 x 24 characters with every eight pixels having their own colour, sprites are also allowed but no graphics.

The next mode allows graphics but no text and again only every eighth pixel may have its own colour. This mode gives the highest 255 x 192 resolution. For graphics where each pixel has its own colour, SCREEN 3 is used. Unfortunately, this only gives a medium resolution of 64 x 48.

Also defined by the SCREEN command are the sprite size, the key click (on/off), the tape speed, 1200/2400 baud, and printer type. The last specifies whether the printer can produce the MSX character set. If it can't, the printer produces spaces.

As for getting into the insides, MSX Basic is well-equipped. PEEK, POKE and USR are available as well as INP, OUT, TIME and WAIT. Access to the video RAM is via the VDP command which allows you to straight into the controller registers. VPEEK and VPOKE are also there giving even more direct access.

Easy sound output is via the BEEP command. More complex features are available with SOUND giving access to the programmable sound generator. The macro facility again comes into its own with PLAY. This resembles the DRAW macros but instead of movement commands, you have the notes ABCDEFGA and the £ character for sharps. Once a tune is set up, the speed, volume and waveform shape can be changed. The sound normally comes from the TV speaker, but if you use a monitor, there is a direct sound output socket.

MSX machines will, in future, allow an upgrade from cassette systems to disk and possible CP/M. The file handling is standard Basic for the cassette system. There are two save and load commands. CSAVE saves files in internal, tokenished format and SAVE does the same in ASCII format. BLOAD and BSAVE allow sections of memory to be directly saved - all pretty standard stuff.

At the back of the MSX Basic reference manual is a brief summary of MSX DOS commands. No disk systems are currently available for MSX machines but details in this section give a clue to some of its possibilities.

The standard access commands are there including FORMAT (none of those tricks that Acorn plays), DEL, COPY and DIR. With the MSX DOS system disk you will get a separate disk Basic giving far more flexible filing with random access and field control. The DOS appears to be quite similar to the Basic A system on the IBM, and it remains to be seen whether the commands given in the Canon manual are the real thing or not.

While the Basic is a flexible programming tool, one or two drawbacks make it tricky. The lack of a good manual contributes to this, but it's likely that any number of helpful books will soon appear.

Another problem is execution speed. It's slow compared with other machines that offer even more facilities. The interrupts should get round this speed problem a little, but as they have not been that well thought out, they are more trouble than it's worth.

Verdict

The Canon V-20 doesn't stand out in the MSX crowd. It just conforms to the standard in most senses. Initially, the Basic appears excellent, but closer acquaintance and poring over the manuals took off some of its lustre.

If the Japanese push hard enough, they may snaffle part of the British market. However, if this is their best home micro, Sinclair, Commodore and Acorn, to name but a few, are still winning hands down.

Specifications

System: Canon V-20 MSX
Price: £280
Processor: Z80A running at 3.58MHz
ROM: 32K
RAM: 64K, only 28K for Basic
Screen: 40 x 25 characters Mode 0, 32 x 24 Mode 1
Sprites: 8 x 8 or 16 x 16 normal or enlarged
Graphics: 256 x 192 Mode 2, 64 x 48 Mode 3
Colours: 15 plus transparent, less depending on screen mode
Keyboard: 74 keys including ten function keys
Interfaces: Two cartridge ports, cassette port, two joystick ports, centronics printer, audio output, video output, RF output
Operating System: MSX Basic
Software Included: None
Distributor: Most high street stores

Canon V-20