Previous column ComputerAnswers
Next column ComputerAnswers
ComputerAnswers Column 5
COMPUTER ANSWERS MAY 1985
Copyright 1984-1989 Simon N Goodwin
Stuck? If you're tearing out your hair trying to solve a hardware or software problem, and you think other people might have run into the same snag, why not write to P.C.W? Please keep your questions short and relevant to other readers - then Simon Goodwin can try to do the same in his replies!
CROSSING YOUR CHANNELS
On retirement I decided to learn to program with a view to using a home computer for data processing.
I purchased a Dragon 32 and, after experience programming helped by various books, I purchased a disc drive and found it most useful. However, for data-processing the manual was less than helpful. There is no way I can see to convert cassette programs to use with the disc. All books deal only with cassettes and say "with the disc drive there will be another channel number." I have tried up to 30 and only get an error reply.
I should be most grateful if you could suggest how to find the channel number, and any books or articles which deal with Dragon disc and data-processing.
Dr.R I P Berry
Dragon Basic is designed to be 'device independent'. This means that you only need one set of commands to send data to any device - the display, cassette, printer, disk drive, or whatever. This scheme originally appeared in 'DEC Basic plus' for mini-computers. Later it cropped up in Microsoft Basic, which is the version of the language used - with minor variations - by IBM, Apple, Commodore, Tandy, and Dragon, among others.
In Basic the PRINT statement is generally used to transmit information, and the INPUT statement to receive it. You tell the computer which device to use with a 'channel number'. On a Dragon you use channel number -2 to send data to the printer:
and channel number -1 to send it to the cassette recorder:
Thus you could, in principle, divert a printout to cassette by just changing the channel number. This is easily done, especially if you use a variable in place of the value '-1' or '-2'.
Channel 0 corresponds to the screen. This is a special case which spoils the rule in the interest of convenience, since you don't have to specify a channel number to use the screen; the computer assumes you want channel 0 if you don't tell it otherwise:
There is an important difference between the cassette and the other devices, which is explained obliquely on page 130 of the Dragon manual. You have to use an extra command - an OPEN - before you can write data to the cassette, and a CLOSE when you've finished. You can write data to the printer or the screen, however, without any preamble.
The OPEN command tells the computer the name of the cassette file you are about to write. This makes it possible to distinguish between files later. Unlike the printer or display, the cassette is a two-way device, which is why you have to specify "I" or "O", for Input or Output, when you open a tape file.
You'd waste a lot of tape if the recorder started and stopped at every PRINT statement, so the computer collects cassette data in a buffer.
A buffer is an area of memory which is used as a temporary store. The computer only starts the tape-recorder and writes information when the buffer is full, so that the information is packed densely onto the tape.
The CLOSE command, used at the end of processing, makes sure that the computer writes out the contents of the partially-filled buffer before you remove or rewind the tape - otherwise you could take out the tape while some data was still hanging around in the buffer, awaiting transmission.
When you get a disc drive you are able to use another 15 channels: numbers 1 to 15. As with the cassette, you have to use an OPEN command to tell the system the name of your file, and to reserve memory for the buffer.
Disc drives are able to wind back and forth quickly, so you can have more than one file open at once - hence the 15 possible channel numbers.
It is worth bearing in mind that each open channel uses up some memory; if space is very tight you might find that you get an 'Out of Memory' error when a file is opened, in which case you will have to make room by simplifying the program, reserving less string space (with CLEAR), or dimensioning smaller arrays. Make sure you CLOSE files as soon as you've finished with them, or you could tie up memory needlessly.
To convert a cassette program to use the disc drive you only need to change the channel-numbers used in OPEN, PRINT, INPUT and CLOSE statements. Typically, you might change all the '-1' values into '1's. If you forget to change any statements the computer will give an error message when it tries to access the file. If the PRINT or INPUT seems correct, check that you've not overlooked an OPEN or CLOSE.
A number of books on Dragon disc usage are available from Tandy shops - the Tandy Colour Computer is very similar in operation to the Dragon. Books about disc programming in Microsoft Basic should also be helpful.
I can't get my new Spectrum+ to give accurate results in some calculations. If I repeatedly subtract fractions from a number (say, taking 1/10 from 1 ten times) I end up with small deviations from the value I expect.
Is my computer faulty? I'd like to use it for some simple accounting programs but I'm worried that it will give the wrong results.
G Kidd, Harborne
The problem you describe is common to almost all micros, and stems from the way computers store numbers. Luckily there is an easy way around the problem, at least in financial programs. To understand the problem, and its solution, you need to investigate the way computers - and humans - process numbers.
As you've no doubt often heard, digital computers use binary arithmetic, or 'base 2'. This means that each digit in a binary number represents 2 times the value of the digit to its right.
Humans have used decimal arithmetic, since the Arabs invented the system, a few thousand years ago. In this scheme, each digit represents 10 times the value of the digit to its right; thus, 'base 10'. There's no particularly good reason for multiplying by ten from one digit to the next - it's just convenient if you're counting on the fingers of two hands. If camels weren't such steady mounts, we might have ended up using base five!
Anyhow, to take a simple example, the number 110 in base ten can be thought of digit by digit, as 1 times ten times ten (for the first digit), plus 1 times ten (the second digit) plus 0 times one (the last digit). In base 2, the computer's system, 110 is 1 times two times two, plus 1 times two, plus 0 times one. Thus, if you work it out, 110 in binary is 6 in decimal.
Computers use binary because it is easy for electronics to deal with just two values (on and off) for each digit, whereas ten values (on, on-ish, fairly on, etc) are more tricky; you can get arguments about whether a signal is off or just fairly off, for instance, whereas the difference between on and off is clear-cut.
It is pretty easy to convert whole numbers from decimal to binary, or vice versa, so long as you can keep track of the multiplier for each digit - one, ten, a hundred, a thousand and so on for decimal, or one, two, four, eight and so forth for binary. It is more difficult to work out how to store fractional values.
In base ten we put a decimal point between the whole-number part of a value and the fractional part. Since the value of each whole-number digit decreases by a factor of ten, as we move from left to right, it seems reasonable enough to continue the trend the other side of the decimal point.
Thus the first digit to the right of the point represents tenths, then come tenths of tenths (hundredths) and so on.
In binary, the value of each digit decreases by a factor of two as you move from left to right. Copying the process used in base ten, each digit after the binary point should represent half the previous amount. Thus, in binary, the first digit to the right of the point represents halves, then come halfs of halfs (quarters), then eighths, and so on.
Just as in decimal, the more binary digits you use, the more accuracy you get, since you can store ever-smaller numbers. You can see that a half is 0.1 in binary and 0.5 in decimal (five tenths). Likewise, a quarter is 0.01 in binary (one half of a half), or 0.25 in decimal (two tenths plus five hundredths).
But there are some fractions that cannot be written precisely in base ten. A third, for instance, is 0.3333333 (roughly) - you'd need an infinite number of decimal digits to write the fraction accurately. In base three you only need one digit: 0.1, since the digit after the point in base three keeps count of thirds. Likewise, a ninth in decimal is 0.1111111 (roughly), or 0.01 (a third of a third) in base 3. Whatever base you choose, some fractions work out exactly, while others won't.
In binary, it turns out, you can't represent 0.1, or the fraction 1/10, exactly. The closest you can come is to say that a tenth is - roughly - a sixteenth plus 1/32, or 0.0011 in binary. This value (like 0.33 for a third) is a bit too small. 0.00110011 is more accurate, but you'd need an infinite number of binary digits to represent a tenth exactly, as a binary fraction.
If your computer used an infinite number of digits it would be (a) Infinitely Slow and (b) Infinitely Expensive, so perhaps it's just as well that it doesn't.
Since the machine can't store a tenth exactly, it follows that if you keep adding tenths together you'll keep adding errors, until the error becomes big enough to show up when you PRINT it. Computers normally 'hide' the last digit or so of a decimal result for precisely this reason - it is often wrong - but the truth comes out eventually.
The solution - as you may have guessed - is to avoid using fractions. This is not too difficult in accounting programs, since you just have to work in whole pence rather than pounds. Half pennies aren't a problem, if you want to bother with them, since a half can be written exactly in binary.
A few computers, such as the Atari, use decimal arithmetic internally. In such a system the computer works in binary, but one decimal digit at a time. This 'binary coded decimal' is slow, but it avoids the 'strange' errors you describe.
IN SEARCH OF QL PASCAL
Further to the review 'Mind your languages' in Personal Computer World, February '85, could you please advise me when and where the full ISO Pascal compiler for the QL will be available.
D Rayner, N. Humberside.
Sinclair have commissioned an implementation of ISO (International Standards Organisation) Pascal, but they hadn't announced any delivery date or price at the time of writing.
My spies tell me that the program is actually being written by Metacomco (26 Portland Square, Bristol). Their other compilers were reviewed in the article you mention. You may get advance notice about the Pascal compiler by contacting Metacomco directly.
The full ISO specification is pretty daunting, even for a QL, so it may be a while before the program passes all the tests, but Metacomco hope to have something to show by the beginning of May.
I have an Oric Atmos 48K computer and have just bought the Oric modem which plugs into the expansion port at the back. I have just ordered the Oric Mcrodisc drive and this also fits into the expansion port.
Is there an adapter so that both items can be plugged in and used at the same time?
P Sargent, Blackburn.
Oric have anticipated your problem. The lead from the computer to the microdisc (supplied with the drive) contains a socket which duplicates all the signals available at the back of the computer. If you plug the disc into the computer, and then connect the modem to the new socket, both peripherals should be ready to go.
ARRAYS AND MACHINE CODE
I am writing a program for the unexpanded VIC 20. Some of it is in Basic and some in machine code. I am having trouble using the data in the arrays (dimensioned in Basic) in the machine code part of the program.
I would be most grateful if you would enlighten me on the easiest or most efficient way to read data from arrays when in machine code.
E R D Mitchelmore, Dartmouth.
The key to this problem lies in the data which you are processing, and unfortunately you don't say much about that. There are routines within the ROM which locate array values, but they're complicated and not really designed for the purpose you have in mind.
If you're using floating point numbers (decimals) then you're probably best advised to write your entire program in Basic and forget about the code - machine code to manipulate decimals tends to be verbose and slow, so there's little to be gained by using it.
If you're working with whole numbers only, the obvious solution is to make things easy for the code. Rather than use Basic arrays, you should store the data in memory along with your machine code, using PEEK and POKE to read and write values from Basic, and LDA and STA from machine code.
It is quite easy to simulate an array with PEEK and POKE. If you're using an array of dimensions (5,6), the Basic command A(J,K)=A(L,M) would become: POKE BASE+J*6+K,PEEK (BASE+L*6+M). We've assumed that stored values fall within the range 0 to 255, and BASE contains the address of an area of 42 otherwise-unused bytes. Notice that, since array subscripts in VIC Basic start at zero, we've had to multiply by 6, rather than 5, when working out the address of the data.
If you need to store positive and negative values, you can always add 128 to each number before you POKE it, giving an effective range of -128 to 127. The limit of 256 possible values need not get in your way either - if you use two bytes for each value there's room for numbers between 0 and 65535. As an example, the following line will PRINT the value stored at position J in a table of 100 values. We've assumed that values of J start at 0 for the first entry in the table, and BASE contains the address of an area of 200 otherwise- unused bytes:
In this case the data is stored in pairs of bytes, like addresses in machine code - the second byte contains the number of multiples of of 256, and the first contains the remainder. To store the value of K at J, use:
If you need to manipulate strings from machine code the same approach can be used. POKE characters and string-lengths into memory so that they can be read by machine code.
The aim of the process is to keep things simple - it is quick and easy to write Basic, and harder to write machine code, so it is a good idea to adapt the Basic to cope with the idiosyncracies of machine code. Another advantage of using PEEK and POKE is that the Basic commands mimic the machine code LDA and STA.
Once you've broken the data down into bytes, or values between 0 and 255, you can use any organisation you like for the stored data.
I am a second year Architectural student and am thinking about buying a computer as an aid to my course and my future job as an Architect. The problem is, which computer? Ideally it should have good graphic facilities for future Computer Aided Design applications.
V Thomas, London N10.
When choosing between computers, personal criteria generally outweigh the technical ones. There's not much real difference between popular computers, other than price and (sometimes) availability. It's usually best to buy a cheap one and explore the possibilities at first hand.
In this case, speaking as an ex-CAD programmer, I'd advise you to put your future needs on one side, unless you're planning to write your own architectural software in the next few months.
Computer Aided Design (CAD) systems are only slowly making their way from minicomputers to micros by the time you graduate there should be lots to choose from, on new hardware like Atari's Amiga. CAD is one of the few areas in which increased computer power is really needed.
Today's fledgling systems run on machines like the Apple (Robocom), BBC Micro (various draughting packages) and the IBM PC (shaky versions of minicomputer software). A few firms are working on packages for the Sinclair QL, which has lots of memory and a minicomputer-like processor, but I've not seen anything wonderful yet.
For the time being I suggest you aim for a computer on which you can word-process your coursework reports. Consider any machine with at least 32K of memory and a display 60 or more columns wide. Second hand computers are often a good buy for serious applications. You'll need a printer too.
Leave the choice of a full-scale CAD system until it's tax- deductable, and remember that there's no point buying hardware unless you can get the right software to go with it.
OVER THE COUNTER
I am writing to you because I have been thinking of becoming a home computer dealer (mail order at first). I was wondering if you could tell me if there are any laws and regulations to be followed - also of any wholesale distributors.
J Oldham, Ruislip.
Don't do it! Or at least, don't do it without a great deal of thought. Microcomputer dealers go bust almost every day, often for no fault of their own. To enter the market now you'll need substantial capital or a very good nose for a niche in the market - business is no longer booming in the way it was four or five years ago. At the very least you should set up a limited company, so that you're not personally liable for the debts of your business.
At first it sounds a great idea to become a computer dealer. All you need to do, apparently, is contact a manufacturer and thus get in touch with a distributor. Then you place a couple of adverts, and wait for the cheques to come rolling in.
In practice you'll find that you must keep substantial stocks so that you don't keep customers waiting as supplies to you fluctuate. Magazines might even check this. It represents a lot of money tied up in products that could become obsolete overnight, or be slashed in value at the whim of some American marketing mandarin.
Five years ago the micro market was growing at a great rate. It could do that without much strain, since it was pretty tiny. A handful of magazines preached to isolated punters. There were few outlets for advertisements and few for products.
Nowadays most business is done through retail stores, which draw on the capital and management skills of large organisations. Distributors were hurt when the first wave of keen but incompetent dealers went to the wall: they'll want guarantees before they'll give you credit. Profit margins are small, as hundreds of firms fight over each market-sector.
When you've got the goods - and the orders - you must cope with Business Rates, VAT Returns, (if you turn over more than a few thousand pounds a quarter), faulty products, bouncing cheques and disappearing despatches. You've got to keep good accounts, for your own security as well as for the scrutiny of tax officials.
Unless you've got what the Americans call 'a Unique Selling Proposition' - a captive market or a captive product - you're probably on your way to bankrupcy or liquidation. If you're still determined to give it a whirl, research your proposed market by scanning advertisements and talking to existing dealers, then take advice from a Bank Manager.
Link to the top of this document
Link to the main index
Previous column ComputerAnswers
Next column ComputerAnswers