Previous column ComputerAnswers   


Final ComputerAnswers Columns


Copyright 1987-2011 Simon N Goodwin

2011 update: This web page contains the final set of questions and answers Simon N Goodwin submitted to Personal Computer World. They were printed over several months, as space became available in the magazine. FAULT FINDING BY NUMBERS (below) is my all-time favourite problem and solution.


Over the years my company has built up an extensive library of software designed to run on our IBM micro-computers using Microsoft BASIC or BASICA.

We are attracted towards the Amstrad PC1512 but rather dismayed to discover that we cannot load IBM BASICA into the Amstrad in order to run our software. Can this problem be overcome?
M.J Fort, Peterborough, Cambridgeshire.

Most of the code for BASICA is stored in 32K of ROM memory on the IBM PC system board. The file you load from disk is actually only a bunch of corrections and 'extra' features which work in conjunction with the ROM routines.

In their economy drive Amstrad decided to do without the ROMs, which is why you can't run BASICA. However you CAN run Microsoft's stand-alone MS-BASIC, and this is so similar to BASICA that you are unlikely to run into compatibility problems.

The most cost-effective scheme is to buy a copy of Microsoft's £85 'QuickBASIC' compiler. This translates interpreted BASIC programs into machine code. It gives a hefty speed advantage, and adds several much-needed features to the language.

Microsoft say that QuickBASIC code will run without change, and no need for an interpreter, on any PC compatible - Amstrads and IBMs included! You'd be wise to carry on developing software on 'real' IBMs, so that you can use their interpreters for interactive testing. Microsoft's phone number is 0734 500741.


In the November PCW I read of boxes "to turn a monitor into a television". I would very much like to know more. Is a separate aerial needed? Do I have to disconnect disks, printers and so on? Will they work with any monitor, such as mine for the Tandy Model 1?
Parig Digan, Dalgan Park, Ireland.

There must be many situations when it is desirable to take output from a composite video source and feed it into an RGB monitor. Is this feasible (and cheap)?
Alfred W Pauson, Thornliebank, Glasgow.

Last year Display Electronics obtained a very large number of 'TV tuners' - devices capable of splitting a broadcast TV signal into standard, unmodulated sound and video. I suspect that these gadgets were originally made, at considerable cost, for cable TV applications. Display Electronics realised that they could be used to feed television signals from a conventional TV aerial into a computer monitor, and a market was born! Incidentally, this is not a way to avoid payment of a TV licence. UK licensing law covers the use of 'receiving equipment' - not just television sets. You must buy a licence unless the premises where the monitor is used to display broadcast television pictures are covered by an existing license.

The original 'Telebox' produced a composite video signal compatible with colour or monochrome monitors that accept input through a single, screened, cable. The term 'composite video' indicates that all of the information needed to produce a picture - intensity, colour, vertical and horizontal timing pulses - is encoded into one signal.

The TV sound is NOT encoded with the video information, although tuners for monitors receive that as well. Two sockets on the Telebox allow you to connect an external loudspeaker or amplifier. The first socket provides up to about 4 Watts of power, which should be louder than most TVs, if you supply an efficient 'speaker; the second output is at 'line' level. The basic Telebox has seven push-button tuning controls, and sells for about £30.

Not all micro monitors accept composite video input. Some require you to supply separate timing signals, or 'synchs', pronounced 'sinks'. Colour monitors often need separate signals to control the three colour 'guns' which work in combination to generate any colour.

A few computer displays gain elegant circuitry, and crisper boundaries, by only allowing a gun to be 'on' or 'off', with no intermediate levels. These 'RGB TTL' models CANNOT display a TV picture properly, as they can only display eight colours, including black and white. RGB stands for Red, Green, Blue - the three primary colours - and TTL stands for 'Transistor Transistor Logic', which is the generic name of the type of switching circuit used.

RGB monitors which allow smooth, graduated control of the intensity of each primary colour are termed 'linear'. These can produce a full range of colours, so they're capable of reproducing the detailed colour in a TV broadcast - indeed, most monitors seem to work at least as well as TVs of the same price.

Three firms make tuners for RGB linear monitors, all at prices around £70. The first of these was the Screenvision from Screens Microcomputers and Electronics. This is a souped up version of the Telebox, with RGB Linear output and a built-in 'speaker, as well as a phono output. Screens have developed PAL A/B and SECAM versions of their tuner, which can decode signals broadcast outside the UK.

