TAPES...Where would we be without them? Without any form of standard for the very non-standard world of the Elk, that's where and for what? No matter how hard I have tried, it is impossible to make my Elk a purely disk only system. They might be horribly slow and prone to unreliability but throwing out the cassette is not an option I will take.

First of all most, if not very nearly all, software is tape-based. I'm not particularly a games person but I have my favourites and they arrive on tape. What I then do with them is up to me (copyright permitting). More to the point, the lack of a standard disk system for the Elk means the only guaranteed way to send data to another user is via tape. Beeb users are lucky in the respect that DFS is the disk system. ADFS is more of a personal thing for them.

That said, tapes do deteriorate. They are particularly prone to absorbing moisture from the atmosphere [The chemical term is hydroscopic, fact fans! - Will]. Try leaving one in a kitchen full of steaming pots for a few days and then using it. You will find the particle coating quickly lifts from the tape and collects on any of the rubbing surfaces like tape heads and cassette casing. This agglomeration only increases the tendency for the tape to shed its coating further and in no time you have a useless tape.

Damp houses produce the same effect - the damper they are the sooner the symptoms become catastrophic. Because water is such a common compound, it is impractical to create a dry zone to keep your tapes in, and they continue to absorb water until they become saturated and unplaybale. It may take hours or years but it will happen.

Anyone doubting the veracity of the above should consider why prerecorded audio cassettes are so much cheaper than the equivalent LD or CD. LPs deteriorate because of the unavoidable wear from the needle, but will survive in a damp climate. Cassettes suffer from both and the audio-buying public recognise the fact.

