U009@CCIW.BITNET (11/24/89)
Hi there again. A few minor points: I find my UUEncoder on the PC damages the .UUE file if it gets bigger than 64K (sound familiar? segmentation?) and some of the archives I distributed generate a de-arcing error on the last file (which is only a copy of an advertisment in the original .ARC). I shortened the archive for future distribution (including the copy I sent to PROG-A16 at UOGUELPH.BITNET). You must carefully watch the progress of the duplication for skipped tracks, double copies of tracks and loss of sync. Don't assume it copied correctly because you saw -77-78-79 as you turned your head. If in doubt, run it again. I came upon the following information posted here by Mark Powell, <USQB015%liverpool.ac.uk@NSFnet-Relay.AC.UK>, on Thu, 20 Jul 89: > ... About 35 seconds for SS and about 68 for DS. In theory this is an > very nice device to own.... > HOWEVER!!!! I have a not been able to copy ANYTHING AT ALL with this > device. I have an Atari 1M external drive A and a Advanced Software > Technologies 1M external drive B, operating on a Nov 1985 520STM. Maybe, > this is too old a machine for the device to work on... I don't know. I > heard that the newer STs have a slightly different FDC, so maybe that is > the problem. Can anyone advise? I have a really old 520 (by North American Standards) 1985 ROMs too and it works fine from a ST314 (DS) drive to a ST354 (SS) drive, so the problem might be in the actual timing of the index pulse from the AST drive. Remember, the duplication relies on exact synchronism between the drives and some copy protection schemes we have analysed seem to rely on a specific, narrow range of byte count from the index pulse to the first sector header mark. Regards, Stu Beal, VE3MWM, (U009@CCIW.BITNET), National Water Research Institute, Burlington, Ontario, Canada.