mikes@lakesys.UUCP (Mike Shawaluk) (12/22/88)
In article <14049@oberon.USC.EDU> papa@pollux.usc.edu (Marco Papa) writes: > >Version 1.0e of A-Talk III, which I shipped to OXXI last week for duplication, >supports "multiple serial ports", through different UNIT numbers. As Matt >. . . >-- Marco Papa 'Doc' I am taking the liberty at this time to post the "Read-Me" file which came with my Atalk-III 1.0e upgrade yesterday (you can imagine my surprise in getting 1.0e, after requesting 1.0c!) (hope it's okay with Marco and OXXI :-) ----------------------------------------------------------------------------- A-Talk III -- Release 1.0e December 8, 1988 Copyright (C) 1988 Felsina Software This file contains information available after the printing of the manual for release 1.0 of A-Talk III. 1. CHOP ------- When chopping files (Transfer Auto Chop On), a temporary copy of the file is made. Therefore, you should "save" the file on a disk with a number of free bytes larger than twice the size of the file to receive. The same is true when transferring to a RAM disk. 2. WXMODEM ---------- This release includes support for the WXMODEM (Windowed XMODEM) protocol designed by Peter Boswell and currently available on People/Link. The Protocol menu includes a new entry named WXMODEM, and the PROTOCOL command of the A-Talk III script language allows an additional "w" parameter to request a WXMODEM transfer. It can be used as follows: PROTOCOL W RECEIVE filename 3. YMODEM-g ----------- Developing technology is providing phone lines data transmission at ever higher speeds using very specialized techniques. These high-speed modems as well as session protocols such as X.PC, provide high-speed and nearly error-free communications. YMODEM-g is a modification to the YMODEM Batch protocol where acknowledgements for data blocks are not used. Because it does not use error-recovery, YMODEM-g must be used with hard-wired connection or with an hardware error-correcting modem. When YMODEM-g detects an error data transfer is aborted. YMODEM-g requires UNIDIRECTIONAL flow-control to work at high speeds: the receiver should send X-off to the sender when its input buffer is full, and the sender should resume sending when receiving X-on. The Amiga serial device, as currently implemented in versions 1.2 and 1.3 of the system software, only allows BIDIRECTIONAL flow-control. Therefore, currently it is not possible to use flow-control with YMODEM-g in streaming (continuous) mode. As a result, we have found that YMODEM-g is reliable at receiving speeds up to 4800 bauds. No problem instead is present when sending files from the Amiga to another host using YMODEM-g: speeds up to 19200 bauds can be safely used in this case. Depending on the support from the host BBS, RTS/CTS handshake can be used, in place of X-on/X-off, which should allow faster speeds. The Protocol menu includes a new entry named YMODEM-g, and the PROTOCOL command of the A-Talk III script language allows an additional "g" parameter to request a YMODEM-g transfer. It can be used as follows: PROTOCOL G RECEIVE 4. PHONEBOOK/SETTINGS FILE LOCATION ----------------------------------- When looking for the Phonebook and the saved settings, A-Talk III now first looks in subdirectory "Settings" of the "current" directory. If no files are found, A-Talk III will then look in AT3:Settings. If no files are found, A-Talk III will put up a requester indicating that the Phonebook was not found. 5. ZMODEM ENHANCEMENTS ---------------------- * ZMODEM Resume A-Talk III Rel. 1.0e now supports ZMODEM Recover/Resume of an interrupted file transfer both when invoked by the host (as in Rel. 1.0) and when selected locally on the Amiga. If the destination file exists, a requester will come up which will ask the user whether he/she wants to "Resume" or "Replace" the file. Selecting "Resume" will append the received data to the destination file and start transfer at the offset corresponding to the receiver's end of file. Selecting "Replace" will overwrite the old file with the received data: the old file's data is lost. As described in Chuck Forsberg's ZMODEM documentation, the Resume option will only be allowed when no "text conversion" option has been requested by the host ZMODEM program. * ZMODEM Speed The speed of ZMODEM send and receive has been improved by 60%, especially for Binary transfers. This will be noticeable only at speeds of 9600 baud and up. A-Talk III Rel. 1.0e is able to transfer files at over 1000 char/sec. at 9600 bauds, and over 1500 char/sec. at 19,200 bauds when receiving to the RAM: disk with ZMODEM protocol and RTS/CTS handshake. * ZMODEM Remote Host Commands ZMODEM now supports remote commands from a host computer, generally a UNIX(tm) based system. Remote host commands are typed on the host command line and then executed on the Amiga. The allowed commands must provide their own windows for input/output. For example, when using "sz" on a UNIX system, one can type: sz -i Clock This command will instruct A-Talk III to execute the "Clock" program and return "immediately" upon successful startup of the program. sz -c "makedir RAM:mydir" This command will instruct A-Talk III to run the makedir program to create the appropriate directory and resume execution only after the makedir command has exited. Entire sets of directories and subdirectories can be transferred with ZMODEM, when the same directory structure has been established on both the host and the Amiga, and GetDIR has selected the "root" of the corresponding Amiga directory tree. * ZMODEM Transfer Type When using ZMODEM and Ymodem Batch, the Transfer Type should be set to "Text" ONLY when receiving text files from PC-DOS or CPM-based bulletin boards. When transferring text files between Amigas and between Amigas and UNIX, the Transfer Type should be set to "Binary", since both Amiga and UNIX use the same end-of-line character and, unlike CPM and PC-DOS, they have no concept of an end-of-file character. 6. BUG FIXES ------------ - DIAL Script Command A bug has been fixed in A-Talk III 1.0 concerning the DIAL command of the script language. The manual says that the parameter of the DIAL command is a string between double quotes("). In reality, the DIAL command only accepted strings WITHOUT quotes. In A-Talk III Rel. 1.0e, the DIAL command works as described in the manual. Therefore now the double quotes are required. - Problem with MemWatch When running MemWatch (by John Toebes, Copyright (C) 1987 The Software Distillery) with A-Talk III Rel. 1.0, a requester would pop up indicating that A-Talk III was overwriting low memory. While fortunately this did not result in a GURU, it puzzled some users. This bug is now fixed in Rel. 1.0e. - Additional IBM PC ANSI Support A-Talk III Rel. 1.0e provides FULL support of all IBM PC ANSI escape codes, when selecting ANSI Terminal, IBM PC Font, 8 colors and Full screen. For complete emulation of the IBM CGA, the following colors should be used: Color 1: Black Color 2: Red Color 3: Green Color 4: Yellow Color 5: Blue Color 6: Magenta Color 7: Cyan Color 8: White - HAYES Fail Messages The entire set of Hayes fail codes (VOICE/BUSY/NO DIALTONE) has been added to the Dial routine, which will fix the problem of timing out when the host has not generated the proper carrier signal. The returned fail message is displayed on the screen. - TALK Emulator When selecting the FULL screen and TALK Terminal, the incoming data is now confined at the top half of the screen. 7. RTS/CTS SUPPORT ------------------ A-Talk III Rel. 1.0e supports RTS/CTS handshake. This can be selected through the Amiga Preferences. After invoking Preferences, select "Change Serial". Then select Handshaking RTS/CTS. Click on OK and Save (or Use). Then you can run A-Talk III, and the serial port will be opened with RTS/CTS. RTS/CTS handshaking is faster than X-o/X-off. Therefore it is recommended with ZMODEM transfers. Besides the RTS/CTS selection, the Serial Buffer Size is also selectable from Preferences. The default is 8000 bytes. For file transfers at high speeds, one can also select a Buffer Size of 16000 bytes. 8. US ROBOTICS HST MODEM ------------------------ The US Robotics HST modem is a high-speed modem that is very popular with IBM PC-based bulletin boards. If you have such a modem, optimum performace can be obtained with RTS/CTS, 16000-byte serial buffer, and 19,200 baud. 9. PHONEBOOK ADDITIONS ---------------------- Two features have been added to the Phonebook: long distance codes and queueing. * Long Distance Codes At the bottom of the Phonebook area a new 35-character string requester, labeled "Long Distance Code" has been added. It allows the user to enter an MCI, PC PURSUIT or SPRINT access code to be prefixed to the actual phone number. For example it could contain the number: 1-800-347-6578W-12345-617-920-2050 The first part is the access code. This is followed by the Hayes "W" command, which waits for a dial tone. Then comes the phone company card "secret" access code and home phone number. The actual destination number is stored in the "Phone Number" string gadget. * Queuing At the bottom of the Phonebook area a new 2-digit string requester, labeled "Queue", has been added. The entered number "links" one host with another one. The allowed range of values is 1 through 60. To aid in linking various hosts to each other, the host names are now preceded by the "host" number in the center of the Phonebook. If an host is found to be busy, the one "linked" to is is tried and so on. Circular lists are allowed [1->2->3->1]. 10. TALK2THREE TOOL ------------------ A tool called Talk2Three has been added to the Installation Disk. It allows automatic translation of "old" A-Talk and A-Talk PLus script files to A-Talk III script files. ADDITIONAL ACKNOWLEDGEMENTS: --------------------------- We would also like to thank the following people/organizations for their contributions: Dan J. James for the WXMODEM code. People/Link for free access to their system for testing purposes. -- - Mike Shawaluk ...!uunet!marque!lakesys!mikes
papa@pollux.usc.edu (Marco Papa) (12/23/88)
In article <242@lakesys.UUCP| mikes@lakesys.UUCP (Mike Shawaluk) writes: |In article <14049@oberon.USC.EDU| papa@pollux.usc.edu (Marco Papa) writes: ||Version 1.0e of A-Talk III, which I shipped to OXXI last week for duplication, ||supports "multiple serial ports", through different UNIT numbers. As Matt ||. . . ||-- Marco Papa 'Doc' | |I am taking the liberty at this time to post the "Read-Me" file which came |with my Atalk-III 1.0e upgrade yesterday (you can imagine my surprise in |getting 1.0e, after requesting 1.0c!) | |(hope it's okay with Marco and OXXI :-) ^^^^^^^^^^^^^^ Well, sorry but there are TWO major reasons why the posting was inappropriate: 1. As posted, the message is what I would call "blantant advertising". AT LEAST you should have warned the user about "COMMERCIAL INFORMATION", stick a ^L in there and let him skip if he desires to do so. In general, there is ONE perfect place for commercial postings on Usenet: comp.newprod. It is moderated, so one has to wait a few days before stuff shows up, but all flames are redirected to /dev/null, since if you subscribe to it, then you know you are getting. |----------------------------------------------------------------------------- | | A-Talk III -- Release 1.0e | | December 8, 1988 | | Copyright (C) 1988 Felsina Software ^^^^^^^^^^^^^ 2. Did you see that little Copyright notice? Copyright means "right to copy". In general, unless one gets a WRITTEN release, NOTHING on any copyrighted disk can be legally put put in a "public" place, such as Usenet, without violating the copyright. Public domain programs/files on such disks are of course excluded from this. So, for next time, please take the above into consideration. Note that there is a "fair use" of copyrighted material that allows "excerpting" from it. Excerpting "a few" lines from the Readme file would probably be covered by the "fair use" doctrine. Posting the ENTIRE file, definitely is not covered. Now, do I have to add "copyright" to my KILL file ? :-) -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
gsarff@meph.UUCP (Gary Sarff) (12/24/88)
In article <242@lakesys.UUCP> mikes@lakesys.UUCP (Mike Shawaluk) writes: >In article <14049@oberon.USC.EDU> papa@pollux.usc.edu (Marco Papa) writes: >> >1. CHOP >------- >When chopping files (Transfer Auto Chop On), a temporary copy of the file >is made. Therefore, you should "save" the file on a disk with a number of >free bytes larger than twice the size of the file to receive. The same >is true when transferring to a RAM disk. What? Comm and most other term programs I have seen don't need twice the space of a file free on disk to do autochopping. Just look at the block received at the end of file and scan backwards and only write out non-pad bytes to the disk. The way Atalk III is doing it, someone with only floppies won't be able to download large files, and amiga is getting larger files all the time on bbs's and public networks as people make big animations and such. This sounds strange. ------------------------------------------------------------------------ "Those whom the gods would destroy, they first make mad" He who steals my core-dump, steals trash
papa@pollux.usc.edu (Marco Papa) (01/13/89)
In article <00063@meph.UUCP> gsarff@meph.UUCP (Gary Sarff) writes: >In article <242@lakesys.UUCP> mikes@lakesys.UUCP (Mike Shawaluk) writes: >>In article <14049@oberon.USC.EDU> papa@pollux.usc.edu (Marco Papa) writes: >The way Atalk III is doing it, someone with only floppies >won't be able to download large files, and amiga is getting larger files >all the time on bbs's and public networks as people make big animations and >such. This sounds strange. Auto Chop in general should hardly be used at all since most files on BBS are now ARC-ed or ZOO-ed, especially all those animations. "Chopping" an ARC or ZOO file will always produce a "munged" last file. If you are transferring a single file, it will be munged and ZOO or ARC won't be able to decompress it properly. When running the resulting program one will get the dreaded "unable to load XXXX: file is not an objetc module". Whatever program you are using, please turn auto-chop off for .ARC and .ZOO files. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
mikes@lakesys.UUCP (Mike Shawaluk) (01/13/89)
In article <14652@oberon.USC.EDU> papa@pollux.usc.edu (Marco Papa) writes: > >Auto Chop in general should hardly be used at all since most files on BBS are >now ARC-ed or ZOO-ed, especially all those animations. "Chopping" an ARC or >ZOO file will always produce a "munged" last file. If you are transferring >a single file, it will be munged and ZOO or ARC won't be able to decompress it >properly. When running the resulting program one will get the dreaded >"unable to load XXXX: file is not an objetc module". Whatever program you >are using, please turn auto-chop off for .ARC and .ZOO files. > >-- Marco Papa 'Doc' Actually, I remember having problems with several of the PD terminal programs I used to use (vt100, Comm) before I bought a commercial one (I now own OnLine! 2 and Atalk III), in regard to chopping; I also seem to recall that the most recent version of Vt100 (2.8?) does implement a correction to this anomaly. The problem, as I remember it, is that an .ARC file ends with the character sequence 0x1a00 (that is, CTRL-Z followed by a NUL byte), to indicate the "end of archive" mark. Most of the auto-chop routines will, unfortunately, delete these two bytes from the end, thus "corrupting" the archive (I don't know what .ZOO files have in them, but most of the ZOO's I've seen lately have zzendpad.foo's in them, so it must be something similar). Anyways, with the increased usage of YMODEM-Batch, Zmodem, and even Kermit, which all communicate the file size to the receiving system, the need to "chop" files is, as Marco says, becoming less and less important, in addition to the reasons stated regarding archives. I guess all that I wanted to say here is that I believe that the statement "chopping will ALWAYS mung a .ZOO or .ARC file" is a bit harsh or misleading; it should probably be reworded to "chopping an .ARC or .ZOO file using many (or most) terminal programs, including Atalk III, ...". I don't recall the exact technique that Vt100 uses for auto-chopping, but maybe Tony S. can share it with us? BTW, it was really important for that anomaly in VT100 to be corrected, since that program, at least in the earlier versions, did not give the user a choice regarding autochopping; it ALWAYS chopped (tho I can't speak for the current version, as I haven't used it in a long time.) -- - Mike Shawaluk ...!uunet!marque!lakesys!mikes
pnelson@antares.UUCP (Phil Nelson) (01/14/89)
In article <14652@oberon.USC.EDU> papa@pollux.usc.edu (Marco Papa) writes: >now ARC-ed or ZOO-ed, especially all those animations. "Chopping" an ARC or >ZOO file will always produce a "munged" last file. If you are transferring >a single file, it will be munged and ZOO or ARC won't be able to decompress it >properly. When running the resulting program one will get the dreaded >"unable to load XXXX: file is not an objetc module". Whatever program you >are using, please turn auto-chop off for .ARC and .ZOO files. > Please pardon my ignorance, but why must an auto-chop mung the end of a .zoo or .arc file? Shouldn't it leave the file alone if it doesn't know how much to chop? By the way, I received my A-Talk III upgrade today, I'm running it now. So far, I like it! I tried a 9600 baud Z-modem transfer from a Sun server at work, it worked 1st time, and very quickly. It may be that I will finally retire vt100, which I have been using in preference to the several other commercial comm programs I own. >-- Marco Papa 'Doc' >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu > "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= just another unofficial and unsolicited comment from: -- Phil Nelson at (but not speaking for) OnTyme:NSC.P/Nelson Tymnet, McDonnell Douglas Network Systems Company Voice:408-922-7508 UUCP:{pyramid|ames}oliveb!tymix!pnelson LRV:Component Station "ding ding..." -Santa Clara County Transit Company trolley car (AKA "LRV")
blgardne@esunix.UUCP (Blaine Gardner) (01/15/89)
From article <14652@oberon.USC.EDU>, by papa@pollux.usc.edu (Marco Papa): > Auto Chop in general should hardly be used at all since most files on BBS are > now ARC-ed or ZOO-ed, especially all those animations. "Chopping" an ARC or > ZOO file will always produce a "munged" last file. If you are transferring > a single file, it will be munged and ZOO or ARC won't be able to decompress it > properly. When running the resulting program one will get the dreaded > "unable to load XXXX: file is not an objetc module". Whatever program you > are using, please turn auto-chop off for .ARC and .ZOO files. Marco, several of the PD terminal programs disable auto-chop when the filename has a suffix of .ARC or .ZOO, does Atalk III do this? (I'm asking because it sounds like the answer is NO from your message.) Do you have plans to add an autodialer to Atalk III? The lack of one is the biggest reason I've got for not buying it. Right now I use Baud Bandit (the latest PD version of GT Comm, soon to be commercial) for dialing, and switch over to AZComm for file transfers. To make things even worse, I use Handshake for VT100 emulation when calling work (I was using VT100, but it doesn't support 19,200 BPS and with the Trailblazer Plus the serial port stays locked at 19,200 regardless of what speed the modem is running at) but have to exit it for Zmodem transfers again. Here's a few items from my fantasy terminal program wish list: 1) Zmodem (If you've got that, you've got it made.) 2) Autodialer with a circular queue (see Baud Bandit for the best example.) 3) The ability to send a setup string to the modem for each phonebook entry before dialing. (Obscure perhaps, but I've got a Telebit Trailblazer Plus, and I need to change a register if the computer I'm calling doesn't have a Trailblazer.) 4) Scripts for logon and such. 5) TRUE VT100 emulation, VT220 with the f-keys supported would be nice. The VT100 graphics character set too. 6) Flicker free color when ANSI color graphics are being displayed. Every terminal program I've seen has horrible flickers, flashes, and tears when a color combination other than 0 for background and 1 for text is scrolled. 7) 19,200 BPS support, full speed. (Again, a Trailblazer.) 8) Hardware handshaking support (Trailblazer again.) So am I dreaming, or is there a program that will really do all this? -- Blaine Gardner @ Evans & Sutherland 580 Arapeen Drive, SLC, Utah 84108 Here: utah-cs!esunix!blgardne {ucbvax,allegra,decvax}!decwrl!esunix!blgardne There: uunet!iconsys!caeco!pedro!worsel!blaine "Nobody will ever need more than 64K." "Nobody needs multitasking on a PC."
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (01/15/89)
In <14652@oberon.USC.EDU>, papa@pollux.usc.edu (Marco Papa) writes: > Auto Chop in general should hardly be used at all since most files on BBS are > now ARC-ed or ZOO-ed, especially all those animations. "Chopping" an ARC or > ZOO file will always produce a "munged" last file. If you are transferring > a single file, it will be munged and ZOO or ARC won't be able to decompress it > properly. When running the resulting program one will get the dreaded > "unable to load XXXX: file is not an objetc module". Whatever program you > are using, please turn auto-chop off for .ARC and .ZOO files. Well Marco, it's unfortunate that your program mungs .ARC or .ZOO files, but I can assure you that it is not the case with all terminal programs. The one I am most familiar with, Aterm 7.3, definitely does not mung them. That was fixed ages ago. I always receommend that people leave AutoChop enabled on Aterm, because there are VERY few files that will ever be adversely affected. Aterm does not require 'twice the space' to do autochop. You are welcome to the source code for Aterm 7.3 if you are interested. If you are not on CIS (or any network where it might also be), I'd be happy to mail it to you. > -- Marco Papa 'Doc' -larry -- Frisbeetarianism: The belief that when you die, your soul goes up on the roof and gets stuck. +----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------------+
shimoda@infohh.rmi.de (Markus Schmidt) (01/15/89)
Hi! If the uploader handled the file correct there should be no problem with chopping. According to Chuck Forsberg you may pad either with NUL or CMP_EOF, and there is no reason for not using CMP_EOF when the last byte of the file is NUL. Of course the receiver may only chop those PADs that match the last byte in the transfer and not mixed 00 and 1A. AmigaCall (unfortunately only aviable in Europe as a german version) exactly does that.
elg@killer.DALLAS.TX.US (Eric Green) (01/17/89)
in article <470@infohh.rmi.de>, shimoda@infohh.rmi.de (Markus Schmidt) says: > If the uploader handled the file correct there should be no problem > with chopping. According to Chuck Forsberg you may pad either with NUL > or CMP_EOF, and there is no reason for not using CMP_EOF when the last > byte of the file is NUL. > Of course the receiver may only chop those PADs that match the last byte > in the transfer and not mixed 00 and 1A. Let's say that your file length is an exact multiple of 128 bytes. Further, let's say that your file ends with fifteen NUL characters. Xmodem will not create an extra empty padding block. Thus an autochopper will chop off 15 bytes of your file. That's just one example of why Xmodem is brain-dead for use with non-CP/M systems. I personally use Batch Ymodem or Zmodem whenever possible, just to bypass those problems. -- Eric Lee Green ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg Snail Mail P.O. Box 92191 Lafayette, LA 70509 Netter A: In Hell they run VMS. Netter B: No. In Hell, they run MS-DOS. And you only get 256k.
aaron@madnix.UUCP (Aaron Avery) (01/17/89)
In article <470@infohh.rmi.de> shimoda@infohh.rmi.de (Markus Schmidt) writes: >with chopping. According to Chuck Forsberg you may pad either with NUL >or CMP_EOF, and there is no reason for not using CMP_EOF when the last >byte of the file is NUL. >Of course the receiver may only chop those PADs that match the last byte >in the transfer and not mixed 00 and 1A. This is the correct way to do it. This is how I've always done it. This, however, still cannot deal with the file who's real length exactly fills the last block. Then, if the last character or few characters are either NULL or CPM_EOF, they will (incorrectly) get chopped. More people should just support simple batch Ymodem. It's almost exactly the same as Xmodem (code wise), sends the filename and length, and handles batch transfers. -- Aaron Avery, ASDG Inc. "A mime is a terrible thing to waste." -- Robin Williams ARPA: madnix!aaron@cs.wisc.edu {uunet|ncoast}!marque! UUCP: {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!aaron
papa@pollux.usc.edu (Marco Papa) (01/17/89)
In article <343@antares.UUCP> pnelson@antares.UUCP (Phil Nelson) writes: |In article <14652@oberon.USC.EDU| papa@pollux.usc.edu (Marco Papa) writes: ||When running the resulting program one will get the dreaded ||"unable to load XXXX: file is not an objetc module". Whatever program you ||are using, please turn auto-chop off for .ARC and .ZOO files. | |Please pardon my ignorance, but why must an auto-chop mung the end of a .zoo |or .arc file? Shouldn't it leave the file alone if it doesn't know how much |to chop? Chopping works by getting to the end-of-file and searching backward for a particular "hunk" that indicates the end of an Amiga loadable program. Using the fact that the uploaded file has an .ARC or .ZOO extension works most of the time, except when the user "renames" the file he/she is downloading (Note that auto-chopping has a meaning only for Xmodem transfers that require the user to select a "local" filename in which to store the incoming file. YMODEM Batch, ZMODEM and Kermit file transfers always send the file size together with the file, so A-Talk III completely ignores the Auto-chop setting for these transfers. |By the way, I received my A-Talk III upgrade today, I'm running it now. So |far, I like it! I tried a 9600 baud Z-modem transfer from a Sun server at |work, it worked 1st time, and very quickly. The ZMODEM code has been improved a LOT. As a matter of fact some UNIX hosts cannot keep up with the speed A-Talk III can send files at. We are planning further unprovements to ZMODEM's performance by encoding the CRC generation/ checking in assembler. That's were now most of the time is spent, and those routines are still written in C (as ALL the rest of A-Talk III). By the way, I'd like to acknowledge the help we had with code improvements with Tomas Rokicki's [sorry If I misspelled it] profiler. The profiler works like a champ with ALL versions of MANX after 3.40e and is provided in the MANX release disks. |It may be that I will finally |retire vt100, which I have been using in preference to the several other |commercial comm programs I own. Maybe :-) Thanks, anyway. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
papa@pollux.usc.edu (Marco Papa) (01/17/89)
In article <6818@killer.DALLAS.TX.US> elg@killer.DALLAS.TX.US (Eric Green) writes: |That's just one example of why Xmodem is brain-dead for use with |non-CP/M systems. I personally use Batch Ymodem or Zmodem whenever |possible, just to bypass those problems. Smart idea. And since now most BBSs and public networks support either one of those (or kermit which also has no "chopping" problems) there is really no need to use XMODEM (which moreover is way much slower than ZMODEM or YMODEM Batch). -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
acs@pccuts.pcc.amdahl.com (Tony Sumrall) (01/17/89)
In article <293@lakesys.UUCP> mikes@lakesys.UUCP (Mike Shawaluk) writes: > ... I don't recall the exact technique that >Vt100 uses for auto-chopping, but maybe Tony S. can share it with us? VT100 chops all preceding occurrences of the last character in the last packet if the last character is ^Z or 0x00; it chops until it encounters a character that isn't the same as the last char. I.e. if((firstchar = bufr[--bufptr]) == 0 || firstchar == 0x1A) while (bufptr && bufr[--bufptr] == firstchar) ; bufptr++; write(fd, bufr, bufptr); I'll try to remember to make auto-chop an option in the 2.9 version. > - Mike Shawaluk > ...!uunet!marque!lakesys!mikes -- Tony Sumrall acs@pccuts.pcc.amdahl.com <=> amdahl!pccuts!acs [ Opinions expressed herein are the author's and should not be construed to reflect the views of Amdahl Corp. ]
sterling@cbmvax.UUCP (Rick Sterling QA) (01/18/89)
In article <6818@killer.DALLAS.TX.US> elg@killer.DALLAS.TX.US (Eric Green) writes: > in article <470@infohh.rmi.de>, shimoda@infohh.rmi.de (Markus Schmidt) says: > > If the uploader handled the file correct there should be no problem > > with chopping. According to Chuck Forsberg you may pad either with NUL > > or CMP_EOF, and there is no reason for not using CMP_EOF when the last > > byte of the file is NUL. > > Of course the receiver may only chop those PADs that match the last byte > > in the transfer and not mixed 00 and 1A. > > Let's say that your file length is an exact multiple of 128 bytes. > Further, let's say that your file ends with fifteen NUL characters. > Xmodem will not create an extra empty padding block. Thus an ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > autochopper will chop off 15 bytes of your file. > > That's just one example of why Xmodem is brain-dead for use with > non-CP/M systems. I personally use Batch Ymodem or Zmodem whenever > possible, just to bypass those problems. > > -- > Eric Lee Green ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg > Snail Mail P.O. Box 92191 Lafayette, LA 70509 > Netter A: In Hell they run VMS. > Netter B: No. In Hell, they run MS-DOS. And you only get 256k. According to my reading of the protocol it should create the extra padding block with ^Z's ... This is how I implemented it in several term progs in the past.... 1. If file is a multiple of 128 bytes and does not end with $00 or $1A send file as is. 2. If file is a multiple of 128 bytes and ends with $00 then pad extra block with $1A 3. If file is a multiple of 128 bytes and ends with $1A then pad extra block with $00 4. If file is not multiple of 128 bytes and ends with $00 then pad to end of block with $1A 5. If file is not multiple of 128 bytes and ends with $1A then pad to end of block with $00 6. If file is not a multiple of 128 bytes and does not end with $00 or $1A then pad to end of block with $1A No 'munged' files ;-) - Rick - -- ============================================================================= Rick Sterling COMMODORE AMIGA TEST ENGINEERING N2CGI UUCP {allegra,rutgers}!cbmvax!sterling =============================================================================
m230bw89@trillium.waterloo.edu (Scotte Zinn) (01/18/89)
I recently purchased a copy of ATalk III (rev1.0e) and had a few problems with it as well as a few things that weren't thought out in its design. A got ATalk III running, then started the following ARexx script: /* This tests the REXX stuff */ address ATK CD "download:" SEND "ATS0=0^M" address The results were: The directory was not changed in the file requestor. (Maybe not a bug, but certainly an inconvenience since the file requestors started from DF0: even when the program was run from a hard drive) The AA light on my HAYES compatible modem didn't go out nor did I see the OK response. (No characters were sent from the modem at all) Another inconvenience, the phone book could be called up via a keyboard shortcut, but once on the phone book screen, you have to use a mouse!! Come on you guys, don't implement the power user features half heartedly! How come very few (I've only seen one and that was VT100R2.6) programs that support kermit support it in 7 bit even parity mode for transferring binary files? Diga! doesn't even do it correctly. Needless to say, I have returned ATalkIII to the store I bought it from and will wait patiently for a terminal program that will do things reliably. I did like most of the interface that ATalkIII had. Scotte Zinn rszinn@rose.waterloo.edu
papa@pollux.usc.edu (Marco Papa) (01/19/89)
In article <10833@watdragon.waterloo.edu> m230bw89@trillium.waterloo.edu (Scotte Zinn) writes: > > >I recently purchased a copy of ATalk III (rev1.0e) and had a few problems >with it as well as a few things that weren't thought out in its design. > >A got ATalk III running, then started the following ARexx script: > > /* This tests the REXX stuff */ > address ATK > CD "download:" > SEND "ATS0=0^M" <----- **** > address > >The results were: > The directory was not changed in the file requestor. (Maybe not a > bug, but certainly an inconvenience since the file requestors started > from DF0: even when the program was run from a hard drive) > > The AA light on my HAYES compatible modem didn't go out nor did I > see the OK response. (No characters were sent from the modem at all) Sorry, but you should have RTFM, dude! The SEND command sends a FILE not a string. The REPLY command sends a string (Online! also uses REPLY". So the send just failed since I doubt that you have a file named ATS0=0^M :-) Of course you could hardly see anything showing up on your modem, you didn't send ANYTHING to it. Also you need quotes in general for ARexx scripts so as to avoid clashes with ARexx command names. The CD command will change the directory for next SEND and RECEIVE (of course given with a "real" filename. >Another inconvenience, the phone book could be called up via a keyboard >shortcut, but once on the phone book screen, you have to use a mouse!! Come >on you guys, don't implement the power user features half heartedly! ^^^^^^^^^^ Yea, you are the "power user" that tries to use a script language without even reading its syntax? What a "power user"! >Needless to say, I have returned ATalkIII to the store I bought it from and >will wait patiently for a terminal program that will do things reliably. I am glad you did. >I did like most of the interface that ATalkIII had. Who cares, "power user". -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
jlydiatt@jlami.wimsey.bc.ca (Jeff Lydiatt) (01/19/89)
I have never had any problems chopping downloaded zoo or arc'ed
files using the version of Xmodem implemented in Aterm7.3. The trick
Aterm uses is to note that arc'ed files generally end with the two
characters '1A00'x. If the pad character is '00'x and the last non-zero
byte was also a '1A'x, the algorithm leaves one '00'x in the file.
Zoo files don't seem to be a problem. The zoo files I have observed
all seem to end with the character '83'x - not a character normally used
as a pad character by Xmodem.
--
---
"My dog will only eat cantaloupes", was Tom's melancholy complaint.
// Jeff Lydiatt: jlydiatt@jlami.wimsey.bc.ca | From the desk
\X/ UUCP {uunet,cs.ubc.ca}!jlami.wimsey.bc.ca!jlydiatt | of Tom Swiftie.elg@killer.DALLAS.TX.US (Eric Green) (01/19/89)
in article <5707@cbmvax.UUCP>, sterling@cbmvax.UUCP (Rick Sterling QA) says: > In article <6818@killer.DALLAS.TX.US> elg@killer.DALLAS.TX.US (Eric Green) writes: >> Let's say that your file length is an exact multiple of 128 bytes. >> Further, let's say that your file ends with fifteen NUL characters. >> Xmodem will not create an extra empty padding block. Thus an > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> autochopper will chop off 15 bytes of your file. >> > According to my reading of the protocol it should create the extra padding > block with ^Z's ... This is how I implemented it in several term progs in > the past.... History: Ward Christenson needed to transfer binary files from one CP/M system to another. CP/M binary files are all a multiple of 128 bytes long. So all files he transferred were a multiple of 128 bytes long -- with no padding, and with no padding block. If I called your system (which creates the extra padding blocks) with my CP/M system (a Commodore 128 running MEX), and uploaded a binary file, then downloaded it back to myself, what I got back would be incorrect. CP/M is the ultimate test of whether an Xmodem protocol is "right" or not. If it don't work under CP/M, it ain't Real Xmodem. -- Eric Lee Green ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg Snail Mail P.O. Box 92191 Lafayette, LA 70509 Netter A: In Hell they run VMS. Netter B: No. In Hell, they run MS-DOS. And you only get 256k.
shimoda@infohh.rmi.de (Markus Schmidt) (01/19/89)
In article <405@madnix.UUCP> aaron@madnix.UUCP (Aaron Avery) writes: >This is the correct way to do it. This is how I've always done it. This, >however, still cannot deal with the file who's real length exactly fills the >last block. Then, if the last character or few characters are either NULL or >CPM_EOF, they will (incorrectly) get chopped. More people should just support >simple batch Ymodem. It's almost exactly the same as Xmodem (code wise), sends >the filename and length, and handles batch transfers. > Of course my programs also handles YBatch & ZModem. It iws just AT bad that so few other terminalpackages support this 99% solution for chopping. I thik the last pit (len=n*128 and 0/CMP_EOF) is acceptable when you do not have the choice of Y/ZModem (like often here in Germany). Cu Markus
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (01/20/89)
In article <6842@killer.DALLAS.TX.US> elg@killer.DALLAS.TX.US (Eric Green) writes: >History: Ward Christenson needed to transfer binary files from one >CP/M system to another. CP/M binary files are all a multiple of 128 >bytes long. So all files he transferred were a multiple of 128 bytes >long -- with no padding, and with no padding block. This is not quite true. Ward Christensen's spec says that when transferring files which are not a multiple of 128 bytes (such as text files, terminated by ^Z on CP/M) the last sector should be padded with control-Z's, and the receiving system should remove any control-Z's from the end of the last sector if it supports arbitrary sized files. This system will correctly transfer any file as long as the last data byte is not a control-Z. That is the fundamental flaw in Xmodem protocol: that it can not properly transfer a file which ends in ^Z. >If I called your system (which creates the extra padding blocks) with >my CP/M system (a Commodore 128 running MEX), and uploaded a binary >file, then downloaded it back to myself, what I got back would be >incorrect. It shouldn't be incorrect if both sides use the spec'd "chopping" method. >CP/M is the ultimate test of whether an Xmodem protocol is "right" or >not. If it don't work under CP/M, it ain't Real Xmodem. Fine, but that doesn't mean that all files must become padded to a 128-byte boundary in the transfer. -- -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.cts.com - The Unix Programmer's Manual, ...!sdcsvax!crash!elgar!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com
sterling@cbmvax.UUCP (Rick Sterling QA) (01/20/89)
In article <6842@killer.DALLAS.TX.US> elg@killer.DALLAS.TX.US (Eric Green) writes: > in article <5707@cbmvax.UUCP>, sterling@cbmvax.UUCP (Rick Sterling QA) says: > > In article <6818@killer.DALLAS.TX.US> elg@killer.DALLAS.TX.US (Eric Green) writes: > >> Let's say that your file length is an exact multiple of 128 bytes. > >> Further, let's say that your file ends with fifteen NUL characters. > >> Xmodem will not create an extra empty padding block. Thus an > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> autochopper will chop off 15 bytes of your file. > >> > > According to my reading of the protocol it should create the extra padding > > block with ^Z's ... This is how I implemented it in several term progs in > > the past.... > > If I called your system (which creates the extra padding blocks) with > my CP/M system (a Commodore 128 running MEX), and uploaded a binary > file, then downloaded it back to myself, what I got back would be > incorrect. > > CP/M is the ultimate test of whether an Xmodem protocol is "right" or > not. If it don't work under CP/M, it ain't Real Xmodem. > -- > Eric Lee Green ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg What's CP/M ? ;-) Guess I should have qualified the above by saying that this is the required logic for non-CP/M systems to transfer arbitrary length files when the protocol does not transmit file length info. At worst it would add a block to a file for CP/M systems but it would never lose file data. - Rick - -- ============================================================================= Rick Sterling COMMODORE AMIGA TEST ENGINEERING N2CGI UUCP {allegra,rutgers}!cbmvax!sterling =============================================================================
elg@killer.DALLAS.TX.US (Eric Green) (01/21/89)
in article <5742@cbmvax.UUCP>, ditto@cbmvax.UUCP (Michael "Ford" Ditto) says: > In article <6842@killer.DALLAS.TX.US> elg@killer.DALLAS.TX.US (Eric Green) writes: >>If I called your system (which creates the extra padding blocks) with >>my CP/M system (a Commodore 128 running MEX), and uploaded a binary >>file, then downloaded it back to myself, what I got back would be >>incorrect. > It shouldn't be incorrect if both sides use the spec'd "chopping" > method. Note that CP/M generally does not do "chopping", for the simpler reason that it is not necessary (all files are already padded to a 128 byte boundary). Thus my recieved file would be 128 bytes longer than it was when I transmitted it... Nasty. >>CP/M is the ultimate test of whether an Xmodem protocol is "right" or >>not. If it don't work under CP/M, it ain't Real Xmodem. > Fine, but that doesn't mean that all files must become padded to > a 128-byte boundary in the transfer. This originally started as a conversation about flaws of the Xmodem protocol, in particular, about the problem of binary files that are an exact multiple of 128 bytes in length and have control-Z or NUL charcters as their last bytes. "all files must become padded" is not an accurate description of the problem. Your fix, creating an extra block consisting solely of padding, will work, if the reciever does normal auto-chopping. But if the reciever does not, e.g. is a CP/M system, you're breaking things. Breaking things is nasty. The moral: If creating that extra "padding block", allow it to be turned off for systems that don't need or want any kind of extra padding (beyond that of the "fill the last block" variety). -- Eric Lee Green ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg Snail Mail P.O. Box 92191 Lafayette, LA 70509 Netter A: In Hell they run VMS. Netter B: No. In Hell, they run MS-DOS. And you only get 256k.
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (01/23/89)
In <6872@killer.DALLAS.TX.US>, elg@killer.DALLAS.TX.US (Eric Green) writes: >Note that CP/M generally does not do "chopping", for the simpler >reason that it is not necessary (all files are already padded to a 128 >byte boundary). Thus my recieved file would be 128 bytes longer than >it was when I transmitted it... Nasty. I see... it's 'nasty' to change the length of a file. Well, that's what I've bitching about for years, a so-called protocol that mungs files if they don't happen to be CP/M. >This originally started as a conversation about flaws of the Xmodem >protocol, in particular, about the problem of binary files that are an >exact multiple of 128 bytes in length and have control-Z or NUL >charcters as their last bytes. "all files must become padded" is not >an accurate description of the problem. Your fix, creating an extra >block consisting solely of padding, will work, if the reciever does >normal auto-chopping. But if the reciever does not, e.g. is a CP/M >system, you're breaking things. Breaking things is nasty. Yes, breaking things is nasty. It's just too bad that XModem has survived as long as it has. If the rest of the world were like the computer industry, we'd be reading our newspapers on marble slabs. CP/M is as obsolete as XModem. I certainly wouldn't go two inches out of my way to ensure that the file would be aesthetically acceptable to a CP/M user, especially if the padding did not matter on the CP/M system except for that extra 128 bytes. Let 'em chop it themselves. Those of us who chose not to bother with CP/M had to find the workarounds for a braindead protocol that was forced upon us by people who wouldn't know a protocol from a proctologist, and we'll bloody well stick with those workarounds. -larry -- Frisbeetarianism: The belief that when you die, your soul goes up on the roof and gets stuck. +----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------------+