Previous column ComputerAnswers    Next column ComputerAnswers

Logo

ComputerAnswers Column 3


COMPUTER ANSWERS MARCH 1985



Copyright 1984-1989 Simon N Goodwin

CONNECTION CONVENTIONS

I recently bought a Dragon 32 computer but I can't save or load programs. The problem is that the cable which comes with the computer has small jack plugs at the cassette end, but my tape recorder (a Philips 3302A) expects DIN plugs.

Is there any way I can use the tape-recorder with the computer, or will I have to buy a new recorder?
Andrea Husbands, Wrexham, Clwyd.

In theory it is possible to use the tape recorder, just by changing the plugs at the end of the lead from the computer. You'll need a two-pin DIN loudspeaker plug in place of the EAR jack, and a three pin DIN plug instead of the MIC jack. These go into the sockets marked with a picture of a loudspeaker and a digit (1), respectively.

You'll need to experiment to find the correct way to wire up the two MIC wires to the three-pin DIN plug - one wire should go to the middle pin, and the other to one of the side pins.

In practice it may be more sensible to spend #10 or so on a cheap, modern cassette player with jack sockets already fitted. You don't need to buy a special 'computer compatible' model - most of these are just last year's flops tarted up with a tape-counter and a few flashing lights. Some of them don't even work reliably with common computers! You'll get just as good performance from a cheaper, general-purpose model.

Some hi-fi recorders are useless with computers because they contain clever circuitry to 'process' the sound. This makes it sound better to the human ear, but confuses a computer, for which raucous bleeps and buzzes have a special meaning.

The most common cause of unreliable loading is incorrectly set-up tape-heads. This is easily identified, since you get problems loading other people's tapes (or pre-recorded ones) but your own tapes load perfectly; the mis-alignment corrects itself on your own tapes - you record them askew and read them back the same way.

Incorrect tape-head alignment is a common fault on old machines. With heavy use or rough handling the heads used to read a cassette can move out of line, making music sound dull and data unintelligible to a computer. The more 'tinny' a recorder sounds, the better it is likely to work with most models of computer. It is possible to re-align the heads on a tape recorder, but it is easy to make things worse rather than better unless you know exactly what you are doing.

Of course, it helps to clean and de-magnetise your tape heads regularly, using one of the kits available from most electrical shops, but this doesn't usually make a great deal of difference - computers are quite tolerant of dirty tape heads (except on a microdrive system!) - incorrect alignment gives much greater problems.

Some Hi Fi shops or Electricians will re-align tape heads for you, but prices vary widely, from about #2 to as much as #20. There isn't room to explain the procedure here, especially as it varies from one machine to the next, but I may explore it in more detail in a future issue if I get a deluge of further questions!



MIXING YOUR OWN PAINT

Is there any way I can use more than 16 colours on my Commodore 64 computer? I can use extra colours, for instance in sprites, but these must be chosen from the 16 available for background displays. I would like to be able to produce shading and graduated hues, like on an Atari or some of the new arcade machines.
Dave Waller, Canning Circus, Nottingham.

You're stuck with just 16 colours on a Commodore 64, although some of the new machines from Commodore allow the shading you describe. On an Atari every point displayed can have an 'intensity' (brightness) as well as a hue (colour) - this means that shades of the same colour can be produced, giving the attractive results you mention.

The electronics of the Commodore 64 can only generate 16 different hue signals for the TV - these correspond to the standard, poster colours you are used to. On a Spectrum there are only 8 colours available, but each can appear in bright or normal intensity, giving 15 possibilities (bright black looks exactly the same as normal black; in fact the difference between the other colours in each intensity can be hard to distinguish).

On an Atari there are 16 colours, but each can be shown in a range of intensities - either 8 or 16 different brightnesses, depending on which books you believe.

Luckily there is a 'trick' which can enable you to produce the effect of extra colours. Imagine a block of colour on a TV screen, 20 dots wide and 20 dots high. 400 dots would be glowing, producing an area of colour - say green. Now imagine that every other row in the block is set to black. You should have a grid of horizontal lines, but in fact what you get is a darker shade of green - the lines merge together, spilling dimly into the black areas. The effect is destroyed if you look closely at the picture, but from a distance it looks as if you have produced a new colour.

