abc@BRL.ARPA (Brint Cooper) (06/02/88)
Recently, a series of six (6) files was posted to APPLE2-L. When EXEC-ed, they produce binaries which will generate music when used with an Apple sound program. I have downloaded the third of these six on two different occasions, and, each time, received "ERROR" upon EXEC-ing them under PRODOS 1.0.1 on an un-enhanced Apple IIe. Does anyone know why? _Brint
SEWALL@UCONNVM.BITNET (Murph Sewall) (06/03/88)
> I have downloaded the third of these six on two different >occasions, and, each time, received "ERROR" upon EXEC-ing them under >PRODOS 1.0.1 on an un-enhanced Apple IIe. While I can't help you with the music program question (that error message occurs when, for any reason the EXECUTIONER file is corrupted) because I haven't tried to download that. I can help with ProDOS (BOY is 1.0.1 out of date!). I got a copy of 1.4 with my latest edition of Copy 2+, I can upload an EXECUTIONER file of ProDOS 1.4 and mail it to you if you'd like (many bug fixes since 1.0.1).
JDA@NIHCU.BITNET (Doug Ashbrook) (06/04/88)
> Recently, a series of six (6) files was posted to APPLE2-L. > When EXEC-ed, they produce binaries which will generate music when used > with an Apple sound program. > > I have downloaded the third of these six on two different > occasions, and, each time, received "ERROR" upon EXEC-ing them under > PRODOS 1.0.1 on an un-enhanced Apple IIe. Just last night I had a similar problem downloading a file with Kermit 3.83. Normally I have a clean phone connection and no retries are needed. But last night I must of had a noisy phone connection because many retries were occurring. When the packet was re-transmitted, Kermit did not throw away the bad packet. Each time I attempted to EXEC the file after any retries had occurred, I got the "ERROR" message. I was finally able to download the file without any retries and it then EXECed cleanly. Has anyone else had any problems with Kermit not discarding bad packets? ------------------------------------------------------------------- J. Douglas Ashbrook (301) 496-5181 BITNET: JDA@NIHCU ARPA: jda%nihcu.bitnet@cunyvm.cuny.edu National Institutes of Health, Computer Center, Bethesda, MD 20892
SEWALL@UCONNVM.BITNET (Murph Sewall) (06/04/88)
>Just last night I had a similar problem downloading a file with >Kermit 3.83. Normally I have a clean phone connection and no retries >are needed. But last night I must of had a noisy phone connection >because many retries were occurring. When the packet was >re-transmitted, Kermit did not throw away the bad packet. Each time Did it not discard ANY of the bad packets or only some of them (one would have been enough to FUBAR the EXECUTIONER)? >I attempted to EXEC the file after any retries had occurred, I got >the "ERROR" message. I was finally able to download the file without >any retries and it then EXECed cleanly. > >Has anyone else had any problems with Kermit not discarding bad >packets? I've never had that problem downloading text files. I occasionally get a retry and haven't gotten an extra packet (perhaps it depends on exactly what error requiring a retry occurs). Is it possible that the bad packets generating retries WERE replaced, but that at least one packet was accepted (correct checksum character) that should not have been? There's a 1 in 256 chance of that happening in XModem given a bad block, and if I understand Kermit's error checking, the same odds apply. I have had trouble downloading binary files (from IBM to IBM over bitnet where no translations to ASCII intervene, binary transfer will work). Evidently the one character block-check (the only level Kermit-65 supports) is insufficient to insure against bad blocks in 8bit transfers. I've received corrupted binary code even when there were NO errors resulting in retries (confirmed by uploading the file and comparing byte-for-byte against the original). The Kermit protocol provides for up to 3 character CRC error checking. The MS-DOS docs note that SET BLOCK 3 should be used when transerring binary files. However, I've been under the impression that SET BLOCK 1 is sufficient for 7-bit transfers. I assume that providing for SET BLOCK-CHECK 2 (or 3) in Kermit-65 would involve a LOT of overhead that might create other problems or expand the code beyond the capacity of 48K Apple 2's (?). --------------------- Disclaimer: The "look and feel" of this message is exclusively MINE! (subject to change without notice; void where prohibited) ARPA: sewall%uconnvm.bitnet@mitvma.mit.edu Murphy A. Sewall BITNET: SEWALL@UCONNVM School of Business Admin. UUCP: ...ihnp4!psuvax1!UCONNVM.BITNET!SEWALL University of Connecticut