| ★ APPLICATIONS ★ DIVERS ★ SPECTRUM TO AMSTRAD (YOUR COMPUTER) ★ |
Transplant surgery - a great success | Spectrum to Amstrad Part II - completing the transplant |
Richard Sargent takes us through the delicate procedures involved in the transfer of Basic and data programs from Spectrum to Amstrad. Spectrum owners who find the memory and storage of their machines too limiting are likely to turn to one of the Amstrad micros as a replacement computer. With Spectrums, especially the rubber-key variety, having little or no second-hand value, the machine upgrade will probably result in there being two computers in the house. Would it not be useful if data and Basic programs could be transferred from the Spectrum to the Amstrad, thus obviating the need to type thousands of characters into the Amstrad? The programs with this article will do that. Anything which a Spectrum can normally LPRINT or LLIST can be sent via cassette tape to an Amstrad. The Spectrum can be an old 48K machine, a Spectrum + , a Spectrum 128 or the new Spectrum 128+2; the Amstrad can be a CPC464. CPC664 or CPC6128 and although it is more convenient to use the Amstrad disc system, a tape-only CPC464 system can be used if necessary. Four programs are involved. At the Spectrum end, a single machine code program resides in high memory and provides the code for a special SAVE routine. The routine re-routes LPRINTs or LLISTs automatically to the cassette, writing the data in a way which can be read easily by the Amstrad. The other three programs fit into the Amstrad. One is a machine-code LOAD routine based, naturally enough, on the Spectrum LOAD routine, which is explained expertly in Logan and O'Hara's book The Complete Spectrum ROM Disassembly. This routine is handled by a Basic program, either program three or program four, depending on the size of the file being transferred. The machine code should be left severely alone. No knowledge of Z-80 machine code is needed to run the transfer program but the Basic program can be tinkered with and modified to meet individual needs. There has to be a catch to all this, or course, and I suppose I should mention it now before anyone shouts “computer compatibility” and rushes to buy two CPC6128s. The programs are called File Transfer programs - note well the word is transfer, not translate. To put it bluntly, although the programs are guaranteed to move a Basic program from one machine to another, it is only the simple varieties of program which RUN immediately in the new machine. Amstrad Basic is not Spectrum Basic and there are one-hundred-and-one things in Spectrum Basic to trip an unsuspecting Amstrad into syntax error. Translation, where necessary, is achieved at the Amstrad end of the system by human intervention. Two methods are possible. If the Amstrad has no word processor fitted, you must LIST the Basic program and make the necessary changes using copy-cursor editing. That is faster than any editing you will have done on the Spectrum but still leaves much to be desired. Loading the Basic program into a word processor such as the Amor Protext is the second option, allowing fast alterations to be made with the global replace command. Programs which use fancy graphics will take some time to translate, whereas programs containing large proportions of ASCII text and ASCII data - such as an index of a record collection or an adventure game - should be easy to translate, especially once the differences between the eccentric Spectrum string slicing and the more normal RIGHT$ LEFT$ of the Amstrad are appreciated. Programs using extensive PEEKs and POKEs are probably not worth translating. Spectrum program The transfer requires an ASCII format of the Spectrum program, as opposed to an internal tokenised format to be recorded on tape. That is achieved by diverting the flow of ASCII bytes which normally would go to a printer after a LUST command. Most Spectrum programs can be transferred in one session but particularly long ones will have be split and transferred in two halves. That may seem strange since, at first sight, both micros appear to have about the same amount of user RAM available for Basic programs - about 37,000 bytes. The Spectrum Basic program, however, is compacted when it is resident in RAM and expands when LISTed. For„example, the keyword RANDOMIZE is a one-byte token in RAM and a nine-byte character when LISTed. On the other hand, Spectrum numbers occupy less space when listed, shedding six bytes for every number. The transfer program is responsible for some further expansion. A block-graphic or user-defined shape occupies one byte in RAM but is transferred to the Amstrad as a three-digit code in brackets e.g., [131] thus gaining four bytes in the process. Machine code To LLIST a program on to a cassette it is necessary to store all or part of the listing in a RAM buffer, since LLISTing directly to cassette, byte by byte, is not possible. The machine code program -listing one - occupies high memory, F000H to F1 DFto be exact, and the Basic program is allowed to fill the remaining memory. Prirping the machine code is achieved by RANDOMIZE USR 61440 and the routine will lie dormant until a LLIST or a LPRINT command is given. There is no requirement to run the Basic program, so the Spectrum video RAM (VRAM) at 4000H to 5B00H can be used as a 6.75K buffer to store the output diverted from the printer. Thus the Basic is LLISTed to VRAM. When the LLIST has finished or when the VRAM is full, whichever occurs first, the valid program segment in the VRAM is sent to the cassette tape as a binary file. Note that, although the binary SAVE is used, the material being saved is purely textual in nature. If the LLISTing has not finished, the VRAM will be cleared and more program lines will be sent there to be saved as a second program segment and so on. What the screen shows while the LLIST is in action defies description - it looks remarkably like a fatal machine crash but do not be fooled - real English words and numbers are steadily filling the video RAM. RANDOMIZE USR 61490 restores LLIST and LPRINT to their normal action. The tape cannot be verified but it can be played back into the Spectrum without corrupting any bytes and it is essential to do that since any bad recording will be revealed in the form of a “tape loading error” message. Each segment has a different file name - the first is A, the second B and so on - so LOAD “A”CODE will load the first program segment back on to the screen. Now is the time to take the transfer tape and put it into a nearby Amstrad datacorder. Do not forget you are only one-third of the way towards achieving a working Amstrad program. Two transfer programs need to be in the Amstrad. The machine codelisting two - should be a &8000 which, believe it or not, is considered “high” memory on disc-based Amstrads. A Basic control program -listing three - should be resident in low memory. The first segment loads from &4000 onwards and, because it is an entire Spectrum screenful - 1B00H bytes - will fill the Amstrad RAM up to &5AFF. The second segment will start loading at &5B00 and continue until the transfer is complete. If, by chance, this final segment also happened to be exactly a Spectrum screenful, the RAM end address would be &75FF. The control program knows how much RAM has been used because it reads the segment length from the tape header during the loading process. Notice that segment B has now been concatenated with segment A. The control program then proceeds to write the relevant RAM contents to disc or tape as an ASCII file. That is done in Basic and so disc users will notice an uncharacteristic delay while a FOR-NEXT loop is repeated some 16,000 times. If only Amstrad had produced its disc-firmware guide in time I could have written the ASCII SAVE in machine code. Tape users will not be aware of any extra delay, since saving 16,000 bytes to tape takes so long anyway. The file “AM1.ASC” can now be loaded into Protext -ROM version - and edited. After editing, SAVE the new file as “AM1.EDT” and LOAD “AM1.EDT” into Basic. Alternatively, the Basic command LOAD “AM1.ASC” can be given to bring the file directly into Amstrad Basic and you must do that if you have no suitable word processor. In either case MEMORY should be set to &7FFF or an “out of memory” error message will be thrown up - the control program leaves MEMORY set to &3FFF. If the LOAD is successful, editing can start. The load will fail if the Amstrad is presented with a Basic line more than 255 characters long. This, fortunately, is a rare event -the solution to the problem will be given next month. This article will be concluded in next month's issue of Your Computer. YourComputer(87-01) |
|  |
|
