Previous column ComputerAnswers
Next column ComputerAnswers
ComputerAnswers Column 12
COMPUTER ANSWERS DECEMBER 1985
Copyright 1984-1989 Simon N Goodwin
COMPUTER DATING FOR COMPUTER SOFTWARE
We often have to face situations where a customer is asking for a very special package to run under MS-DOS. Although we suspect that the package exists somewhere we do not know where to start looking.
I believe it is difficult to find one publication completely covering the subject, but maybe you can recommend one or more publications which would serve the purpose.
Jean-Claude Elias, Amman, Jordan.
Several of the monthly micro magazines publish lists of business software, but these are invariably incomplete: there so many packages, advertised in so many different areas, that it would be impossible to assemble a full list. The rate at which packages appear and disappear means that such guides are inevitably inaccurate as well as incomplete by the time that they are published. Even if you can find what you want in such a guide - and they tend to concentrate on 'popular' applications rather than obscure ones - you then have the problem of tracking down a dealer: some of them seem to appear and disappear as fast as the packages they sell!
The best way to find obscure packages is to scan the advertisements in a range of magazines: PCW is the biggest such title published in the UK, but it may also be worth examining Practical Computing and magazines which specialise in the computer you wish to use. If the software you need is aimed at a 'vertical' market you may find what you want more quickly by scanning through trade magazines for the appropriate field - most such titles carry advertisements for specialist packages.
If this sounds too much work you may get faster results from a marketing agency, such as 'Software Information'. At last the Micro industry is waking up to the fact that it makes a poor job of promoting 'specialised' packages - these agencies operate a kind of 'computer dating' for software users and suppliers, at the expense of dealers who hope to profit from increased sales.
Software Information maintain an up-to-date list of packages for most machines, together with a list of dealers. The dealers pay to have their wares promoted by the company, so the service is free to the potential purchaser. Callers ring 01 831 0071 and state their requirements. The agency 'phone back later with details of packages that fit the bill, and the names and addresses of appropriate dealers from their list. Overseas inquiries are welcome.
The slight snag of using such a service is that you only hear about products available from the dealers on the books of the information service. This doesn't matter if you can't find the program you need any other way, and you don't have to act upon their recommendation in any case: you can always use the service as a 'back-up' for your own enquiries.
UNIX, 'C' AND ALTOS POLLING PROBLEMS
Recently I learnt to program in the 'C' language but I don't know how to write 'C' functions which are equivalent to BASIC's GET$ or INKEY$. Our compiler ('cc') is a full implementation of 'C', as specified in Kernighan and Ritchie's book, 'The C programming language'.
I tried to use the routines in the book, but with no success. Altos have provided a screen package called CURSES in which they provide the function 'getch()' to do the job. This consumes large amounts of memory - my 512 bytes of source code produce about 12K of object code and still does not function properly. I hope you will be able to provide a better function to do the job.
A. F Segar, Al-Khobar, KSA.
Firstly, a pre-emptive apology - we do not have the time or space to provide full-scale programming solutions in Computer Answers. However we can point out the likely cause of a problem, and explain how we would go about tackling it.
Although the syntax of the 'C' language is defined in the book you mention, the input and output commands are not fully specified. The designers of the language recognised that such facilities will inevitably vary from one machine to another. They deliberately avoided building such facilities into the core of the language. In 'C' input and output are performed by calling functions, rather than through the use of specialised routines (such as BASIC's INPUT, INKEY$ and so on).
This approach makes it easy for systems programmers to move a 'C' compiler from one machine to another, especially as 'C' compilers are usually written in 'C' themselves. The implementors need only re-write the functions that their compiler needs, without delving deep into machine-code. The snag from the user's point of view is that the precise performance of input and output functions may vary between one type of computer and the next.
In this case it seems that the READ function will not return a 'dummy' character with the value zero when there is no data immediately available. This may stem from lazy implementation or incompatibility between the terminals you are using and the 'device drivers'. These are the machine- code routines at the heart of any Unix or Xenix system; they handle the nitty-gritty details of communication with external devices. These routines vary a great deal between one implementation of Unix and another, since they communicate with the hardware at a very low level.
It is possible that the terminals which you are using are not configured correctly. Check this by consulting the person who installed the system, and reading through the configuration instructions. Make sure that the terminals that you are using are set up to match the requirements of the device-drivers.
The Altos terminal package consumes a lot of memory because it contains several functions associated with screen-handing which you do not require. When you #include the CURSES package you tell the compiler to process the entire contents of the associated file. Unfortunately the 'source-library' feature of 'C' mean that most compilers are not clever enough to eliminate unused routines from the final output file, so much of your 12K object file contains routines that are never called by your test program. This would not be the case if you were using a more sophisticated language, such as Ada.
The solution is to extract the required routines from CURSES, and discard the rest. All of the CURSES routines should be in a standard text file, which you can copy and edit. In principle this is a simple operation, but in practice you may find that 'getch()' interacts with other routines and variables declared in the file, so it could take you a while to discover which parts can safely be discarded.
It is best to remove routines one by one if you're not certain whether or not they are needed. You might be able to save time by contacting the person who implemented the package, but it tends to be difficult to track such people down without a lot of time, persistence and a big telephone budget!
Since you say that the screen package does not work properly in any case, it is likely that you will need to adjust the configuration of your system once you have reduced the size of the package. Check that your terminals transmit each character as it is typed - some terminals store characters and transmit a whole line at a time. Some terminal interface boards (inside the computer) work similarly. In both cases you should be able to inhibit this 'buffering', but you may find that system performance suffers as a result, since the processor will be interrupted by the terminal more often. This is the price you pay for interactive computing, and one reason why micro networks often out-perform multi-user systems on larger computers.
I have got an ACT Apricot, and would like to know if there is any sort of club for Apricot owners and users.
Magnus Unemyr, Jonkoping, Sweden.
As far as we know there is no established club for Apricot users, but there are plans to start such a group. Unfortunately we were not able to contact the organiser for further details before this issue went to press. You should be able to find out more by writing to F.S Cartwright at Rockside, 13 Worley Ridge, Nailsworth, Gloucestershire GL6 OPD, UK. It would be polite to send an SAE, or an International Reply Coupon if you are writing from outside the UK.
LIES, DAMNED LIES AND BENCHTESTS
I would like to know the outcome of any benchtests carried out on either the Atari 520ST or the Acorn 32016 second processor.
Would the Atari 520ST be compatible with Apricot F1 software, as they both use CP/M but have slightly different processors?
Michael Charnley, Bradville, Milton Keynes.
PCW reviewed the Atari 520ST in the June 1985 issue. There were no benchmark timings for Personal Basic in the article, because the interpreter was not finished, but I would caution you against giving them much credence in any case, since the Kilobaud benchmarks (on which the PCW tests are based) bear about as much relation to the 'power' of a computer as your inside leg measurement does to your athletic prowess.
Benchmark programs are useful in the sense that they give you some feel for the speed of a Basic system when performing simple tasks. You can extract vaguely interesting information by comparing the figures, such as the speed of a subroutine call or the speed difference between references to a numbers and variables. The snag is that benchmarks do not measure many other features, such as accuracy, string-handling time (which dominates many business programs) the ease with which a language can be extended (fast interpreters are often hard to extend) and the change in speed as program size increases.
Modern sixteen bit computer benchmarks often appear poor in comparison with older machines, since they use software designed to cater for large programs efficiently - this imposes a misleading overhead on short programs. Older Basic interpreters, such as Microsoft Basic, limit the user to 64K of code and slow down dramatically as programs expand towards that limit.
Modern computers show their power when programs become larger and more complex. The 'SuperBasic' used on Sinclair's QL can cope with 600K programs with little speed degredation. Its disappointing benchmark figures also stem from the way that the interpreter is designed to allow new commands to be added easily. This was deliberately done so that users could eliminate Basic 'bottlenecks' with 'add-on' commands for sorting, coping, searching and other time-consuming operations.
Beware of 'optimised' timings which make computers look stunningly fast on benchtests. For example, some of the test timings for BBC Basic, used on Acorn computers, are slowed by a factor of four if a few extra variables are declared and the loop counter is re-named!
Given these limitations of benchmarks, why do we bother? The PCW benchmarks do have some value as a limited 'index' between machines, albeit a subjective one. We also feature alternative tests, like those in the 'Fast Timing' article in the July 1985 PCW.
Execution of a Basic program involves the interaction of hundreds of routines and dozens of circuits; there is no brief group of tests which could give a comprehensive profile. The best way to measure any computer is to use it. In the case of a new machine, you have to make do with the opinions of the reviewer and the published specification.
Be wary of simplistic measures such as 'clock speed', which tells you nothing about how much the machine can do between one tick of the clock and the next (this depends on the processor and its surrounding circuitry). Remember that software is often more significant than hardware speed, and a benchmark for one language tells you little or nothing about the speed of other languages or compilers.
That said, the 32016 is a more sophisticated processor than the 68000 in most respects. I expect the 32016 to be significantly more powerful than the 68000, assuming that it is coupled with an efficient memory organisation - the Atari, QL and Macintosh are all slowed down by the fact that the processor and display electronics must 'share' access to memory, whereas the 32016 second processor should not be constrained in that way. However, there is much more software for the 68000, and without software a processor is nothing more than a sliver of expensively-processed sand.
Turning to your second question, Apricot software will have to be re-written (or at least re-compiled) for the Atari. The processors used in the two machines are much more than 'slightly' different.
There are stories that an 8086 emulator will be produced for the 68000, but the stories are rather misleading. Such an emulator will be very slow, very complex, and not totally compatible, due to the differences between the respective machines' hardware. It is true that both the computers you mention have operating systems with names starting with the letters 'CP/M', and a similar interface for programmers and users, but the code is completely different for each.
Programs written in a high-level language (such as 'C') may be converted fairly easily (with, say, a quarter of the effort needed for a total re-write). Machine-code programs, which tend to be the most powerful, will need to be re-written completely - there is no such thing as a Rosetta Stone for computer software. That said, the similarities between the operating systems should help users who want to swap their attention, or their data files, from one machine to the other.
Could you tell me how to convert an assembly program into machine code for the IBM PC? Could I use 'Debug' to acheive this? If so, how? I find the Debug menu very difficult to understand.
Anita, No address supplied.
In theory you could use Debug to enter programs, just as you could hammer nails into a wall with your fist - Debug is not designed for that purpose. Debug is a tool for experienced programmers who wish to test and make minor modifications to machine code.
You need an Assembler. This is a program which translates mnemonics - the text of your assembly-language program - into binary instructions which can be directly executed by the PC's processor. You should be able to order an assembler from any PC dealer - there are several such programs available, including the Digital Research assembler which is supplied with a set of 'debugging tools'. Be warned that assembly-language programming is pretty tough going.
LIGHTING UP THE TORCH
I am operating a Torch computer with a BBC Micro and Torch colour monitor. I recently purchased an Apricot F1, expecting that it would be able to drive the Torch monitor. Alas, it will not. The input on the Torch monitor is a six pin DIN socket and the output from the Apricot is a nine pin D-type socket. Apricot advertise that their machine will run any IRGB monitor - is there any way, please, that I can get a lead made up? I have very little technical ability and the work would have to be done by a dealer.
P.E Kemp, Drayton, Norwich.
Apricot now say that the F1 will work with 'most' IRGB monitors - the 'I' is important, since it indicates that the computer generates an 'Intensity' signal - if your monitor will not accept this you will be restricted to eight colours, rather than the 16 normally available. The Apricot generates two separate synchronisation signals - these will have to be combined for a monitor which expects 'composite sync', and some electronics may be needed to ensure that the signal polarity is correct.
Your local Apricot dealer is United Sumlock, of 37 Prince of Wales Road, Norwich (0603 617083). They should be able to sort out a lead to connect the Apricot and the monitor together, although you may find that some small-scale modifications to the monitor are required. You may end up having to choose between having a monitor compatible with the Torch and having one compatible with the Apricot.
This letter should serve as a warning to other micro purchasers - if you want to use part of your existing set-up with a new device you should make sure that the components are compatible before parting with your money. You can't afford to rely on sweeping statements about compatibility, especially if they come from marketing literature - there's no way any supplier can guarantee that a computer will be compatible with every peripheral on the market. Any professional dealer will be happy to sort out this sort of problem for you - but it is easier, and often cheaper, to obtain help when there is a substantial sale in the offing.
THE SHARP END
I have had great success over the past three years with C P Electronics Supabase program on my Sharp MZ-80A. But now I have a problem. The program tape will no longer load and I have been unable to contact Mr. C.D Hearn of C P Electronics who wrote and supplied the program. I originally obtained the programs through C P E's advertisements in PCW and wonder whether you can tell me where I can obtain a replacement tape?
As you will appreciate, I would much prefer not having to start again to replace over 400 entries each comprising 10 or 12 fields which are held on my present Supabase data tapes.
Alan Smith, Epsom, Surrey.
I'm sorry to say that I have drawn a blank on this one - I've 'phoned round the dwindling list of Sharp software suppliers without being able to find anyone with a copy of Supabase. The original suppliers have moved and left no forwarding address. If Mr. Hearn, or anyone who can obtain a copy, is reading this would they please write to Computer Answers, and we'll pass on the message.
Link to the top of this document
Link to the main index
Previous column ComputerAnswers
Next column ComputerAnswers