Before you ask about floppy disks, remember that there are no touching parts. (Pretty damn close - I mean you can't actually see the gap between head and disk!) Therefore, it never occurs that the coating is lifted from the disk by the head. Water does not affect magnetism. After all, think of the North Pole. This does not mean you should stop cleaning your drives.

It does pay to get a good data tape player, although what counts as good is obviously a matter of luck in many cases. One of the reasons tape fell into such disrepute for personal computers was the lack of specialist hardware for data cassettes. The requirements of data storage/retrieval and audio storage/retrieval are very different. With audio, the analogue source (voice, strings, steam engines) becomes analogue loudspeaker output via analogue, or possibly digital, storage; both work equally well. Computer cassettes require the transformation of digital output to analogue storage for subsequent conversion to digital input! An amazing tortuous process carried out by the CFS interface, fraught with uncontrollable variables such as tape condition, cleanliness of tape heads and the quality of the original recording. The least you can do is get a good tape player, surely now?

Last but not least is the choice of tape for data storage/retrieval. I found several times that it is not the case that a high powered audio tape will be best for your Elk cassette. Far from it. The increased high frequency response of Chrome or Metal cassettes makes for more confusion than that of a reputably branded bottom grade ferric Type I. A case of don't feel the quality, measure the width!

ISSUE #6 ELECTRON...I had one of these and they are very different inside - not least because of the extra ICs but the overall board layout. I did not detect any more "functionality".

It is not necessarily a universal feature of these boards, but I believe the cassette tuning frequency on my Issue 6 was different from that of the standard Issue 4. I certainly had uncommon trouble sending tapes from 4 to 6. It wasn't a case of "Data?" messages - the Issue 4 CFS just wouldn't read anything as there at all - even using the same player for both machines! Sending 4 to 6 was possible though. I can only think that it is the tuning frequency that was the problem.

There is nothing that I'm aware of in the Advanced User Guide about issues of the Elk. I called Pres to ask if they knew of any differences and was told I was the first in all these years to ask the question! No, they said, all their products work perfectly well on either board and they had detected no extra functionality.

All I can suggest is that the excessive use of the ULA is eased by the extra DRAM (I think it is) and the ULA is improved to get round the problem of dying the way it does in the spring-mounted issue 4 variant. But it is a very different board.

The 205,000 number is common to all Elks that I've met.

Sim City...Reading Alan Davies' letter made me dig out my copy of Sim City to remind myself what a good game it was. I bought it some time ago and for some reason failed to follow my usual practice of making a back-up. Imagine the horror when I discovered the Elk version was shot to ribbons with "Block?" and "Data?" messages all over the shop. Eventually (Hours later, diarists!) I cleaned it up enough to make a backup and restore the original source tape to a useable state. I suspect Alan has a similar problem. Sim City packs a lot into the Elk, making it prone to "Bad Program" messages at an uncommon stage. If the city file is corrupted, it might throw a "Bad Program" error where a "Data?" would usually be. I've also noticed that sometimes it will load in Turbo mode, but occasionally gets no further than the first loader. Anyone else had this?

UPGRADES...I've spent considerable time with an Acorn Archimedes and they are infinitely preferable to the badly-thought-out PC. The sad fact is, however, that without a PC emulator on board, and very often with, they will not run the packaged software that it is becoming necessary to be familiar with if your want an office job. LOTUS 1-2-3, for example. The reasons for upgrading to a 32bit Acorn must make allowance for the fact that even after spending all that money, you still won't be able to run most PC software. Wicked but true. As for buying an Archie for the BBC emulator, that has to be a bit like buying a Mercedes and installing posh Esgrot seats, surely?

It is this de facto PC standard that drove me to such a vigoruous denouncement of DFS. MS-DOS is the standard for all PC (Windows not withstanding) and the concept of sub-directories and their efficient management is quite demanding. I benefitted enormously from my exposure to ADFS when first faced with a PC. Had I only known DFS, I would have been reduced to tears within seconds.

All Acorns are belting good little machines and Elks are a joy for their ease of use and friendly interfaces. I wish I could use my Elk at work, really I do.

For this reason, I am waiting expectantly on Derek Hilton's research into DOS-COPY for the Elk. The ability to read/write DOS format disks would be of immeasurable use to me, professionally and socially. In general terms it would give the old Elk an enormous boost for would-be awfers like moi.

View...I really reckon to this WP, but am I only one who was a bit confused by Bill Woodall's opening paragraph to View in EUG #8? As far as I know View for the Elk came in one version only (E1.0) and contained the same functionality as View 3.00 for the Master. A summary of the differences wouldn't amount to much, but View 3/E1 is much more useable than the common Beeb versions (2.1 and 1.4).

The NAME command exists in View 3/E1 and is useful with skeleton files (eg LOAD skel 0 NAME bank5), easily handling the path structures of ADFS.

I've used View 2.1 on the Beeb and it's nothing like as friendly without the FUNC key. There are three possible combinations of SHIFT, CTRL and the F key to get the functions available in one combination on the Elk. It also lacks the features I rely on in View E1. Moreover, it has irritations such as the need to issue a NEW command before anything can begin!

I suspect the Master implementation of View 3 also calls for varying key presses to get a command, making E1 the friendliest version around! F-keys, along with screen mode and colours, can be defined from a BASIC program than ends by calling up View. I've included a sample menu program to show what I mean. It assumes a Pres AP2 and an at least med.res monitor. Change *LANG 2 to *W. if you are without an AP2 ROM. Tape users may want to edit the references to external files (Printer Driver, *BACKUP, etc). I make no apologies for its quick and dirty look.

COBOL...Yeah. I'm supposed to speak this for a living and when I retrained I was given excellent instruction in the use of structured COBOL and remain convinced that it is ideally suited to complex systems when used in a structured fashion. Sadly it rarely is, and my life is made miserable by meeting COBOL code that has been written in the most obtuse way imaginable, riddled with GO TO commands, illustrated by such comments as "@*$ knows what this bit does, but it looks pretty damn meaty to me!".

The situation is not helped by the current obsession with C, and its variants, which are prettier but much weaker than COBOL. (The Land Rover of computer languages - it goes anywhere but consider yourself stuffed if you have an accident involving one). As a professional programmer, my advice to Christian Weber is by all means learn COBOL but get some C as well. I recommend "Parkin", available from WHSmith.

Through no fault of my own, I am not running the south west branch of the retirement home for shagged out old 8bit Acorn computers. One of the more pleasureable aspects of this philantropy is the software my patients often bring with them.

Such is the history of this version of Mornington Crescent which is an implementation of the old parlour game. It was originally a Beeb-only effort running in boring black and white in Mode 7 and was typed in from The Micro User sometime in the 80's.

I have converted it to run on a 64K Elk in dazzling London Translivery, with a slightly more human text interface, an explanation of the simple rules and removed the more irritating routines the original author thought fit to include. I've also debugged it to a degree - correcting a couple of typing errors in the data statements that make up the bulk of this program (and make it too large for ordinary 32K machines!). There are still two points where it doesn't run smoothly; one invariably, the other more periodic. Bit like the service on London Transport itself, I suppose. Have fun finding them. Oh yes, and it's not the current version of the Tube Map either.

For those of you who may have picked up on the "Sorry, I Haven't A Clue" radio panel game version of this game is entirely separate and uses few of the gambits frequently heard there. In particular I regret the absense of the Took double-twist, and the Rushton grumble is unplayable in any non-radio format of the game.

However, I think on this occasion a computer implementation has managed to capture the basic flavour of the gameplay and I anticipate cheery EUG readers spending a deliriously happy few minutes before being bored stupid by it.

Christopher Chadwick
Swindon, Wilts
EUG #9

Chris Chadwick