The effect may be better if you scatter the contrasting dots (which can be in any colour) throughout the area to be shaded, in a chequerboard pattern. A red and yellow check will look orange, red and blue will look purple, and so on.

This effect - a sort of computer tartan - can be used on any computer with a high-resolution colour display. It doesn't work on a low-resolution display, or a video monitor, since the dots don't merge together. It is called 'stippling'; it is named after a process used by some artists.

The Sinclair QL has built-in commands to generate stippled mixtures of its eight standard colours, giving the appearance of over 200 colours. Many commercial programmers use stipples on a variety of machines, to generate shading and 3D effects.



EXPERT IN TROUBLE

I am writing a small expert system on my Spectrum 48K. I have written the logic and am experiencing difficulty with the data. I have about 250 lines of data so far, although this will expand, hopefully up to 1000 lines.

Would it be wise for me to access the data directly using endless GOTOs, or should I consider a database system? If so, can you recommend a package?
M.D Gibbons, Rise Park, Nottingham.

It's hard to advise you without knowing exacly what 'difficulty' you are having, but here are a few general points about storing data on a small computer.

You're best advised to store all the data in a string or a string array, and load it into your program from tape or microdrive. This avoids all the 'overheads' - memory which would be used to store line-numbers, LET or DATA statements, and so on, at the expense of the room available for your data.

DATA statements are definitely to be avoided, since they can be very wasteful. If you read data from program lines into an array you are, effectively, creating two copies in memory - the version in the program, and a copy in the variables area. Some computers take special care to minimise the wastage of memory when strings are assigned from DATA, but in general the technique is very wasteful (remember that READ and LET take a COPY of the data and associate that copy with the variable being assigned).

The snag of using tape-files and string arrays is that Spectrum arrays use 'fixed length' strings. In other words, every string is padded out with spaces to a fixed length. This makes it easier for the computer to keep track of them, since each entry in the array can be found a fixed number of bytes after the one before, but it can be very wasteful if the strings vary a great deal in length - they will all be padded out to the length of the longest one, leaving large amounts of memory containing nothing but spaces. This is not a problem in Microsoft Basic (on the Dragon, IBM PC, Oric, Commodore 64 and so on) - those machines use so-called 'dynamic string arrays' - each string in an array can be a different length to the others. This is efficient, but slower than the Sinclair system.

Another problem confined to the Spectrum and ZX-81 concerns numbers in DATA statements and program lines. Computers use a binary form to represent numbers internally (leading to strange rounding-errors in some calculations).

Normally every number is converted from decimal (e.g. 42) into binary (the bits 101010) whenever the computer encounters the number in a program.

Sinclair computers store all numbers in text AND a hidden binary form, within the program. Thus the value 42 would be stored as the digit '4', then the digit '2', then a marker (CHR$ 14) to show that the next five bytes should not be listed, and the five byte binary form of the number. Five bytes are used so that large numbers or small numbers can be represented in the same way.

The upshoot is that the computer doesn't have to keep converting values from text to binary whenever it finds them. This makes the computer run programs a little more quickly (and saves Sinclair the hassle of having to write a fast routine to convert text to binary) but it wastes large amounts of memory - the value '1', for instance, takes up seven bytes rather than one (one for the text, plus a marker and five binary bytes) and the value -255 takes up ten bytes (four for the text, a marker, and five, once again, for the value).

The way to stop this largesse is to store the numbers in such a way that they can't be converted to binary as you enter them. The Spectrum only converts numbers - sequences of digits. It can't cope with expressions like SQR(PI), and works those out as it goes along.

Consequently it is more economical to type 'INT PI' (two bytes) than '3' (seven bytes - one for the text, a marker and five for the binary) in a DATA statement. You can use NOT PI instead of zero, PI/PI to replace one, -INT PI for minus three and so on, saving four or five bytes each time. The program will go a little more slowly (about 30-40 per cent, in my experience) but the data will occupy less memory.

