Avoid all those file copying blues, courtesy of DAVE INSTONE BREWER ALL disc drive owners will know the difficulties associated with copying files between discs. PIP, the CP/M utility, is very tedious when you only have one drive, and the other routines copy the whole disc, not individual files. However, these problems are now a thing of the past. This utility has been designed to work with any setup which obeys the rules of Amsdos. It is certainly compatible with the new KDS 5.25in drive and should work with any drive with up to &800k capacity and 256 directory entries. Filecopy can transfer any files normally associated with Amsdos or CP/M. It will copy Basic, binary and Ascii files of any length from one disc to another, even on different drives, including 5.25in. As it only makes use of available ram, programs currently in memory will not be corrupted. Type the program in, save and run it. This will poke the machine code into the highest area of free memory, and then save it as copy.&a2. HIMEM is set, and the new command |COPY is initialised. The &A2 - or some other number - in the filename indicates the start address of the code, which is &A200 in this example. This will vary according to the value of HIMEM when the program was run, and is included so that the code can be installed quickly on future occasions. All you need is a simple loader such as: 10 MEMORY &A1FF
20 LOAD"copy.&a2"
30 CALL &A2B0Table I shows the four command formats. If the file won't fit into memory, it will be copied in smaller sections. Therefore copying may be quicker if other programs are not loaded. Filecopy's ease of use and the simplicity of its syntax disguise the fact that copying files under Amsdos is difficult. The firmware assumes that Basic or binary files being saved are loaded in their correct positions in memory, which means that programs being copied would be likely to overwrite any program already in the computer. How it's done The firmware also demands that only one disc is used in a drive at any one time. Files opened on a disc are automatically closed when another disc is used in the same drive, so files which are too large to fit into the CPC's memory cannot be copied easily. These restrictions concerning the use of one disc are due to the fact that Amsdos makes a map of the disc's space usage. Called the allocation vector, or ALV, it is regularly examined in order to find out where files are and which parts of the disc are free. Before the firmware begins writing to a disc it checks to see which one is in the drive. This is so that it doesn't overwrite any sectors which were free on the source disc, but which may contain a valuable data on the destination disc. When the disc is changed, it is logged in and a new ALV constructed to locate the free sectors. All well and good, but because the ALV resides at a specific place in memory, the map of the source disc will be wiped out. So when you come back to copy the second half of the program the firmware draws a new map, opens the file at the beginning, and starts again. This utility makes room for a second ALV and also a second checksum vector - CSV - to ensure that the correct disc is being used. Unfortunately this still doesn't stop the firmware throwing a wobbler and closing any open files when a different disc is inserted. Therefore, files in danger of being closed are temporarily allocated to another drive where the firmware is more than happy to ignore them. This drive transfer is only theoretical, and it doesn't matter whether or not a second drive is fitted. If the firmware routines are abandoned completely, any changes to the format which has been logged into Amsdos - such as using extra tracks, or fitting a 5.25in B drive - are not recognised, and the utility would be restricted to normal setups. As many people have something non-standard, the firmware has not been ignored, just persuaded to cooperate. My program pretends that every file is an Ascii file, and writes the Basic or binary header itself. This allows it to load and save files from any part of memory free at the time. Problems with CP/M Copying CP/M files presents its own problems. The only way you can tell the length of a file is from its directory entry, which maps out the disc sectors the file occupies. Therefore with a CP/M file the FILE-IN-CHAR call goes on reading characters until it runs out of sectors in the directory entry, and then returns with carry and zero false. To copy .com files I use an undocumented feature of the FILE-IN-CHR call at &BC80. This call returns with both carry and zero flags false if an end of file (EOF) marker has been found so that we know when to stop reading a headerless file, such as an Ascii file. However, it can detect two types of EOF marker - a file EOF and a directory EOF - though only one is documented. The normal way Amsdos marks the end of a file is with the character &1A, which is added to the end of the file when it is saved. In CP/M there are no file headers indicating the length of a file, nor are there EOF markers within files. The first type of EOF - the file EOF -can be distinguished from the directory EOF by the value in the A register, which is &1A for the file EOF and &0F for the directory EOF. It is a mystery why Amstrad did not provide this type of utility with the CPC. Once you start using it you will wonder how you ever managed your disc housekeeping without it. |COPY,"file" From one disc to another,
|COPY,"file>B" From the current drive to drive B.
|COPY,"A:file>B" From drive A to drive B.
|KOPY An alternative version of |COPY.Provided in case another RSX of the same name is present. - CPC464 owners will need to put the parameters in a string variable, for example:
a$="file"
|COPY,@a$CPC COMPUTING (12-1988) | ★ AMSTRAD CPC ★ DOWNLOAD ★ |
|
CPCrulez[Content Management System] v8.7-desktop/c
Page créée en 556 millisecondes et consultée 2726 foisL'Amstrad CPC est une machine 8 bits à base d'un Z80 à 4MHz. Le premier de la gamme fut le CPC 464 en 1984, équipé d'un lecteur de cassettes intégré il se plaçait en concurrent du Commodore C64 beaucoup plus compliqué à utiliser et plus cher. Ce fut un réel succès et sorti cette même années le CPC 664 équipé d'un lecteur de disquettes trois pouces intégré. Sa vie fut de courte durée puisqu'en 1985 il fut remplacé par le CPC 6128 qui était plus compact, plus soigné et surtout qui avait 128Ko de RAM au lieu de 64Ko. |
|
| 
