This is autocopy, an automatic tape-copy program. I found new use in it with the registered version of the Z80-201 emulator. This program may be usable for other systems supporting tape files as well. Copyright: This program is herewith public domain. This means I claim no rights for this program. Feel free to include it with your emulator(s) if you think your users can use this. What is this, can I use this? Maybe: This program is written in 1985 for automatically copying tapes. It continuously reads and writes tape without user interaction. This is special since all the other copiers I've seen require operator interaction to start and stop tapes. This program drives a Z80 PIO port to start and stop the source and destination recorder. Now this was not of much use for others up till now but Z80-201 changed it! Z80-201 can load/save to .TAP files. It delivers a program that does essentially the same as mine, but this program just does whole tapes at a time, without interaction! Converting a whole tape to .TAP files: Convert your tapes to .TAP files the following way: 1) Set the tape input to LPT1 (or what have you) 2) Set the tape output to multiple tape files 3) Load "autocpy2.z80" 4) Run your tape. Every bit will by copied as .TAP file, unless your tape contains non-standard tape signals (I can't recognize speed-load things). The program automatically recognizes headerless-files. I recommend using multiple tape-files because saving goes faster. If not the program may miss the next header because the tape keeps running! You can always create a multiple tape file later by using the COPY command as described in the Z80 manual. Converting single or multiple .TAP files to real tape: Convert your .TAP files to normal tape the following way: 1) Set the tape input to the single-tape file or the multiple tape file directory. 2) Set the tape output to LPT1 (or what have you) 3) Set your tape to RECORD 4) Load "autocpy1.z80" The normal setting will give a delay of 3 seconds for a basic program and 1/4 second for other parts (headerless or code). These delays make use of the CPU interrupts and should be machine-speed independent. Note that this program will go on and on because the input .TAP file(s) will restart if the end is reached! Note that as soon as "autocpy1.z80" starts the load/save cycle will start! Bugs: Some programs have CODE blocks which are too big for this copier to be handled. I saw that Gerton's program, delivered with the registered version (you will need that anyway to do tape load/save to real tape!), keeps even more memory free, you may have luck with that. I only know a few games with this problem. Most of the time I already hacked them in two parts and used a move-block program (LDIR/LDDR) to enable it for Microdrive-use. About the programs: The original program has timing loops to allow the recorders to start and stop. I have two patched versions now. The versions are autocopy.z80 - This is the unmodified autocopy program as I wrote it in 1985. autocpy1.z80 - This is a patched version. The delays for start/stop are patched out, the delays before saving are shortened to make up for the time of loading the .TAP file into the emulator. autocpy2.z80 - This is a patched version. All the delays are patched out. With a simple hex-editor the changes are easy to find. All the tape start/stop delays work by the code: LD B,50 (= 0x32) HALT DJNZ FD <- this is patched to 0 in autocpy[12].z80 The delays before the leaders work by: LD A,(0x4017) LD B,A HALT DJNZ FD <- this is patched to 0 in autocpy2.z80 In "autocpy1.z80" the following code was changed 'Delay before CODE block' LD A,50 (= 0x32) changed to 0x0C LD (0x4917),A 'Delay before BASIC block' LD A,250 (= 0xFA) changed to 150 (=0x96) LD (0x4917),A Please don't ask me about the details of this program. I wrote it 9 years ago and I only did a quick and dirty find to find the delay- loops. I have the source somewhere but I can't regenerate it with the Interface-1 coupled on. The startup routine resides in a basic REM statement and is assumed to be at a fixed position. Microdrive channels, extra system-variables etc. mess this up. If you are really interested in how it works feel free to reverse-engineer it. What I can tell you is that the first thing the code does is initialize the Z80-PIO and move itself into video-memory. The whole code runs in video-memory leaving 40000+ bytes free to load. If your program is too big it will still load but at the end of the memory the pointer wraps around to the ROM space so your code-image will not be correct afterwards! Author: H. de Groot - groot@idca.tds.philips.nl P.S. Email will change to groot@apd.dec.com this year or the next year!