In general, you will save three bytes on every number if you type 'VAL "number"' rather than 'number' - three bytes are used up by VAL and the two string quotes, but six bytes are saved, since the number is seen as a string and consequently not stored as binary as well as text. Remember, this is only true of the ZX-81 and Spectrum.

It is often a good idea to store your DATA as a CODE block, PEEKing and POKEing values. If many of your numbers are integers between 0 and 255, it is best to store those in single bytes, rather than use five byte floating point numbers.

You can store numbers in their text form, using a word-processor such as Tasword. Put an 'enter' character between lines of data, and commas or spaces between the numbers. Use a relatively small numeric array to contain the address of each line (you'll need a loop to initialise this array by PEEKing the code). Tasword produces a CODE file containing text data which can be loaded at any address.

PEEK and POKE are the most efficient way to store data, especially numbers, but they may be rather slow since you have to PEEK characters one by one whenever you need them.

It is definitely a good idea to divide your program into two parts - one to set up the data and another to process it. This minimises the space taken up by program lines at any point, but it can be unweildy on a cassette system.

There's one excellent book on simple expert systems. 'Build Your Own Expert System' by Chris Naylor contains example Basic programs (for Apple and Spectrum) which use GOTOS to implement a database.

The classic criticism of the GOTO statement is that it leads to unreadable code, but nobody expects to be able to 'read' a database anyway - they should be able to check all the data by asking the system questions, rather than by scrutinising the listing.



MORE ACE SPACE

Last year I bought a 3K Jupiter Ace. I would like to expand the memory, but I understand that the manufacturers of the computer, Jupiter Cantab, have gone bust. None of the shops near my home stock accessories for the Ace. Is there anywhere I can still get a RAM pack for my computer? Could I plug in the 16K RAM pack from my ZX-81?
John Dewhurst, Middlesborough, Cleveland.

The expansion port on a Jupiter Ace carries the same signals as a ZX-81 port, so it should be possible to connect a ZX-81 RAM pack. However the signals are wired on the port in a different order, so you'll need an adapter to enable the two devices to work together.

Despite the death of Jupiter Cantab there are still a few firms supplying Ace enthusiasts. The stocks of the Jupiter Ace, and add-ons, are now owned by a company called Boldfield Limited Computing (surely not a slight on the performance of the Ace?!). They sell most of the original add-ons, including RAM packs (#23 for 16K), joystick interfaces, keyboard adaptors and so on. They also stock a 'motherboard' which has an Ace expansion plug on one side and a ZX-81 socket on the other. You could use this to connect your Sinclair RAM pack to the Jupiter Ace. It costs #13.80.

For further details you should contact Boldfield at Sussex House, Hobson Street, Cambridge CB1 1NJ.



TRANSLATION FRUSTRATION

I have recently changed computer from a Sharp MZ-80A to a BBC Model B. This has meant that all the data I had on cassette for the Sharp's data base is now incompatible with the BBC. As there is so much data on the cassettes it is impractical to type it out again if there is an alternative. What I would like to be able to do is make the data compatible with a BBC data base.
Edward Wilding, Blaby, Leicestershire.

This is a very common problem, in business data processing as well as personal computing. Often companies use the same system for years rather than upgrade to a more useful or efficient one - they simply can't afford the cost of converting all their data from one format to another.

Curiously enough, the essence of the problem is the low cost of computers - it doesn't take very long before the data on a system is worth far more than the machine which processes it.

In your case there's no easy solution. Both computers use special-purpose hardware to generate or detect a cassette signal, and they each use a different approach to the storage of data.

Your Sharp cassettes will make no more sense to the Beeb than a tape of Culture Club or Beethoven's Pastoral symphony.

Data on a cassette is recorded as a series of clicks or tones. One pitch might correspond to a logic 1, and another to a logic 0, so that a stream of bleeps or clicks can correspond to a program, or a list of data items. The actual pitches or timings used will vary from one computer to another, influencing the reliability of the recording and the speed at which it can be read.

Your BBC Micro uses different tones and a different speed to the Sharp, so you can't just load the data as you would information recorded from another BBC. In fact, the Sharp data would be too fast for the Beeb.

Even if the tones were the same, the 'format' might be different. This is the sequence in which data is recorded, the way file names and locations are handled, and so on.

Every file contains extra information besides the data - its name, size, total value (for checking) and so on. These are recorded in different ways on various machines. There's no 'standard' format since each choice has advantages and disadvantages in terms of complexity, flexibility, reliability and speed.

Some computers decode cassettes using software. A program might use simple electronics to sense individual clicks on the tape. Software translates the pattern of clicks into a message. In such a computer it is possible to read 'foreign' tapes by loading a program which can decipher the timings and format used. This only works with a few computers - for instance, it is possible to obtain programs to load TRS-80 data onto a Nascom, or ZX-81 programs onto a Spectrum. Even these programs have some restrictions, and they are not able to convert all types of file.

The BBC Micro uses hardware to decipher data on cassette. This makes it fast but inflexible - it can only decipher two formats (BBC Micro tapes at 300 or 1200 baud). The Sharp tapes conform to neither system, so they can't be read.

There is a solution to your problem, but it will involve connecting the two computers together and a good deal of trial and error.

There is a 'standard' way of transfering data from one computer to another, or to another device. The RS-232 interface is a gadget which transmits characters, bit by bit, to any other device with the required circuitry. It is often used to communicate with printers, or telephone modems, or other peripherals. Your BBC Micro has an RS-423 interface, which can produce signals like an RS-232. The RS-232 is a two-way link, so you can transfer data either way between two computers equipped with the interface - at least, that's the theory! You will need an RS-232 interface for the Sharp, and a cable to connect it to the RS-423 socket on the back of the BBC micro. If communication is impossible at first, turn the plug at the BBC end the other way up - the position varies depending which computer thinks it is 'in charge'.

You should be able to PRINT data from the Sharp, down the RS-232 cable, and INPUT it into the BBC Micro. You'll have to read about the commands needed to control the RS-232 interface at each end of the link. Once you've got communication underway you can write the data out to a BBC Micro cassette, although you may have to juggle it around a bit to convert it into the format expected by your data base package.

Unless you understand a lot about both computers, or can find someone who does, it is going to be much easier to re-type your data onto the new system. Of course, you won't learn as much that way...!



COMMODORE ASSEMBLERS

I have been searching through magazines looking for reviews of assemblers for the Commodore 64. I haven't got very much money so #20.00 is about the most I am prepared to pay.

Would you be able to recommend a suitable assembler, bearing in mind my price limit and the fact that I am still using tapes?
Daniel Procida, De La Salle College, Malta.

There is a large number of assemblers available for the Commodore 64, on tape, disk and cartridge. Most of them allow all the standard features of assembly language - mnemonics, labels and so on.

It is worth making sure, before you buy an assembler, that it conforms to a few basic criteria - it should be written in machine-code (Basic assemblers are irritatingly slow) and it should be at least 'two-pass' - this means that you can refer to any label anywhere in your program. Other useful features are 'macros' - facilities to refer to a group of instructions with one name - and built-in debugging commands - these should allow you to adjust memory values, start and stop machine-code programs, and so on.

There is a big problem associated with learning machine- code on a cassette-based computer. When you make a mistake in a Basic program, the most common result is an error message. You can then adjust the program and run it again.

The same cannot be said for machine-code programs. The majority of mistakes in machine-code cause the computer to stop dead or crash completely, losing all the contents of its memory. In either case you can't fix the mistake until you have re-loaded your assembler program, instructions, debugger (if any) and re-assembled the code. This will take several minutes on a cassette system.

It is much more convenient to have your assembler on a cartridge, so that you don't have to re-load it from tape every time something goes wrong. This may cost a little more than you planned (Commodore's own assembler/editor cartridge costs #24.95 at the time of writing) but the extra money will be well-spent - you'll save hours in the first week of serious use. Almost all professional Commodore 64 programmers use cartridge-based assemblers.

If you want to dip your foot first, and get some idea of what assembly language is all about, you might as well start with a cheap and cheerful program on tape. Mushroom Software (193 Rommany Road, London SE27) sell a 2/3 pass assembler on cassette for just #5.50 - plus #1 for overseas orders.


Link to the top of this document    Link to the main index
Previous column ComputerAnswers    Next column ComputerAnswers