Previous column ComputerAnswers    Next column ComputerAnswers


ComputerAnswers Column 10


Copyright 1984-1989 Simon N Goodwin


I read, with interest, the article on MIDI, the Musical Instrument Digital Interface, in May's Personal Computer World. I am interested in writing home musical software and would like more information.

First, could you recommend any books on music and computing which are not specific to a machine or sound chip, and second, where could I get detailed information on MIDI codes and synthesiser-specific codes?
I Smith, Ripley, Derbyshire.

A good introductory book about computer music is 'The Musician and the Micro' by Ray Hammond, published by Blandford Press at £4.95.

If you need more information about MIDI than was in our article you will probably need to contact Sequential Circuits on the continent. They will provide a full MIDI specification for a few pounds: Sequential Circuits Ltd, Post Bus 16, 3640 AA Mijdrecht, Holland.

Alternatively, you may be able to wheedle information out of synthesiser dealers in the UK, if you express an interest in their products. The May 1985 issue of the specialist magazine 'Electronics and Music Maker' is also worth examining - you should be able to find a copy at your local library.

If you'd like to get into MIDI at a very low cost, and you already own a Spectrum and Interface 1, you may be interested to learn that the Quicksilva game 'Zombie Zombie' has the circuit diagram of an incredibly simple MIDI interface printed on the cassette insert. The game uses this circuit to provide sound effects on a powerful Yamaha DX-7 synthesiser - for those Spectrum owers lucky enough to own one - but the circuit is appropriate to any MIDI synth and only costs a few pence to build.

If you use this approach you'll have to write your own software. The Spectrum's network port (used to generate the MIDI signal) is at I/O address 247; you can produce a signal at the network socket on the back of Interface 1 by alternately writing odd and even values to that port, using the OUT instruction. Some experimentation will probably be needed to get the timings right. You may find Basic too slow for this purpose, but a language like Forth should be well-suited to the task.


I have an Amstrad CPC-464 with a DDI-1 disk interface. When I LOAD a Basic program from disk and then try to MERGE another Basic program I usually meet an end of file error. A subsequent LIST shows that there is now no program in the memory. Basic programs can be MERGEd from tape without any problem.

I would like to know if this is a firmware bug (rather than a fault on my system) and if you know any way of getting around it, short of resaving programs on tape and then merging them - a rather laborious process.
P.G Clarke, Stockport, Cheshire.

Your problem stems from a bug in the disk system software. The EOF error occurs because programs are - by default - saved in their tokenised form, where they contain lots of 'invisible' control characters to convey information such as line-lengths and numbers. If any of these characters happen to have the code 26 (Control Z) they are treated as end-of-file markers by the disk system, which then prematurely stops reading the file.

