simon@ms.uky.edu (Simon Gales) (01/28/89)
Has anyone tried porting zmodem to the commodore?
--
/------------------------------------------------------------------------\
Simon Gales@University of Ky
{rutgers, uunet}!ukma!simon - simon@ms.uky.edu - simon@UKMA.BITNETizot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (01/29/89)
> From: simon@ms.uky.edu (Simon Gales) > Message-ID: <10978@s.ms.uky.edu> > Has anyone tried porting zmodem to the commodore? As mentioned in an earlier message, the problem with ZMODEM is that it never stops transmitting. The problem with the C64 is that, if a bit arrives while the C64 is writing to the disk via the serial port (which will happen, since you have to get the data to the disk even though the transmitter never shuts up), the NMI code of the RS-232 drivers takes so long to execute that the sensitive timing of the serial bus is fouled up, resulting in flase EOI's (and of transmission signals) or, worse, lockup. =========================================================================== Internet: Geoffrey.Welsh@f171.n221.z1.fidonet.org | 66 Mooregate Crescent Usenet: watmath!isishq!izot | Suite 602 FidoNet: Geoffrey Welsh on 1:221/171 | Kitchener, Ontario PunterNet: 7/Geoffrey Welsh | N2M 5E6 CANADA BBS: (519) 742-8939 24h 7d 300/1200/2400bps | (519) 741-9553 =========================================================================== | "I don't need a disclaimer. No one pays any attention to what I say." | =========================================================================== -- Geoffrey Welsh - via FidoNet node 1:221/162 UUCP: ...!watmath!isishq!171!izot Internet: izot@f171.n221.z1.FIDONET.ORG
Brendan@cup.portal.com (Brendan P Kehoe) (01/30/89)
I'm in the middle of trying to write a reliable zmodem routine...but it's
got to be *THE* pickiest protocol on this planet.
Brendanjgreco@csd4.milw.wisc.edu (Joe Greco) (01/31/89)
In comp.sys.cbm article <14095@cup.portal.com>, Brendan@cup.portal.com (Brendan P Kehoe) wrote: > I'm in the middle of trying to write a reliable zmodem routine...but it's >got to be *THE* pickiest protocol on this planet. I would think that you would run into several problems with the 1541 as a disk drive. I would think that the fact that the 1541 and RS232 are mutually exclusive (can't listen/talk to RS232 while drive is being used) would be a problem with Z-Modem. That's one reason that Commodore protocols have always been a little limited. . JG -- jgreco@csd4.milw.wisc.edu Joe Greco at FidoNet 1:154/200 USnail: 9905 W Montana Ave PunterNet Node 30 or 31 West Allis, WI 53227-3329 "These aren't anybody's opinions." Voice: 414/321-6184 Data: 414/321-9287 (Happy Hacker's BBS)
mat@emcard.UUCP (W Mat Waites) (02/01/89)
In article <683@csd4.milw.wisc.edu> jgreco@csd4.milw.wisc.edu (Joe Greco) writes: }In comp.sys.cbm article <14095@cup.portal.com>, Brendan@cup.portal.com (Brendan P Kehoe) wrote: }> I'm in the middle of trying to write a reliable zmodem routine...but it's }>got to be *THE* pickiest protocol on this planet. } }I would think that you would run into several problems with the 1541 }as a disk drive. I would think that the fact that the 1541 and RS232 }are mutually exclusive (can't listen/talk to RS232 while drive is }being used) would be a problem with Z-Modem. That's one reason that }Commodore protocols have always been a little limited. } }. JG } }-- }jgreco@csd4.milw.wisc.edu Joe Greco at FidoNet 1:154/200 }USnail: 9905 W Montana Ave PunterNet Node 30 or 31 } West Allis, WI 53227-3329 "These aren't anybody's opinions." }Voice: 414/321-6184 Data: 414/321-9287 (Happy Hacker's BBS) What ever happened to the joker who posted a couple of months ago about building a real UART board? Surely the NMI routines run fast enough to allow response to a uart, i.e. 1 interrupt per character. Another kludgey possibility (and aren't kludges the tradition in c64 telecomm?) would be to allocate a large chunk of memory to hold incoming blocks. That would allow you to cut zmodem loose for 20k bytes worth of data or so, and then hold up zmodem and write it all out. You wouldn't acheive the max throughput of zmodem, but it would be much, much better than xmodem or punter. Mat -- W Mat Waites gatech!emcard!mat 8-5 ET: (404) 727-7197
izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (02/03/89)
> From: mat@emcard.UUCP (W Mat Waites) > Message-ID: <6482@emcard.UUCP> > What ever happened to the joker who posted a couple of months ago about > building a real UART board? I believe there was some discussion on building boards based on the 6850 (a primitive ACIA) or the 6551 (a more integrated ACIA). I designed (but never built) a board that would allow one to use an Intel 8250 or compatible UART with the C64/C128. Best of all, the 8250 could be replaced by a National Semiconductor 16550A, which has 16-byte FIFO buffers on the input and output hold registers (meaning that delaying interrupt recognition for whatever reason would not cause bytes to be lost, and that overhead per byte could be reduced by writing/fetching more than one byte to/from the buffers at a time. > Surely the NMI routines run fast enough to allow response to a uart, i.e. > 1 interrupt per character. But the NMIs that react to each bit are no longer (in fact I'd be willing to bet shorter) than the NMI to pack away the byte. The difference is in how often they come up (i.e. how much CPU time BETWEEN interrupts, not how much time is spent executing them). If a UART interrupt has time to pack a byte into a buffer, then my routines have time to flag in one bit and shift it into a byte. The quesiton is, how much do we reduce the disk's speed (400 CPS on a good day, following a full moon, if your dinner digested well last night - Jim Butterfield) by stopping all the time to deal with incoming bits? > That would allow you to cut zmodem loose for 20k bytes > worth of data or so, and then hold up zmodem and write it all out. > You wouldn't acheive the max throughput of zmodem, but it would be much, > much better than xmodem or punter. Although ZMODEM can technically be implemented as a windowing or normal block-handshake protocol, I have yet to find a single implementation of ZMODEM that mentioned this abilility. I suspect that most existsing ZMODEM drivers were written to be streaming (non-stop) and would choke if any attempt was made to stop them (especially generating timeouts while waiting for a 1541 to write 20K to the disk!). Geoff ( watmath!isishq!izot ) -- Geoffrey Welsh - via FidoNet node 1:221/162 UUCP: ...!watmath!isishq!171!izot Internet: izot@f171.n221.z1.FIDONET.ORG
jgreco@csd4.milw.wisc.edu (Joe Greco) (02/03/89)
In comp.sys.cbm article <6482@emcard.UUCP>, mat@emcard.UUCP (W Mat Waites) wrote: ]What ever happened to the joker who posted a couple of months ago about ]building a real UART board? Are you referring to ME? I don't have the facilities, and I have been trying to talk somebody into doing it for me :-) ]Surely the NMI routines run fast enough to allow response to a uart, i.e. ]1 interrupt per character. Definitely. I would see very little problems with allowing simultaneous serial bus access and UART I/O (if the UART NMI is fast enough). ]Another kludgey possibility (and aren't kludges the tradition in c64 Yes they are.... heh ]telecomm?) would be to allocate a large chunk of memory to hold ]incoming blocks. That would allow you to cut zmodem loose for 20k bytes ]worth of data or so, and then hold up zmodem and write it all out. ]You wouldn't acheive the max throughput of zmodem, but it would be much, ]much better than xmodem or punter. Z-Modem might time-out while the 64 was saving the data. I don't know, I've never tried it. -- jgreco@csd4.milw.wisc.edu Joe Greco at FidoNet 1:154/200 USnail: 9905 W Montana Ave PunterNet Node 30 or 31 West Allis, WI 53227-3329 "These aren't anybody's opinions." Voice: 414/321-6184 Data: 414/321-9287 (Happy Hacker's BBS)
Brendan@cup.portal.com (Brendan P Kehoe) (02/03/89)
What I've been experimenting with is using the REU...receive like 16k then
throw it into the reu then let the zmodem routine keep on buzzing happily
since a dma call takes virtually no time..hmm....any suggestions?
Brendan@cup.portal.comelg@killer.DALLAS.TX.US (Eric Green) (02/03/89)
in article <6482@emcard.UUCP>, mat@emcard.UUCP (W Mat Waites) says: > What ever happened to the joker who posted a couple of months ago about > building a real UART board? My brother designed and built a real UART board. However, it has the slight problem of being incompatible with most terminal programs, since the drivers are in RAM and not ROM. This is easily solved by modifying the ROMs, but I haven't moved his code into "ROM" yet (I have a "soft Kernal ROM" setup that I use for such prototyping purposes). I'm thinking about sending some of this stuff to The Transactor. Maybe you'll eventually see some of it there, at least in its current (non-commercial-quality but usable) state. > Surely the NMI routines run fast enough to allow response to a uart, i.e. > 1 interrupt per character. Nope. We got big-time serial-bus lockup when we tried. Turning the RS232 NMI's off when accessing disk solved that problem. It's easy enough to see why, when you see the Kernal ROM: (ARGH! I can't find my annotated Kernal at the moment... anyhow...) Do byte-level handshaking. OK, got handshake, wait for individual bits: lp: Wait for bus to settle shift clock bit into carry, if not clock goto lp: shift bit into byte, exit loop if got full byte. Wait for clock to fall again, e.g. another loop like above jmp lp: T(v) is on the order of 20us. Looking at the C-64's serial bus output routines (which presumably are duplicated inside the 1541), there's only 20 instructions or so executed per each time thru the loop that's shifting these bits out... it's shifting the bits out as fast as it can, except for a 4-NOP delay and waiting for the bus to settle. There's little chance of responding to a NMI in this sort of time frame. Heck, it takes most of that just to save/restore the registers! > Another kludgey possibility (and aren't kludges the tradition in c64 > telecomm?) would be to allocate a large chunk of memory to hold > incoming blocks. That would allow you to cut zmodem loose for 20k bytes This would work fairly well, actually. It would give you the advantages of Ymodem (the big block size), without the disadvantage (having to re-send that whole big block upon error). If you have a fast drive, it might actually be worthwhile. With a 1541, regular Xmodem is just as fast, unless you're using PC Pursuit (which is going away). -- | // Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 | | // ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg (318)989-9849 | | \X/ >> In Hell you need 4Mb to Multitask << |
jgreco@csd4.milw.wisc.edu (Joe Greco) (02/04/89)
In comp.sys.cbm article <14246@cup.portal.com>, Brendan@cup.portal.com (Brendan P Kehoe) wrote: > What I've been experimenting with is using the REU...receive like 16k then >throw it into the reu then let the zmodem routine keep on buzzing happily >since a dma call takes virtually no time..hmm....any suggestions? First, the REU access would probably kill one or two incoming characters. DMA has a nasty habit of interrupting the NMI timing because the processor cannot service the NMI. Second, one could not download files larger than {128K, 256K, 512K}. Nice idea, otherwise. -- jgreco@csd4.milw.wisc.edu Joe Greco at FidoNet 1:154/200 USnail: 9905 W Montana Ave PunterNet Node 30 or 31 West Allis, WI 53227-3329 "These aren't anybody's opinions." Voice: 414/321-6184 Data: 414/321-9287 (Happy Hacker's BBS)
A-N-Onymouse@cup.portal.com (John - DeBert) (02/05/89)
That joker who posted in this conference about a UART PCB a few months ago was I. Really. I did build a UART to add to my 64 so that I could use my Hazeltine, Hazel. It worked fairly well but it did not help speed up disk access. Of course, it would make "RS-232" communications more efficient, taking less CPU over- head, obviously. The disk i/o process is still a big stumbling block for the zmodem stuff being discussed here. Of course, you can always build another add-on card dedicated exclusively to disk i/o and add a huge RAM buffer... The ciruitry for the UART card and another PCB will be submitted to the Transactor for publication, as soon as I finish beautifying the drawings, for those of you who want to see it. I no longer have my 64 or any of the software. Not even notes on the driver for the UART, so I cannot provide any details but once you-all see the circuit, coming up with a driver for it should be a piece of cake. JJD A-N-Onymouse@cup.portal.com
Brendan@cup.portal.com (Brendan P Kehoe) (02/06/89)
In comp.sys.cbm article <766@csd4.milw.wisc.edu>, jgreco@csd4.milw.wisc.edu writes: >In comp.sys.cbm article <14246@cup.portal.com>, Brendan@cup.portal.com (Brendan P Kehoe) wrote: >> What I've been experimenting with is using the REU...receive like 16k then >>throw it into the reu then let the zmodem routine keep on buzzing happily >>since a dma call takes virtually no time..hmm....any suggestions? > >First, the REU access would probably kill one or two incoming >characters. DMA has a nasty habit of interrupting the NMI timing >because the processor cannot service the NMI. > >Second, one could not download files larger than {128K, 256K, 512K}. The reason I thought of using the REU was because of their capacity; I don't often download programs larger than, say, 500 blocks (approx 124k)...the 1750 would more than do for this..anyway...can you think of a way to shield the rs232 incoming line and the triggering of the nmi from the dma call without a break in tempo? If we could figure out a way to keep the dma from slamming the nmi's, we may be on to something here. > >Nice idea, otherwise. >-- >jgreco@csd4.milw.wisc.edu Joe Greco at FidoNet 1:154/200 >USnail: 9905 W Montana Ave PunterNet Node 30 or 31 > West Allis, WI 53227-3329 "These aren't anybody's opinions." >Voice: 414/321-6184 Data: 414/321-9287 (Happy Hacker's BBS) Brendan@cup.portal.com
elg@killer.DALLAS.TX.US (Eric Green) (02/06/89)
in article <766@csd4.milw.wisc.edu>, jgreco@csd4.milw.wisc.edu (Joe Greco) says: > In comp.sys.cbm article <14246@cup.portal.com>, Brendan@cup.portal.com (Brendan P Kehoe) wrote: >> What I've been experimenting with is using the REU...receive like 16k then >>throw it into the reu then let the zmodem routine keep on buzzing happily >>since a dma call takes virtually no time..hmm....any suggestions? > First, the REU access would probably kill one or two incoming > characters. DMA has a nasty habit of interrupting the NMI timing > because the processor cannot service the NMI. Solvable. Zmodem allows flow control. Do a control-S, wait until the flow of characters in stops, then do your DMA. Send a control-Q, then restart. The reason this can't be used for everything is that Zmodem also has strict timeout requirements for flow control. If you don't control-Q for awhile, Zmodem will assume you barfed and will go away. The REU is plenty fast to get around this problem. The 1541 may not be. One problem is that the regular RS232 routines have trouble sending and recieving at the same time, so sending a control-S could barfle an incoming character.... > Second, one could not download files larger than {128K, 256K, 512K}. Is that really a limitation? I rarely see files bigger than 300 blocks (half a 1541), because most people use ARC or LYNX with a single 1541 drive and couldn't de-archive anything bigger than 80K. -- | // Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 | | // ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg (318)989-9849 | | \X/ >> In Hell you need 4Mb to Multitask << |
izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (02/07/89)
> From: elg@killer.DALLAS.TX.US (Eric Green) > Message-ID: <7050@killer.DALLAS.TX.US> > Solvable. Zmodem allows flow control. Do a control-S, wait until the > flow of characters in stops, then do your DMA. Send a control-Q, then > restart. Not all implementations implement that properly. > One problem is that the regular RS232 routines have trouble sending > and recieving at the same time, so sending a control-S could barfle an > incoming character.... Since we're writing fancy code, a decent RS-232 driver (which would solve that problem completely on a C64 doing 2400 bps) would be no problem. > > Second, one could not download files larger than {128K, 256K, 512K}. > > Is that really a limitation? I rarely see files bigger than 300 blocks > (half a 1541), because most people use ARC or LYNX with a single > 1541 drive and couldn't de-archive anything bigger than 80K. Speak for yourself! When I was still using my CBM 8-bit stuff, I never had a computer that wasn't connected to at least one 1-meg drive (SFD, 8250). 1581 offers nearly that, and 8050 (like Joe Greco uses) offers a comfortable 1/2 meg. Any CBM hacker interested in top-notch performance threw his 1541 into a corner (if not out the window) long ago. Geoff ( watmath!isishq!izot ) -- Geoffrey Welsh - via FidoNet node 1:221/162 UUCP: ...!watmath!isishq!171!izot Internet: izot@f171.n221.z1.FIDONET.ORG
elg@killer.DALLAS.TX.US (Eric Green) (02/13/89)
in article <1573.23F37816@isishq.FIDONET.ORG>, izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) says: $ > > Second, one could not download files larger than {128K, 256K, 512K}. $ > $ > Is that really a limitation? I rarely see files bigger than 300 blocks $ > (half a 1541), because most people use ARC or LYNX with a single $ > 1541 drive and couldn't de-archive anything bigger than 80K. $ $ Speak for yourself! When I was still using my CBM 8-bit stuff, I never had $ a computer that wasn't connected to at least one 1-meg drive (SFD, 8250). 1581 $ offers nearly that, and 8050 (like Joe Greco uses) offers a comfortable 1/2 $ meg. Any CBM hacker interested in top-notch performance threw his 1541 into a $ corner (if not out the window) long ago. While the serious speed freeks through out their 1541s, the majority of C-64 users still use them, for the same reason they have C-64s in the first place -- cost. I rarely see software for download on a BBS that's longer than around 300 blocks, for the simple reason that most of the USERS of that BBS could not use it (and thus the sysop won't keep around anything bigger, because most of his users can't download it). BTW, the 1541 does have one serious advantage over more "modern" hardware. I've never seen a copy program for, say, a 1581 or SFD-1001 that'd copy at anywhere near the data rate of the fastest 1541 copiers (around 40 seconds for 160K? Thats, hmm, 4Kbytes/second). The old 8050 I have hooked to the BBS might manage that, but I've never used its builtin diskcopy command, so I really don't know (when I do backups, I use the internal filecopy command, to un-fragment the disk -- and that takes FOREVER). -- | // Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 | | // ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg (318)989-9849 | | \X/ >> In Hell you need 4Mb to Multitask << |
izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (02/15/89)
> From: elg@killer.DALLAS.TX.US (Eric Green) > Message-ID: <7125@killer.DALLAS.TX.US> > BTW, the 1541 does have one serious advantage over more "modern" > hardware. I've never seen a copy program for, say, a 1581 or SFD-1001 > that'd copy at anywhere near the data rate of the fastest 1541 copiers > (around 40 seconds for 160K? Thats, hmm, 4Kbytes/second). The old 8050 > I have hooked to the BBS might manage that, but I've never used its > builtin diskcopy command, so I really don't know (when I do backups, I > use the internal filecopy command, to un-fragment the disk -- and that > takes FOREVER). Ugh! (either way) The 8050 will diskcopy half a meg in six minutes. Much of that time (1:40) is spent formatting the disk. An acquaintance of mine is running a BBS on two SFD's, and I once promised him a fast backup program. I haven't got the equipment here to do it with so it hasn't gotten beyond the coding stages but, if and when I get it done, it ought to be fairly impressive (keeping in mind that it will not execute any custom code in the SFD's). =========================================================================== Internet: Geoffrey.Welsh@f171.n221.z1.fidonet.org | 66 Mooregate Crescent Usenet: watmath!isishq!izot | Suite 602 FidoNet: Geoffrey Welsh on 1:221/171 | Kitchener, Ontario PunterNet: 7/Geoffrey Welsh | N2M 5E6 CANADA BBS: (519) 742-8939 24h 7d 300/1200/2400bps | (519) 741-9553 =========================================================================== | "I don't need a disclaimer. No one pays any attention to what I say." | =========================================================================== -- Geoffrey Welsh - via FidoNet node 1:221/162 UUCP: ...!watmath!isishq!171!izot Internet: izot@f171.n221.z1.FIDONET.ORG
Hank@cup.portal.com (Hank W Oxford) (02/28/89)
Perhaps getting Zmodem to run on a Commodore isn't as difficult as
everyone thinks. Zmodem does not *have* to send data constantly.
Taken from various places in the Zmodem Reference:
ZMODEM allows a choice of data streaming methods
selected according to the limitations of the sending
program operating environment, receiving program
operating environment, and the transmission channel(s).
If the receiver cannot overlap serial and disk I/O, it
uses the ZRINIT frame to specify a buffer length which
the sender will not overfill before sending a ZCRCW
packet.
ZCRCW data packets expect a response before the next
frame is sent. If the receiver does not indicate
overlapped I/O capability with the CANOVIO bit, the
sender uses the ZCRCW to allow the receiver to write its
buffer before sending more data.jgreco@csd4.milw.wisc.edu (Joe Greco) (03/01/89)
In comp.sys.cbm article <15177@cup.portal.com>, Hank@cup.portal.com (Hank W Oxford) wrote: ]Perhaps getting Zmodem to run on a Commodore isn't as difficult as ]everyone thinks. Zmodem does not *have* to send data constantly. ]Taken from various places in the Zmodem Reference: ] ZMODEM allows a choice of data streaming methods ] selected according to the limitations of the sending ] program operating environment, receiving program ] operating environment, and the transmission channel(s). ] If the receiver cannot overlap serial and disk I/O, it ] uses the ZRINIT frame to specify a buffer length which ] the sender will not overfill before sending a ZCRCW ] packet. ] ZCRCW data packets expect a response before the next ] frame is sent. If the receiver does not indicate ] overlapped I/O capability with the CANOVIO bit, the ] sender uses the ZCRCW to allow the receiver to write its ] buffer before sending more data. Obviously this fella has never encountered real world implementations of Z-Modem :-) :-) :-) :-) Come on, when was the last time anybody did even a 3/4 implementation of Z-Modem? There are probably a lot of reasonably good ones out there. No fault of the authors, since Z-Modem is a complex protocol and a "full" implementation is almost unreasonable. -- jgreco@csd4.milw.wisc.edu Joe Greco at FidoNet 1:154/200 USnail: 9905 W Montana Ave PunterNet Node 30 or 31 West Allis, WI 53227-3329 "These aren't anybody's opinions." Voice: 414/321-6184 Data: 414/321-9287 (Happy Hacker's BBS)