Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!pacbell.com!iggy.GW.Vitalink.COM!widener!brendan
From: brendan@cs.widener.edu (Brendan Kehoe)
Newsgroups: comp.sys.cbm
Subject: Re: Interfacing a Commodore 64 with a VAX/VMS
Message-ID: <2HV_JWD@cs.widener.edu>
Date: 8 Apr 91 13:18:17 GMT
References: <9104032040.AA08669@covax.co.iup.edu> <S!R_S_+@cs.widener.edu> <1991Apr7.012003.423@vax1.mankato.msus.edu>
Organization: Widener CS Dept
Lines: 25

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....