There are two solutions to this problem. The simplest is to save programs in their textual form, rather than tokenised. This is done by appending a comma and a letter A, standing for ASCII, to the normal SAVE command. ASCII is the standard code used to represent text inside micros. Such a file contains no spurious control characters (unless you're have the bad habit of putting control characters inside program strings), so it MERGEs perfectly.

The snag is that the file is longer and transferred more slowly than the tokenised version. If this is irritating, contact Amstrad on 0277 228888, and they will send you a short 'patch' program which corrects the code used for MERGE so that it reads up to the logical end of the file, rather than up to the first end-of-file character.


I run an Apricot F1 with Omicron, Cardbox and Select software. My problem is simple but very frustrating. The cursor does not flash.

My Apricot dealer and ACT both say 'Sorry, there is nothing we can do'. Can the fault really be in the unmodified MSDOS v2.11 sb? This letter is hand-written because my secretary now refuses to use the word-processor because of the saga of the disappearing cursor.
J.A Slater, Blackburn, Lancashire.

ACT tell me that the flashing cursor which is a feature of the Apricot PC and XI machines has been replaced by an unblinking one on the cut-price F1 machine, which lacks hardware to make the cursor flash. Even so, it should be possible to produce a blinking cursor in software (as on the computer which I am using to type this answer) but it will take some operating-system-level programming. In short, you may be stuck with a static cursor.

The lack of flashing cursor hardware shouldn't make the cursor disappear altogether, however. If this problem only occurs when you use certain programs, you probably have an applications software problem; make certain that the operating system and software you are using are specifically meant to run on the Apricot F1, and, if this is the case, explain your problem to the software vendor or publisher.

If the 'fault' happens on all your programs it is more likely to lie in the operating system or the user. Most operating systems recognise a certain sequence of characters as meaning 'turn the cursor on' or 'turn the cursor off'. On many machines, these characters are Control O and Control N, respectively; the relevant characters for the Apricot should be in the User Guide. If the cursor disappears a while after you have started to use the program, it could be that you have accidentally hit the 'cursor off' sequence. The solution is to type 'Cursor On' and continue where you left off.

Neither ACT nor anyone else I spoke to has ever heard of this problem before, so it seems rather likely that it is of an operational nature rather than an inherent property of your hardware or software.


I own a Sharp MZ-700, which was bought from your country about a year ago. Though I find the machine a worthy one, I cannot say the same for the software or add-ons. Therefore I have a number of questions.

Do you know of any CP/M system for the machine? Are there any good Lisp, Prolog or C interpreters or compilers? What about other languages?

Is there a low-cost RS-232 serial interface, modem or 80-column card? Finally, which is the best chess program available for the machine?
P.E Fouliras, Salonika, Greece.

CP/M is not available for the MZ-700, and it is not possible to read CP/M disks unless you're willing to write some intricate machine code. As far as I know the languages you mention are not available on the machine; Hisoft's subset of C should be portable to the Sharp, but I don't think a conversion is likely. There are Pascal and Forth compilers, available from Kuma and other Sharp dealers.

Peterson Electronics, of Academy Street, Forfar, Tayside DD8 2HA specialise in add-on hardware for the MZ-700; they offer an RS-232 interface and a modem, but no 80-column card. Back with software, I think you may find the quality of chess programs on the Sharp rather poor; in any case you can obtain a full list from Kuma Computers of Unit 12, Horseshoe Park, Pangbourne, Berks RG8 7JW.


In your review of the Tatung Einstein it was stated that it had a 32 character per row video chip, but it is fooled by software to give 40 characters. Is it possible to do this on other computers as well, giving say 60 or 80 columns per row?
M Gottlieb, Edgware, Middlesex.

You can squeeze extra columns onto the screen of any micro which has a 'bit-mapped' display - that is, a display where individual points can be lit or extinguished individually with software. On other types of computer, such as the Commodore PET and Sharp MZ-80K, it is only possible to generate a specific set of (usually 256) symbols - you can't control the points individually.

The Einstein, like the BBC Micro, Atari XE and many other machines, can work either way. The second scheme has the advantage of speed and economical use of memory, since it is only necessary to store one byte to produce an entire character on the display, but it restricts you to a single size and shape of character.

It is quite possible to produce characters on a bit-mapped display by lighting and extinguishing groups of points - in fact this is the only method available on the Sinclair Spectrum and Acorn Electron. The less points you use for each character, the more you can cram onto the screen, but the cruder and harder to read the display becomes.

The practical limit beyond which it becomes impossible to represent a full alphabet probably comes when characters are four points wide and six high. On this basis you could get 64 columns and 32 rows onto the display of the Einstein or Spectrum, since they offer control over 256 dots horizontally and 192 vertically. 64 columns is the practical limit for most home computers used with a TV set. You may well find that hard to read, in which case you could go for characters six points wide and eight deep - this gives 40 characters per line on the Einstein; a similar format is used by the Memotech, and in the Hobbit adventure game for the Spectrum.


I have recently purchased the new Oric Atmos keyboard because I am hoping to buy the Oric word-processor. To my surprise I received the Atmos ROM as well. The problem is that most of my software only works on the Oric ROM, and not with the Atmos. Is there anything I can buy or build that will enable me to switch from one ROM to the other?
J Green, Widmer End, Buckinghamshire.

This is a problem for users of a variety of machines which can run more than one ROM; the Sinclair ZX80 was the first popular machine which could run two different Basic ROMs. The solution is quite simple, but it requires experimentation and some precise soldering - we would only recommend it to those confident of their ability to work with digital electronics. Strangely, I don't know of any firm offering such a service.

The ROM, or Read Only Memory, contains the instructions which give the computer it's 'personality' - the commands it recognises, the editing mechanism and so forth. The processor indicates that it wants to read the ROM by generating an 'address' which corresponds to the ROM. Logic inside the computer detects appropriate addresses, and a special signal, called 'chip select' is produced whenever the ROM is to be accessed. The ROM only then looks at the address to decide exactly what information it must supply.

If you connected two ROMs to one socket (by connecting all the pins together) you would run into problems because they would both try to present information at the same time and in the same place, but the information would differ and be muddled together. The effect is a little like trying to read two books at once by taking letters alternately from each! What you need is some way of 'putting one of the ROMs to sleep' when you are using the alternate one. You can do this by only allowing the 'chip select' signal to go to one of the components. If you direct the signal to the Oric ROM you will be able to use your old software, whereas new programs will work when the signal is passed to the Atmos ROM.

You should connect all but the chip select pins of both ROMs to the socket. This is commonly done by soldering one copmonent to the back of the other ('piggy-backing'), folding the chip select pins out from the packages. It is probably wiser to build a small circuit board to hold both chips, unless you're very sure of your soldering. Keep interconnection lengths to a minimum, whatever you do - there are signals running around those chips at a rate of millions of pulses a second, and it is easy for them to get lost or cause interference.

The next step is to take the chip select signal from the socket and to the ROM pins, via a two-way (changeover) switch. You should not operate the switch while the computer is turned on; it may be worth enforcing this rule by using a three-position double-pole switch, with different ROMs enabled at opposite ends of the switch travel and the DC supply to the computer cut off in the middle position.

The location of the chip select pins on the package will depend upon the type of ROM you are using - you'll need to look them up in a catalogue or trace through the computer's circuit to find the chip select line.

This discussion pre-supposes that you aim to replace a single ROM with a single replacement, and they both work without modification in the same socket. It also assumes that the ROMs do not impose a significant load when not selected; this is generally the case, but should be checked if you are not sure. If you are replacing a set of chips with a different number of components you will need to work on a socket-by-socket basis.

Some ROMs are turned on when the chip select signal is high (logic 1) and others respond to a low level (logic 0) - if you are replacing one type with another some circuit changes are needed, or the new ROMs will only assert themselves when they are NOT wanted! This problem is most common when replacing EPROMs with ROMs.


I have an Amstrad CPC-464 and I wish to write certain simulation programs. In order to verify them I need to know the formula of the random number generator (congruence formula) of the machine; unfortunately it is not in the book. If you don't know it, can you suggest a method to crack it?
N.A Papadakin, Athens, Greece.

No one at Amstrad was able to give me the formula used by the generator, which is apparently buried deep in the ROM. Almost all micros use an integer formula of the form: SEED := (CONST1 * SEED + CONST2) MOD CONST3 where SEED is used as the basis of each 'new' random number - each number being generated from the previous one - MOD is the remainder function (so 10 MOD 7 is 3) and CONST1, CONST2 and CONST3 are constant values, CONST1 and CONST2 are usually fairly small in relation to CONST3. Preferably all the constants are prime numbers.

You should be able to see that successive calls return a jumbled sequence of numbers ranging in value from one to CONST3, which repeats itself every CONST3 calls (I hope Mike Mudge doesn't write to me about this!).

Some computers, such as the Apple 2, jumble the sequence still further by using the code or timing of the last key-press in place of CONST2. Luckily the Amstrad doesn't do this, or analysis of the sequence could become extremely difficult.

Your problem should be solved if you put the command RANDOMIZE 22 (or any other constant number) at the start of your program. The RANDOMIZE function provides a new 'seed' for the random number generator, which means that you always get the same sequence of numbers after using RANDOMIZE with a specific value. This makes the output of the generator predictable, so that it can be analysed reliably.

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