FYI, I just posted the source code to my GBBS Zmodem drivers to comp.binaries.apple2 -- the source code is public domain now (and is marked as such). Feel free (and please do!) to use it in any projects you might do.
RZ and SZ each take up about 5k as binaries without the 1.5k CRC lookup tables.
Both RZ and SZ each need at least 8k of buffer space, but no more than 16k of buffer space. Both use CRC-32 error checking.
andy
-- Andy Nicholas GEnie & America-Online: shrinkit System Software Engineer CompuServe: 70771,2615 Apple Computer, Inc. InterNET: shrin...@apple.com
I remember someone stating that Z-modem is impossible to do on an Apple //, mainly because it is a streaming protocol and the Apple can't directly write the incoming data to the HD; instead having to pause to write. Does your code automatically pause the send, load the data or save the necessary data, and continue sending? ---- ProLine: talon@pro-odyssey Internet: ta...@pro-odyssey1.cts.com UUCP: crash!pro-odyssey!talon ARPA: crash!pro-odyssey!ta...@nosc.mil
ta...@pro-odyssey.cts.com (Joe Quilici) writes: >In-Reply-To: message from shrin...@Apple.COM >I remember someone stating that Z-modem is impossible to do on an Apple //, >mainly because it is a streaming protocol and the Apple can't directly >write the incoming data to the HD; instead having to pause to write. Does >your code automatically pause the send, load the data or save the necessary >data, and continue sending?
At the risk of putting words in Andy's mouth, his code has to do one of two things:
tell the other end to pause sending just write to the disk and let the garbled packet be retransmitted
ANY micro using a disk controller that causes interrupt blackouts faces the same choice, and in no way does it prevent one from implementing Zmodem. It does put take a bite out of the maximum transfer rate though.
In article <1991Jul30.115721.5...@crash.cts.com> ta...@pro-odyssey.cts.com (Joe Quilici) writes: >I remember someone stating that Z-modem is impossible to do on an Apple //, >mainly because it is a streaming protocol and the Apple can't directly >write the incoming data to the HD; instead having to pause to write. Does >your code automatically pause the send, load the data or save the necessary >data, and continue sending?
Yes. That's one of the provisions of Zmodem; you can specify a buffer size if you are the receiver or respect the buffer size of your receiver if you are the sender. ProTerm v2.2 does the latter, but not the former. My code does both.
And, whoever said that Zmodem is impossible to do on an Apple II didn't know anything about Zmodem.
andy
-- Andy Nicholas GEnie & America-Online: shrinkit System Software Engineer CompuServe: 70771,2615 Apple Computer, Inc. InterNET: shrin...@apple.com
In article <1991Jul30.115721.5...@crash.cts.com> ta...@pro-odyssey.cts.com (Joe Quilici) writes: > In-Reply-To: message from shrin...@Apple.COM
> I remember someone stating that Z-modem is impossible to do on an Apple //, > mainly because it is a streaming protocol and the Apple can't directly > write the incoming data to the HD; instead having to pause to write.
ZMODEM doesn't have to be used in 'streaming' mode. There is an initial handshake in which the sender and receiver decide how they will talk to each other. If the receiver can't handle streaming, it can tell the sender to wait for an acknowledgement before sending the next block. Alternatively it could send a message saying 'hang on, I've lost some data. Can you please re-send from byte XXX'.
Streaming doesn't require writing incoming data directly to the hard drive. It only requires that incoming data is not lost while the hard drive is being accessed (i.e. interrupts are not disabled for very long) and that the hard drive can be written to faster than the data is coming in.
This is usually the case, unless you are writing to a floppy disk...
|