Display Electronics replied with 'Telebox 2', building a composite-to-RGB signal converter into the first Telebox, and adding a loudspeaker and front-panel controls. Then champion box-shifters Dk'Tronics joined the fray, with their own RGB linear tuner.

The basic Telebox is much the cheapest unit, but it has no speaker and only works with Composite Video monitors. All the RGB Linear models have distinct selling-points. The Telebox 2 is probably the most flexible, as it allows composite to RGB conversion and abounds with front-panel controls. The Screenvision is slightly cheaper and available in 'export' versions. The DkTronics tuner is available through retailers, at marginally the lowest UK price, but it has continuous, rather than push-button, tuning, and lacks composite video and line-level sound outputs.

The RGB Linear tuners generally need specially-made leads to join them to your monitor, although Amstrad users should be able to use their computer lead. S.M.E. can make up leads to order, given the details of your monitor.

A tuner is unlikely to work if your monitor must have separate horizontal and vertical synch signals, or if it uses an American-style 60 Hertz screen refresh rate. UK broadcasts redraw the screen only 50 times a second, and few US monitors can 'lock on' to this slower rate. Most such monitors come with imported IBM PCs and work-alikes.

Commodore's 1910 monitor is stranger than its specification suggests; it will accept composite video, but not RGB.

I'm pleased to say I found all three companies very helpful. Display Electronics can be reached on 01 679 4414, Dk'Tronics on 0493 602926, and Screens Microcomputers and Electronics (S.M.E) on 09274 20527.


I have a Mannesman Tally MT-80+ printer, and would like to know the type number of the 2K RAM buffer chips mentioned in the pathetic user-manual.
C Smith, Shipley, West Yorkshire.

The MT-80+ accepts the 6116 chips which are used in most low-cost printers. You must open up the printer and remove the interface board to reveal two sockets, labelled RAM1 and RAM2. Each expects one 6116, so you can expand the internal buffer by up to 4K.

You'll need to adjust some of the configuration DIP switches inside the printer, to tell it that the extra RAM is fitted. I suggest you enquire about this when you order the components, unless you can find advice in the manual.

Mannesman Tally charge £10 plus VAT for each chip; their Sales Office is in Molly Miller's Lane, Wokingham, Berks RG11 HUT (0734 791868). You should be able to get the chips - but probably not technical advice - from many other component suppliers.


I periodically use an Acorn BBC Model B micro and a Miracle Technology WS200 modem to demonstrate computer communications to my college classes. I would now like to use this configuration to access an account on a DEC minicomputer at a nearby polytechnic, and need a software package to make the BBC Micro emulate a DEC VT52 or VT100 terminal. Are similar applications packages available for the Sinclair Spectrum?
S.F Tyler, Ketley, Telford.

The BBC Micro's built-in software comes quite close to emulating a DEC VT-52 - many of the control-codes are identical. The VT-100 is a more sophisticated beast. It offers reverse-video, various character sizes, smooth scrolling and many other features which you can probably live without, especially if you're using a slow dial-up link. Computer Concepts sell a package called 'Termi 2' for £33.35 - this offers VT-52 emulation, with an option to 'customise' its response to emulate other simple terminals.

If you need VT-100 emulation you have a choice between Computer Concepts 'Communicator' package, at £69, and 'Dial-up' from PMS Communications Ltd. 'Dial-up' is normally sold 'bundled' with a WS4000 modem, but you'll want the version that consists of software and a cable; 'personal' and 'educational' variants are available, both at prices around £80. PMS can be contacted on 021 643 7688; Computer Concepts are on 0442 63933.

The Spectrum display can't cope with the 80 characters per line of a VT-52 or VT-100, so there's no chance of getting it to emulate a DEC terminal properly. However simple terminal emulation software is available for the Spectrum with a WS2000, and that will probably allow a limited degree of communication. Forms-entry and screen editing programs are unlikely to work, but you should be able to pass commands and messages back and forth.

You'll need a 'proper' RS-232 interface for the Spectrum - Sinclair's 'Interface 1' works OK with printers but can't cope with all the demands of a modem. Miracle Technology (0473 216141) sell an appropriate interface, with simple bundled software, for £39.95.


