Hank@cup.portal.com (Hank W Oxford) (03/05/89)
Joe Greco: 1) As to 3/4 implementations, most PC BBS's are using Forsberg's own DSZ. If that isn't a full implementation, then what is. On non-PC based BBS's, such as possible Commodore implementations, it would be up to the person writing protocol driver. It would be very odd for someone to write a Zmodem driver for a Commodore that wouldn't work on Commodores, wouldn it? 2) In reference to Tandy PC's disk and serial I/O: Do you own EVERY Tandy PC? No? I didn't think so. I said _some_ Tandy PC's have such a problem. Some of the less expensive models will not (do not) support DMA.
izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (03/06/89)
> From: Hank@cup.portal.com (Hank W Oxford) > Message-ID: <15397@cup.portal.com> > > 1) As to 3/4 implementations, most PC BBS's are using Forsberg's own > DSZ. Nonsense. PCBoard v14, Opus, QuickBBS, and plenty of others provide internal ZMODEM support. Terminal programs like Telix also provide internal support, so that a BBS program supporting ZMODEM would have to deal with the shortcomings (if there are any) in all the terminals out there. > 2) In reference to Tandy PC's disk and serial I/O: > Do you own EVERY Tandy PC? No? I didn't think so. I said _some_ Tandy > PC's have such a problem. Some of the less expensive models will not > (do not) support DMA. I think Joe was talking about a C64 and an IEEE-488 drive. That setup doesn't support DMA, either, but has no problems running the RS-232 port & drives at the same time. =========================================================================== 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
elg@killer.Dallas.TX.US (Eric Green) (03/12/89)
in article <1786.2416BB83@isishq.FIDONET.ORG>, izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) says: > > From: Hank@cup.portal.com (Hank W Oxford) > > 1) As to 3/4 implementations, most PC BBS's are using Forsberg's own > > DSZ. > Nonsense. PCBoard v14, Opus, QuickBBS, and plenty of others provide > internal ZMODEM support. Terminal programs like Telix also provide > internal Most of which programs are written in "C". Forsberg has released the "C" source code to Zmodem protocol (see Unix "sz" and "rz"), which is easily put into any program written in "C" (after inevitable modifications to deal with OS differences... and assuming you have a real computer to compile it on ;-). > I think Joe was talking about a C64 and an IEEE-488 drive. That setup > doesn't support DMA, either, but has no problems running the RS-232 port & > drives at the same time. I wouldn't be so saguine about the perfection of simultaneous IEEE-488 and RS-232. I have tried out both the C-Link II and IEEE Flash and found that if you do not disable the RS232 NMIs before doing disk I/O, you will occasionally get a garbled character from the disk. Especially bad was the case where incoming RS232 would corrupt writes to the disk -- I lost several internal BBS file directories to that problem, before I finally wrote a little wedgie to catch all chkin/chkout and turn off incoming RS232. I have not dug through their modified Kernels to find out the exact reason (plus, in the case of the Link it's a bit difficult -- they have 16K of EPROM, and bank-switch the damned thing), but I suspect it's a matter of timing. It's interesting that drive timing had a lot of significance in the matter too -- it would happen with some SFD's, and not with others. I suspect that the situation would be a lot better with a good IEEE interface (e.g. the Buscard II or the original SKyles Quicksilver), but still wouldn't trust it. -- | // Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 | | // ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg (318)989-9849 | | \X/ amoy mi amiga, pero no me gusta bazofia-DOS.
jgreco@csd4.milw.wisc.edu (Joe Greco) (03/12/89)
In comp.sys.cbm article <1786.2416BB83@isishq.FIDONET.ORG>, izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) wrote: [ note, this is a reply to BOTH Hank and Geoff ] ] > From: Hank@cup.portal.com (Hank W Oxford) ] > Message-ID: <15397@cup.portal.com> ] > ] > 1) As to 3/4 implementations, most PC BBS's are using Forsberg's own ] > DSZ. ] ] Nonsense. PCBoard v14, Opus, QuickBBS, and plenty of others provide ]internal ZMODEM support. Terminal programs like Telix also provide internal ]support, so that a BBS program supporting ZMODEM would have to deal with the ]shortcomings (if there are any) in all the terminals out there. That sounds like a more reasonable assumption to me, Geoff. Somehow I doubted that a single implementation was universal. Heck, even Punter protocol has been written from scratch by a few folks. ] > 2) In reference to Tandy PC's disk and serial I/O: ] > Do you own EVERY Tandy PC? No? I didn't think so. I said _some_ Tandy ] > PC's have such a problem. Some of the less expensive models will not ] > (do not) support DMA. ] ] I think Joe was talking about a C64 and an IEEE-488 drive. That setup ]doesn't support DMA, either, but has no problems running the RS-232 port & ]drives at the same time. (checks newsgroups: line.... um, comp.sys.cbm...) 2) In reference to Tandy PC's disk and serial I/O: (a) I don't care how atrocious it is or is not. (b) This is comp.sys.cbm, not comp.sys.ibm-uncompatible. Geoff's assumption of what I am talking about is certainly correct. Where you get your assumption is a mystery to me. (c) I do not own ANY Tandy PC, and the chances are very very good that I never will. I have seen the difficulties others have with them, and I am not willing to pay outrageous T/RS prices for inferior products. (d) I was under the impression that the general PC architecture relied on DMA for DRAM refresh. The one design I've actually SEEN did it using DMA. How do the cheaper (don't be afraid to say it) Tandy units do it? (e) Do YOU own every Tandy PC? -- 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)
izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (03/14/89)
> From: elg@killer.Dallas.TX.US (Eric Green) > Message-ID: <7509@killer.Dallas.TX.US> > I wouldn't be so saguine about the perfection of simultaneous IEEE-488 > and RS-232. I have tried out both the C-Link II and IEEE Flash and > found that if you do not disable the RS232 NMIs before doing disk I/O, > you will occasionally get a garbled character from the disk. The one and only reason why Steve Punter's BBS64 (in my opinion by far the best C64 BBS program) works only with IEEE-488 drives is that it makes no effort whatsoever to arbitrate in some way between disk and modem I/O. It thinks nothing of reading a line from a message file, dumping it to the buffer, and going immediately for the next line. That is why BBS64 looks so much smoother than BBS programs that work with serial drives. Although it's easy to trip up the RS-232 on BBS64 at 1200 and 2400 bps, I have never seen it misbehave in the least because of garbled disk reads (and I ran a BBS64 system for three years as well as using several for a couple of years before that and since). There is an interesting fact to note here: BBS64 does not work with the C64-Link II because of timing problems. It works flawlessly with the BusCard II, the original C64-Link, and the G-Link with the new ROMs in it. I can't help but wonder if the problem lies in timing/code that was borderline to begin with, and not the result of massive RS-232-induced problems. > I suspect that the situation would be a lot better with a good IEEE > interface (e.g. the Buscard II or the original SKyles Quicksilver), > but still wouldn't trust it. Whoops, sorry. You now know the answer to that one. ============================================================================ Usenet: watmath!isishq!izot | 66 Mooregate Crescent Internet: Geoffrey.Welsh@f171.n221.z1.fidonet.org | Suite 602 FidoNet: Geoffrey Welsh on 1:221/171 | Kitchener, Ontario PunterNet: 7/GEOFFREY WELSH | N2M 5E6 CANADA BBS: (519) 742-8939 24h/7d 9600 USRobotics HST | (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
eravin@dasys1.UUCP (Ed Ravin) (03/16/89)
In article <7509@killer.Dallas.TX.US> elg@killer.Dallas.TX.US (Eric Green) writes: >I wouldn't be so saguine about the perfection of simultaneous IEEE-488 >and RS-232. I have tried out both the C-Link II and IEEE Flash and >found that if you do not disable the RS232 NMIs before doing disk I/O, >you will occasionally get a garbled character from the disk. >Especially bad was the case where incoming RS232 would corrupt writes >to the disk -- I lost several internal BBS file directories to that >problem... >I suspect that the situation would be a lot better with a good IEEE >interface (e.g. the Buscard II or the original SKyles Quicksilver), >but still wouldn't trust it. I wouldn't trust it either. When me and a friend developed the FROG-BBS, a C64 BBS program, one of the devices we supported was the Buscard II. We had exactly this problem: RS-232 NMI's would scramble data being read from the disk, which would eventually cause us to crash when critical data (such as pointers to messages) became garbled. We ended up re-inserting the RS-232 holdoff the Kernal usually has for these situations into our own software. Otherwise, the Buscard II was just wonderful, thought it wasn't quite as fast as the IEEE-488 interface that MSD provided. The MSD interface had other problems, though, including needing a SYS call to be activated (yuk) and taking up 2k or so of memory away from BASIC (big YUK, since our BBS program needs all the memory it can get and then some). -- Ed Ravin | cucard!dasys1!eravin | "A mind is a terrible thing (BigElectricCatPublicUNIX)| eravin@dasys1.UUCP | to waste-- boycott TV!" --------------------------+----------------------+----------------------------- Reader bears responsibility for all opinions expressed in this article.
izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (03/16/89)
> From: eravin@dasys1.UUCP (Ed Ravin) > Message-ID: <9012@dasys1.UUCP> > Otherwise, the Buscard II was just wonderful, thought it wasn't quite as > fast as the IEEE-488 interface that MSD provided. The MSD interface had > other problems, though, including needing a SYS call to be activated (yuk) > and taking up 2k or so of memory away from BASIC (big YUK, since our BBS > program needs all the memory it can get and then some). I quote Steve Douglas, the author of the BusCard II firmware: "The BusCard was designed for *compatibility*, not *speed*". Geoff ( watmath!isishq!izot ) -- Geoffrey Welsh - via FidoNet node 1:221/162 UUCP: ...!watmath!isishq!171!izot Internet: izot@f171.n221.z1.FIDONET.ORG
brett.barabash@canremote.uucp (BRETT BARABASH) (04/02/89)
I was wondering about the program BBS64. I myself have never seen the program in action. It is freeware, I take it? I am currently using the prg. EBBS v3.4. It is quite easy to use. Compared to this, how does the BBS64 work? Better? Worse? G'day from the not-so Great White North! * QNet 1.03a2: Bert's Bulletin Board. Brandon, Man. --- MaS Relayer v1.00.00 Message gatewayed by MaS Network Software and Consulting/HST Internet: brett.barabash@canremote.uucp UUCP: ...!tmsoft!masnet!canremote!brett.barabash