brendan@cs.widener.edu (Brendan Kehoe) (04/05/91)
In <9104032040.AA08669@covax.co.iup.edu>, student@COVAX.CO.IUP.EDU writes: > Now for my question: Is it possible to connect a Commodore 64 to >a VAX for downloading files? I'd like to transfer files at 112,000 or >so baud, a speed which seems to be the maximum for the VAX in my >XMODEM documentation. Yowza. First off, plan to go at 2400 tops (I've heard of 9600 if you use Geoffrey Welsh's IO routines in some terminal program somewhere; I haven't heard of anything using them other than DesTerm). The Vax isn't the limiting speed, the 64 is. Also, answering a question like this can be site dependent. You need to get a terminal program for your 64 (I assume you've built a null-modem since you mention using a direct line) that has some kind of transfer capability. You'll probably find xmodem everywhere, or maybe get a copy of the kermit that was written for the 64. As far as the Vax you're on goes, ask your manager where they've put kermit or xmodem (whichever you have or were able to get for your 64). Then get the Vax to send the file (maybe something like XMODEM SEND BLAH.TXT), and then start the receive on your 64. (Check HELP XMODEM on the Vax, and whatever help or docs that came with your term for the 64, for more info on how to do this exactly with what you're using.) Hope this helps .. not remarkably specific, but hopefully it'll clear up some of the grey spots. -- Brendan Kehoe - Widener Sun Network Manager - brendan@cs.widener.edu Widener University in Chester, PA A Bloody Sun-Dec War Zone Now that we know he has ID, we could give him an account. finger bush@cs....
neusoft@vax1.mankato.msus.edu (04/07/91)
In article <S!R_S_+@cs.widener.edu>, brendan@cs.widener.edu (Brendan Kehoe) writes: > In <9104032040.AA08669@covax.co.iup.edu>, student@COVAX.CO.IUP.EDU writes: >> Now for my question: Is it possible to connect a Commodore 64 to >>a VAX for downloading files? I'd like to transfer files at 112,000 or >>so baud, a speed which seems to be the maximum for the VAX in my >>XMODEM documentation. > > As far as the Vax you're on goes, ask your manager where they've > put kermit or xmodem (whichever you have or were able to get for > your 64). > Then get the Vax to send the file (maybe something like XMODEM SEND > BLAH.TXT), and then start the receive on your 64. (Check HELP XMODEM > on the Vax, and whatever help or docs that came with your term for > the 64, for more info on how to do this exactly with what you're > using.) Be warned however, the Xmodem transfer at our VMS site is VERY buggy and esentially useless for anything beyond a text transfer. I would also suggest not using kermit (see the current kermit argument for details). For up/downloading to our VAX, I use Ymodem (by the way, howcome their is no Zmodem implementations for the 64 or 128?????) but it is not part of the standard system (you have to access it through a special utilities directory). I assume that a VMS Ymodem program would be available at several FTP sites suporting VAX/VMS. If you need a 64 program suporting ymodem, Novaterm (I belive its available at milton) will fit the bill quite nicely. -Mike neusoft@vax1.mankato.msus.edu
brendan@cs.widener.edu (Brendan Kehoe) (04/08/91)
In <1991Apr7.012003.423@vax1.mankato.msus.edu>, neusoft@vax1.mankato.msus.edu writes: > ... (by the way, howcome their is no Zmodem implementations for the >64 or 128?????) This was covered in depth a year or two ago (and as a result, I don't remember all of the arguments very well), but the sum of it is disk i/o. Zmodem, by definition, is not possible on a 64 because of the horrible overhead and lock-out Commodore DOS involves. As a streaming protocol, zmodem can't sit and wait for the disk to do its stuff. On the 128, the same problems occur, but there is one possibility I thought of that hasn't (wasn't) tried out .. have the program use a RAM expansion as the "disk", then after the xfer's done, dump the file that was just received from the expansion module onto the disk. Since it's untested, I can't say this theory is definitely going to work. One problem is the x-nanosecond wait while the DMA controller throws an NMI onto the bus to let it write to the expansion module; that could drop a few bytes, in theory. Anyway, that's what I remember of it. Brendan -- Brendan Kehoe - Widener Sun Network Manager - brendan@cs.widener.edu Widener University in Chester, PA A Bloody Sun-Dec War Zone Now that we know he has ID, we could give him an account. finger bush@cs....
nrossi@jarthur.Claremont.EDU (Nick Rossi) (04/09/91)
In respponse to the Zmodem question with a RAM expander...
The NMI caused by the DMA process in a RAM expander DOES interfere with
incoming data. This can be proven by capturing incoming data directly to a
REU - every 255 bytes or so, a bit of garbage will occur, which is caused by
the DMA. I can see it working with flow control, and it would certainly be
faster than with a disk drive. But I don't think it would be any faster than
the protocols already available on the 64, which is why I and others have
said that it isn't worth the effort to write Zmodem for the 64.
------------------------------ +---------------------------------+
Nick Rossi, '93 | SONY |
------------------------------ | |
Harvey Mudd College | Because caucasians are just |
(ooo HELL is a place on earth) | too damn tall. |
------------------------------ +---------------------------------+treesh@vangogh.helios.nd.edu (04/09/91)
I can see the flames alredy starting to grow on this Zmodem issue again! Zmodem would really be great on the 64/128 if it where at all practical, but dew to the hardware structure of the system and its I/O, timming would just be too critical, and the over-all speed performance would not be worth the efforet, and the effort, to say the least would be one hell of a project for even the best serial hardware programer! Since Swiftlink has come our way, and high baud rates can now be achieved protocols like Ymodem batch, and Xmodem 1K provide pretty fair trasfer rates, espically to a REU. However, there is one protocol that is not yet supported by the c64/128 systems that I have really grown to love on the Amiga system, and its a very simply protocol called Y-Modem-G. This protocol is only useful on modem with MNP-4 or higher. The reason is becase it does not do ANY error checksums, and therefor sends files very fast, and and complexity of the protocol is not present like in X-modem-CRC. The reason this protocol can work at all is because with MNP4 implemented in the modem, there will be NO errors in the data. ctfm
bruce@watnxt2.ucr.edu (Ahmon Dancy) (04/10/91)
On that subject, does anyone know how those error-correcting modems work? ------------------------------------------------------------------------------ Bruce! (Ahmon Dancy) Email Address: bruce@watnxt2.ucr.edu | mail me! Soon to be attending UC Berkeley | EECS major ------------------------------------------------------------------------------
cshamis@desire.wright.edu (04/10/91)
In article <1991Apr9.130813.8840@news.nd.edu>, treesh@vangogh.helios.nd.edu writes: > This > protocol is only useful on modem with MNP-4 or higher. The reason is becase > it does not do ANY error checksums, and therefor sends files very fast, and > and complexity of the protocol is not present like in X-modem-CRC. The reason > this protocol can work at all is because with MNP4 implemented in the > modem, there will be NO errors in the data. > > ctfm Please excuse my ignorance on this matter BUT : If you have MNP on a modem, why would you even NEED a protocol, while not send directly to the modem, (I mean the modem is allready DOING the error checking crap)?? Now I can see that if a file is TOO big to fit in a capture buffer a protocol is always the way to go but I would think that thats the only benifit. Am I a little off base here? CShamis@Desire.Wright.Edu <=-=-=-=- Internet. CShamis@WSU.Bitnet <=-=-=-=- Redundancy (Yah got tah luv it!)
root@zswamp.uucp (Geoffrey Welsh) (04/12/91)
>From: cshamis@desire.wright.edu > If you have MNP on a modem, why would you even NEED a >protocol, while not >send directly to the modem, (I mean the modem is allready >DOING the error checking crap)?? This is a sore point among computer theorists. It is possible that an error may happen between the computer and the modem, and again at the other end. Handshaking, buffer overflow, etc. could comspire to corrupt the data stream. "Not bloody likely, especially over short cables at 9600 bps or lower," say you. You are, of course, correct: the chances are mighty slim... but that doesn't *eliminate* the possibility. I, for one, have operated error-correcting modems at speeds up to 38,400 bps with no form of error correction between the computer and the modem. It worked fine. But many people I know don't have their modems and hosts configured sufficiently well to depend on that. -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 The mile is traversed not by a single leap, but by a procession of coherent steps; those who insist on making the trip in a single element will be failing long after you and I have discovered new worlds. -- me