I own an Atari STF and a Star NL-10 printer, with a parallel interface cartridge. When I print a simple statement: 'THE RAIN IN SPAIN...' the printer produces a garbled message: 'WKG#SCKO#KO#SSCKO...'. What am I doing wrong, if anything? Is the computer or the interface faulty? Please bear in mind that I'm a relative novice.
S.A Westerdale, BFPO 16.

I'm glad you sent detailed examples of this problem, including a 'hex dump' - a printout of the character codes received by the printer.

The exact problem becomes apparent if you write each character code to binary notation, and compare the codes transmitted by the computer with those received by the printer. The binary code for 'T' and 'H' are 01010100 and 01001000, whereas your printer acts as if it receives 'W' and 'K': 01010111 and 01001011. The difference should be obvious - the printer is assuming that the last two digits of each code are 1. If you work your way through the rest of the message you should be able to prove to yourself that this happens regardless of the transmitted value of those digits.

The 'parallel' interface is so named because it expects all eight binary digits of a character code to be transmitted synchronously down eight wires. Somewhere in your system two of these digits are 'getting lost'. Under such circumstances computers usually assume a specific value for such un-connected or wrongly connected signals - in this case, the assumed value is '1'.

Information is sent in parallel from the computer to the interface; if the computer was losing two signals it would not run any programs at all, so it is safe to assume that the problem is somewhere between the computer circuit-board and the printer. The only way to track down such a fault is to systematically examine and, if need be, replace links in the 'chain' between the computer and the printer until the culprit is identified.

I would suspect the printer cable first, then the connectors at either end of it. The interface would be my next suspect. Check that it is properly plugged in, and works with other parallel printers. Alternatively, try the printer with other computers, and see if the garbling of characters still occurs - in which case the printer must be at fault.

You can narrow down the cause of any consistent fault very quickly by replacing components in a system. It is wise to check the cheap mechanical components, such as connectors, first of all. Keep notes, and work in a logical sequence - don't jump to conclusions.


I have had access to three machines with a hard disk, and in each case have found a discrepancy between the total number of bytes for all the files on the disk and the total space allocated to these files. Research indicates that the difference is on a 'per file' basis, independent of the size of any particular file. It amounts to an 'overhead' of space lost per file.

On an IBM PC, with a 20 Megabyte hard disk, this overhead was six kilobytes. It was 1.5K on a 10M Sirius, and 8.2K on a 10M Olivetti. If I have 500 files on one disk, which is by no means unusual or unreasonable, this took up 15 per cent of the IBM PC's disk - a completely unreasonable loss! I have tried dumping the files to a tape-streamer, reformatting the disk, and restoring the files individually - not an 'image' dump. The outcome was exactly the same. I have never seen anything published about this loss. What is going on?
A.L Minter, Sandwich, Kent.

The space on most disks is not allocated character by character, but in lumps, known as 'clusters' or 'granules'. The size of each granule is encoded in the operating system - on PC's it is in the part of the operating system which deals with the nitty-gritty details of communication with a specific manufacturer's hardware. As you have found, the size of granule often varies between one machine and another, and even between different types of drive on the same machine.

A whole number of granules is allocated to each file. If the granule size is 1K, a one byte file and a 1000 byte file will occupy one granule. A 1025 byte file will just overflow into two granules. The smaller the granule size used by a system, the less the overhead 'per file'. But the more granules the operating system must keep track of, the slower it will work, under typical circumstances. This only makes sense if you understand the way files are stored on a disk.

Imagine the consequences of organising a disk as a stream of characters, with each file stored in the next available place, immediately after the previous one. This corresponds to a granule size of one byte. Now imagine that several programs are all writing to different files on that disk. Later, the computer must be able to read the information from each file separately, without getting the data muddled up.

You could try to move entire files whenever a 'collision' might occur. This will involve very large amounts of work, during which the contents of the disk might be garbled - temporarily, unless a power-failure occurs in the meantime.

If you move files just as far as they need to go to allow data to be inserted 'in front' of them, you might end up moving almost the entire content of the disk every time a character was added to an 'old' file. But if you move files further than need be - to make a 1K, or 6K 'hole', perhaps - you might have to move them back later, and you need somewhere to keep track of the amount of 'unused' space at the end of every file.

