leblanc@eecg.toronto.edu (Marcel LeBlanc) (04/24/89)
[] Not that long ago, a discussion about the difficulties of implementing ZMODEM on the C64/C128 was side-tracked by a discussion of fast disk I/O :-). The discussion centered around the requirement for simultaneous disk and RS-232 processing when a file is being received. For IEEE-488 interface owners, this isn't too much of a problem, but the rest of us might still have to accept droping a few packets while saving the receive buffer to disk. Somebody made a suggestion about REAL simultaneous disk (standard serial) and RS-232, but I don't remember the details. The problem with using an REU is that the time required for the DMA transfer could cause a few incoming RS-232 bits to be lost. I'd like to suggest another REU alternative: - use a small ZMODEM receive buffer (say 256 bytes). When it fills, set a flag indicating that it must be saved to the REU. - add a little extra code at the end of the NMI (RS-232) routine to initiate a DMA transfer of the receive buffer to the REU. The DMA transfer must be initiated when it is certain that no bits are about to arrive. The most convenient "safe" time that I can think of is at the end of the NMI processing. At 2400 NMIs/sec, this only allows about 400 cycles per bit. I'm not sure if this is enough to transfer a 256 byte buffer (400-256 cycles only leaves 144, comments Geoff?), but for higher bit rates, the buffer size would probably have to be reduced. Since I have no intention of ever writing these routines, they will remain just ideas. Any comments are welcome. (within reason :-) ) Marcel A. LeBlanc | University of Toronto -- Toronto, Canada leblanc@eecg.toronto.edu | also: LMS Technologies Ltd, Fredericton, NB, Canada ------------------------------------------------------------------------------- UUCP: uunet!utai!eecg!leblanc BITNET: leblanc@eecg.utoronto (may work)
izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (04/25/89)
> From: leblanc@eecg.toronto.edu (Marcel LeBlanc) > Message-ID: <89Apr24.010003edt.2376@godzilla.eecg.toronto.edu> > I'd like to suggest another REU alternative: > > - use a small ZMODEM receive buffer (say 256 bytes). When it fills, set a > flag indicating that it must be saved to the REU. > - add a little extra code at the end of the NMI (RS-232) routine to > initiate a DMA transfer of the receive buffer to the REU. > > The DMA transfer must be initiated when it is certain that no bits are > about > to arrive. The most convenient "safe" time that I can think of is at the > end of the NMI processing. At 2400 NMIs/sec, this only allows about 400 > cycles per bit. I'm not sure if this is enough to transfer a 256 byte > buffer (400-256 cycles only leaves 144, comments Geoff?), but for higher > bit > rates, the buffer size would probably have to be reduced. Your calculations are accurate. I'm pretty sure that none of our routines run longer than 144 clock cycles (ironically, the last bit takes the longest to process because the byte has to be placed in an indexed buffer that might be full). Your idea is worth a look, but not for ZMODEM, which is frankly too complex to code from scratch in 6502, given the small monetary advantage it might offer. -- Geoffrey Welsh - via FidoNet node 1:221/162 UUCP: ...!watmath!isishq!171!izot Internet: izot@f171.n221.z1.FIDONET.ORG
dg@lakart.UUCP (David Goodenough) (04/26/89)
leblanc@eecg.toronto.edu (Marcel LeBlanc) sez: > Not that long ago, a discussion about the difficulties of implementing > ZMODEM on the C64/C128 was side-tracked by a discussion of fast disk I/O > :-). The discussion centered around the requirement for simultaneous disk > and RS-232 processing when a file is being received. If you read the ZMODEM documentation, overlapping disk access and serial I/O is not required for ZMODEM, it just makes it go faster. [ This is also true if you _DON'T_ read the documentation :-) Sometimes I say some damn silly things :-) :-) ] -- dg@lakart.UUCP - David Goodenough +---+ IHS | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@xait.xerox.com +---+
izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (04/29/89)
> From: dg@lakart.UUCP (David Goodenough) > Message-ID: <514@lakart.UUCP> > If you read the ZMODEM documentation, overlapping disk access and serial > I/O is not required for ZMODEM, it just makes it go faster. Irrelevant. Streaming (which requires simultaneous modem & disk I/O) is ZMODEM's performance edge. Without it, ZMODEM offers no performance advantage over YMODEM. -- Geoffrey Welsh - via FidoNet node 1:221/162 UUCP: ...!watmath!isishq!171!izot Internet: izot@f171.n221.z1.FIDONET.ORG
dg@lakart.UUCP (David Goodenough) (05/01/89)
From article <2289.245A8619@isishq.FIDONET.ORG>, by izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh): > > > From: dg@lakart.UUCP (David Goodenough) > > Message-ID: <514@lakart.UUCP> > > > If you read the ZMODEM documentation, overlapping disk access and serial > > I/O is not required for ZMODEM, it just makes it go faster. > > Irrelevant. Streaming (which requires simultaneous modem & disk I/O) is > ZMODEM's performance edge. Without it, ZMODEM offers no performance advantage > over YMODEM. Not strictly true. _CONTINUOUS_ streaming requires overlapping disk I/O and serial I/O. But suppose you're working (as I do in QTERM) with 8K reads and writes at a time. In Ymodem, over a packet switch network (i.e. PC-Pursuit) you can take as much as 6 - 7 seconds per K at 2400BPS: 4 to send the data, and 3 to wait for the ACK to come back. So a 16K file takes 96 seconds, plus disk access time. Now with Zmodem, you _CAN_ acheive 4 seconds per packet, and lose three to six seconds per 8K for holding up, and writing. So you now get the file down in 70 to 75 seconds, i.e. about a 25% improvement. In effect I could keep up the streaming for 30 seconds at a time, and then go off & do some disk access, because anyone can stream while they're not talking to the disk. Of course, if you write each sector to disk as it arrives, all bets are off (but that's much harder on the system in general, and takes longer - hence my choice of 8K buffers). BTW these are real figures: I've received stuff using Ymodem over PC-P and it is sloooooooowwwwwww.