The costs and problems associated with shunting files back and forth around a disk are so terrible that no one takes this approach seriously, despite its initial appeal. It makes more sense to split the space on a disk into indivisible granules, and allocate these as need be.

Your idea of copying all the files on a disk to tape, and then re-loading them individually, may have improved the speed of your system, by ensuring that files were in contiguous granules, rather than interleaved all over the surface of the disk. As you found, it does nothing to release the unused part of the last granule in every file.

Granules are clearly a good idea, or at least a practical one. But why do they tend to be so large, particularly on hard disks, and hence wasteful when small files are being used?

The average size of files on a computer system obviously depends upon the user and the application, but it is often the case that a system will contain a few very large files, but many small ones. The granule size used by the Unix operating system was originally fixed at 512 bytes, for just this reason.

Whatever the size of each granule, the computer must reserve space, outside the area used to hold file contents, so that it can tell which granule belongs to what file, and what position it takes in the file. This information is usually held in the 'directory', along with file names, dates and so on. In theory this can be a file like any other, but in MSDOS it occupies a fixed area and position on the disk.

Ideally the directory would be in the middle of the disk, to minimise the time taken to find it from any given point, but this gets tricky when you allow varying numbers of tracks. Microsoft put the directory on the outside of the disk, where it can be argued data is most secure, as it is spread over the longest possible arc by a constant-speed drive.

So a 1K section of the outer track on a PC floppy disk is reserved for the 'FAT', or File Allocation Table. This table keeps track of which granule belongs to which file. It is not acceptable to have to read this table from disk every time the computer steps from one granule to the next. Lots of time would be wasted while the head was wound back and forth between the directory and the data granules.

Microsoft realised this. When you change the disk in a drive the computer reads the disk's FAT into memory. This saves having to keep re-reading the allocation information from disk while a file is processed. The FAT is re-written to disk when files are closed, which is one reason you should always close output files before removing a disk from a drive.

The bigger the FAT is - hence the greater the number of granules on a disk - the more time must be spent reading and re-writing it, after changes, and the more memory is soaked up by the FAT while a disk is in use.

Microsoft squeeze the FAT for a 320K floppy into 512 bytes, by packing two numbers into every three bytes and using 1K granules. A 20M hard disk using 1K granules would need 20,000 FAT entries, each of two bytes - 40K of data! It's not surprising that IBM choose to trim this down to 5K, by using 6K granules. I'm not sure of the exact scheme in use, but it's worth noting that this size would still allow them to pack granule numbers into 12 bits. Such values can range from 0 to 4095, although in practice a few values are reserved as 'markers'. There are about 3,400 6K granules on a 20M hard disk.

As you have found, manufacturers differ as to the 'best' compromise between low granularity and efficient FAT usage. This unwelcome dilemma stems from the simplistic design and implementation of MSDOS. About the only good thing that can be said about it is that it's more efficient than CP/M. The weaknesses of MSDOS become especially obvious when it is asked to look after hard disks - it is not flexible enough to do the job properly, and both Microsoft and IBM should be ashamed of it. One can only hope that MSDOS 5 will be an improvement.


Fourteen months ago I purchased a new Commodore 1701 monitor. My problem is that the left and right border of the screen have a slight 'wave' which makes program lines move horizontally to the left and right as the wave moves up and down the screen. At times the wave is very noticeable but it is always there, even when turning on the power to start programming.
D. V Brown, Bottesford, South Humberside.

A friend of mine recently had exactly the same problem. What you are almost certainly seeing is a 'beat' between the timing pulses used to synchronise the display and the alternation of the mains electricity supply.

A TV or monitor is not too fussy about the exact frequency at which it receives frames from a computer, as long as it is near enough 50 frames a second to allow the set to 'lock on' to the timing pulse at the start of every frame. If not, you get a 'rolling' picture, and have to adjust the 'vertical hold' control to bring things back into step.

The mains frequency is usually about the same as a computer's frame rate, unless you're using equipment designed for the US market. If the mains signal can 'leak across' into the input circuitry of the monitor it will interfere with the stability of the picture, causing the symptoms you describe.

The most common cause of this problem is electromagnetic interference - either a signal leaks from mains cables into nearby video cables, or, more commonly, the magnetic field from a power-supply transformer interacts with a nearby video circuit. I cured the problem with my friend's monitor by moving the computer power supply to a shelf underneath the monitor. It had previously been trapped between the monitor and the wall. Many Commodore devices use similar un-shielded external power- units, so you may the problem goes away if you move the system around, or spread out its components.

If this doesn't help, or you're pushed for space, you could try replacing the lead between the computer and the monitor - some cheap leads are so poorly screened that they work quite well as aerials! If the wave persists, the fault is more serious. The mains alternation is meant to be filtered out from the video circuitry in the computer and the monitor, but a fault in the power-supply at either end of the link could cause it to leak through. Similar instability might be caused by a more fundamental fault, although I think it unlikely.

If the problem is electrical, rather than mechanical, I advise you to find out as much as you can, and then consult a professional repair firm. You can establish whether it is the computer or the monitor which is at fault by borrowing a replacement unit and seeing if the problem persists with each half of your own system. Perform all your tests with the minimum system needed to demonstrate the fault - don't confuse yourself by involving printers and disk drives needlessly.


I recently purchased a Miracle Technology WS4000 modem. This performs faultlessly when connected to an Olivetti M24 using Datasoft Datatalk communications software. However the Sidekick phone dialer, using pulse dialing, causes the system to 'hang' after a number has been dialed. The voice link is established, and pressing space switches the modem off-line, but Sidekick refuses to accept any input. Can you help?
D Berger, Freiburg, West Germany.

Sidekick is an American product, and it has taken a while for its programmers to get the hang of the European telephone system. Version 1.56 cures the problem you mention. There's still one annoying snag - when you hang up the 'phone the software won't automatically disconnect the line for you. This is not too much of a problem, as the WS4000 detects this and 'drops' the line automatically when its 'timeout' period expires. This normally happens after 30 seconds, but the software allows you to change this.


For the past two years I have used a version of LPA Micro Prolog on my Einstein computer, and have experienced the greatest difficulty in implementing mathematical functions. The software cannot perform trigonometry, square numbers or find logarithms. It is also impossible to raise numbers to powers less than one. Could you come up with some simple algorithms to perform these functions, ideally only using addition, subtraction, multiplication a*d division?
Newton Emerson, Tandragee, County Armagh.

You can work out the value of higher functions by repeatedly applying the normal four arithmetic operators. The normal way to apply these is in a 'convergent series' formula - an calculation made up of a sequence of similar parts. Each part works out smaller than the one before; the more you use, the more accuracy you get.

These rules are based on a mathematical principle called Taylor's approximation. They stick to the familiar four mathmatical operations, but I want to introduce some 'shorthand' so that patterns can be seen quickly and clearly.

X ** Y is a quick way of saying 'X written down Y times and multiplied'. X ** 3 = X * X * X. An exclamation mark after a number means 'multiply together all the whole numbers between one and this number'. 3! = 1 * 2 * 3.

This calculation will tell you COS(X) to an accuracy of two or three digits:

COS(X) is roughly 1 - X**2/2! + X**4/4!

To put that another way:

COS(X) is roughly 1 - (X*X)/(1*2) + (X*X*X*X)/(1*2*3*4)

The pattern continues, with parts alternately negated and added, with numbers two up from the one before. This gives you about four digits of precision:

COS(X) is nearly 1 - X**2/2! + X**4/4! - X**6/6! + X**8/8!

Incidentally, this only works for values of X in radians, between 0 and PI. If you plot the graph of COS you will see that it repeats itself, rising and falling across the zero line. Two steps will give you domain over all positive values of X. Negative values cen be 'trapped' and converted if need be. Divide X by Pi and use the remainder in the above calculation. Then negate the result if the whole number of Pi's was odd.

SIN(Y) can be worked out easily - it's just COS(Y+Pi/2). TAN(Z) is SIN(Z)/COS(Z). You can work out squares using logarithms:

EXP(X) is 1 + X + X**2/2! + X**3/3! + X**4/4! ...

Consult the 'School Mathematics Project Advanced Tables', published by Cambridge University Press, for the formulae of other functions, and a plentiful supply of numbers to check your results against! Some of the information in this reply is derived from Chapter M of the Digital Precision TURBO compiler manual, which I wrote with mathematical help from Freddy Vachha.


In the July 1986 edition of PCW, in an article entitled 'Batch Magic', John DeHaven gave a method of using environment parameters as variables in DOS commands. This procedure worked with DOS 2.1 and was very useful, but it does not seem to work with DOS 3.1. Please could you tell me what the equivalent procedure is for DOS 3.1?
B. Farrar, City Treasurer, Birmingham.

The equivalent procedure is an upgrade to DOS 3.2! I've been wheedling Microsoft for a while about this one, and I've contacted John DeHaven in Thailand, who traded me a part-answer for another question! John acknowledged the problem, and protested that "fetching a variable from the environment is firmly part of the MSDOS specification." Microsoft insist that "it is not a documented feature" - in other words, it's something they like to use themselves but which they don't want to have to support.

The changes for MSDOS 3 were quite major, and variable-passing fell by the wayside. Microsoft observed that it "stopped working" in MSDOS 3.0 and 3.1, but returned for MSDOS 3.2. Unfortunately you can't just copy the relevant file, COMMAND.COM, from 3.2 to 3.1, because MSDOS checks the version numbers and complains unless they match. Sounds like a job for a hacker.


I recently got a copy of MASM 4.0, and it is very much improved in terms of speed. Unfortunately Microsoft did something so transcendentally dumb and crippling that I can't believe it. The error messages are now sent to the STDERR device, handle 3, instead of to STDOUT. Under MSDOS this output goes to the display.

I'm very much used to redirecting MASM output to a file called ERRORS. You can do what you please with it then. Now, I can only redirect it to the printer, with this batch sequence:


MASM etc.


This won't work to a file. The only other way I know to redirect STDERR is in the running program, by closing the handle and opening it to another device. But I couldn't find where they are opening the STDERR handle, to change it.

John DeHaven, Wat Pleng, Thailand

This problem crops up because Microsoft re-wrote MASM completely between version 3.0 and 4.0. The old version was in machine code, while the new one was written in C. Microsoft's C compiler appears to have done a fine job on the low-level code, but apparently it doesn't have code to re-direct STDERR in its library. You couldn't find the code that opens STDERR because it's already open when the program starts to run - MASM doesn't open it explicitly.

As Microsoft see it, the problem is that the 'shell' you are using - the command-line interpreter - is not clever enough to redirect STDERR. They suggest you write a program in assembler, C, or any other language that lets you execute another program with an INT 21 instruction. Close STDERR and re-open it as required, before calling up MASM. STDERR will revert to the display when your control program - in effect, a 'shell' - stops.

This seems a rather roundabout solution, but it may have to suffice until the gurus at Microsoft find it sufficiently annoying to want to fix it - or release the shell THEY'RE using!


Like many home computer owners, I started with a ZX81. This is now lying around gathering dust. Would it be possible to use the 16K RAM pack as a printer buffer?
Hugh Weller-Lewis, Ware, Hertfordshire.

Yes, it would probably be possible. But the memory in that RAM pack now sells for about a pound, in one or two chips. You'd need two RS-232 channels, or about 20 TTL port lines for Centronics printers, plus lots of expensive connectors, buffers and ribbon cable. You'd have to write a machine- code bootstrap ROM and buffering software.

Consult printer manuals to find the purpose and timings of interface pulses. Adrian Dicken's Spectrum Hardware manual, published by Melbourne House, contains lots of information that is also relevant to it's simple predecessor, the ZX-81. It also documents the hardware and software of a parallel printer port. Building a port is a sensible staging post en route to building a buffer.

It can be done, but by the time you've finished you won't be able to see the 16K RAM pack for other bits and pieces. The kits on page 267 of the Maplin Electronics catalogue (in most newsagents) may help you to get started. It's likely to be a big job, in hardware and software terms, but it's quite within the capabilities of a keen hobbyist. Don't expect to save any money! It can be done, but by the time you've finished you won't be able to see the 16K RAM pack for other bits and pieces. The kits on page 267 of the Maplin Electronics catalogue (in most newsagents) may help you to get started. It's likely to be a big job, in hardware and software terms, but it's quite within the capabilities of a keen hobbyist. Don't expect to save any money!

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