cshort@nmsu.edu (Spmg*d, Lord of Potted Meat Product) (02/05/91)
hi i've got my amiga 1000 at work wired (pins 2,3,7) to a sparc station. the setup works great at 9600 baud, but i would really like to run things at 19,200 (i'm greedy, eh). here's the problem: when i cat a large file i get overflow errors & when i try to d/u load i get bad CRC's. i'm using Atalk III and unix based send zmodem (sz 3.07) any suggestions. again this setup works fine at 9600 baud. thanks chris |----------------------|---------------------- | |the world is spam and | | | we are but the key | Spamg*d, lord of potted meat | |--------|-------------| cshort@nmsu.edu | | New Mexico State University | | Computing Research Labratory | | genebank, bionet, nethacker |-------------------| |Read the Avon paperback |SpamKey productions| | -------------------------|-------------------|
hwr@pilhuhn.ka.sub.org (Heiko W.Rupp) (02/06/91)
In article <CSHORT.91Feb4171549@aiaia.nmsu.edu>, Spmg*d, Lord of Potted Meat Product writes: >hi Hi > >i've got my amiga 1000 at work wired (pins 2,3,7) to a sparc station. >the setup works great at 9600 baud, but i would really like to run >things at 19,200 (i'm greedy, eh). here's the problem: >any suggestions. again this setup works fine at 9600 baud. I'm running the UUCico an my A1000 to my news-/mailfeed at 19200 using 7 pin nullmodem cable - perhaps that will help you. -Heiko -- Heiko W.Rupp, Gerwigstr.5, D-7500 Karlsruhe 1 | hwr@pilhuhn.ka.sub.org Tel: +49 7021 693642 (voice only) | uk85@dkauni2.bitnet Zwei Dinge sind unendlich - Das Universum und die menschliche Dummheit
jprad@faatcrl.UUCP (Jack Radigan) (02/12/91)
rick@tmiuv0.uucp writes: >The Amiga's serial hardware has problems at bauds greater than 9600, I >think. The 2000/2500's does. I believe the CBMSpeak on it is, "It is >not reliable." I have ASDG's DSB board in my A2500/30. It works fine >at 19,200. I've used it in my 3000, too, but I've not tried anything >faster than 9600 (betwixt Amoeba III <the 3000> and XyClone <a Unix box>). The official blurb in the RKM on serial I/O is that anything above 19.2kbps is "optimistic". In actuality, any Amiga can handle serial output. It's serial input that gets stickey depending on the confiuration of the system being used. What I've found is that a baseline 7MHz Amiga can easily do 19.2kbps serial I/O so long as a few things are taken into consideration. - Fast ram. If the system only has chip ram or $C00000 ram available, the cpu can't run full tilt and may not be able to honor serial input interrrupt quickly enough to prevent data overruns. Interestingly, the A1000 is less effected by this since it is running the system code in ram instead of the slower ROM of an A500 and A2000. I think it's about 9% faster, or so I remember someone else posting that figure. - 8 and 16 color screens shouldn't be used. The extra chip DMA that these require can lead to data loss as well. Flow control will help, but data can still be lost. If large amounts of text are going to be displayed, a 2 color screen is recommended. - More than 2 floppy drives combined with a couple of HD partitions can cause AmigaDOS to disable the system long enough to cause data loss. It's due to the once-a-second disk changed checking that is done. - Certain types of HD controller can also lead to data loss, those that are hogging the bus for DMA transfers or have device drivers that run at excessively high priorities are the worst offenders. - Having other tasks/processes running that hog the cpu also contribute to serial data loss. Although these are by no means the *only* situations that can effect serial I/O, they are the most common ones that I've found that can cause it. It usually takes a combination of a few items to really cripple the system at 19.2kbps. As for the A3000, I've been able to drive it at 38.4kbps without a burp. Of course, it's a 25MHz beast with 80ns scram, so that may not be the case with 16MHz flavors of the machine or without scram installed. I've been able to obtain close to 3550cps using ZMODEM via a direct connect from an A1000 to an A3000 at 38.4kbps (using JR-Comm of course). The reverse can't be checked since the A1000 totally dies at that rate. I was surprized that the A1000 could even handle the handshake at the start of the transfer, but it did. At 19.2kbps, the A1000 obtained 1910cps in both directions without data loss. All transfers were with text files, compressed files cause ZMODEM character escaping to occur which slows down the transfer accordingly. As you said, "your milage may very"... -jack-
sbeagle@kennels.actrix.gen.nz (Sleeping Beagle) (02/13/91)
rick@tmiuv0.uucp writes: > In article <CSHORT.91Feb4171549@aiaia.nmsu.edu>, cshort@nmsu.edu (Spmg*d, Lor > > i've got my amiga 1000 at work wired (pins 2,3,7) to a sparc station. > > the setup works great at 9600 baud, but i would really like to run > > things at 19,200 (i'm greedy, eh). here's the problem: > > > > when i cat a large file i get overflow errors & > > when i try to d/u load i get bad CRC's. i'm using Atalk III and > > unix based send zmodem (sz 3.07) I'm quite happily using 19200 bps between my AT and Amiga 500. The Amiga is running JR-Comm 0.94a... Transfer rates vary between 1700 cps and slightly over 1900 cps. This is with half duplex enabled (if that does anything in this mode!) and XON/XOFF handshaking enabled. -- ** Official Signature for Sleeping Beagle (aka Thomas Farmer)! ** sbeagle@kennels.actrix.gen.nz || Disclaimers are for sick societies ** Thomas.Farmer@bbs.actrix.gen.nz || with too many lawyers.
papa@pollux.usc.edu (Marco Papa) (02/13/91)
In article <gwBBX1w163w@kennels.actrix.gen.nz> sbeagle@kennels.actrix.gen.nz (Sleeping Beagle) writes: >rick@tmiuv0.uucp writes: >> In article <CSHORT.91Feb4171549@aiaia.nmsu.edu>, cshort@nmsu.edu (Spmg*d, Lor || | i've got my amiga 1000 at work wired (pins 2,3,7) to a sparc station. || | the setup works great at 9600 baud, but i would really like to run || | things at 19,200 (i'm greedy, eh). here's the problem: || | || | when i cat a large file i get overflow errors & || | when i try to d/u load i get bad CRC's. i'm using Atalk III and || | unix based send zmodem (sz 3.07) Make sure that you're using RTS/CTS handshake at those speeds (make sure that the sparc serial port is set up that way, too). |This is with half duplex enabled (if that does anything in this mode!) This doesn't doe ANYTHING at all. |and XON/XOFF handshaking enabled. This one also has no efect on Zmosdem since Zmodem throws away Xon/Xoffs. Zmodem is built to work best with RTS/CTS enabled. -- Marco -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
jprad@faatcrl.UUCP (Jack Radigan) (02/14/91)
sbeagle@kennels.actrix.gen.nz (Sleeping Beagle) writes: >rick@tmiuv0.uucp writes: >I'm quite happily using 19200 bps between my AT and Amiga 500. >The Amiga is running JR-Comm 0.94a... >Transfer rates vary between 1700 cps and slightly over 1900 cps. >This is with half duplex enabled (if that does anything in this mode!) and >XON/XOFF handshaking enabled. Turning off XON/XOFF handshake will boost that figure somewhat, but if you're sending data to a floppy you will have to leave it on. Also, the 1.0 series of JR-Comm incorporated extensive double-buffering both at the serial I/O level and with asynchronous file I/O. The speed increase is tremendous when compared with 0.94a. -jack-
jprad@faatcrl.UUCP (Jack Radigan) (02/14/91)
papa@pollux.usc.edu (Marco Papa) writes: >This one also has no efect on Zmosdem since Zmodem throws away Xon/Xoffs. >Zmodem is built to work best with RTS/CTS enabled. Well, not quite. ZMODEM directly responds to XON/XOFF characters and escapes them within binary files, so it does effect performance. Also, at the serial.device level, XON/XOFF enabled slows down the device some since it has to check for these characters. -jack-
papa@pollux.usc.edu (Marco Papa) (02/14/91)
In article <985@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: >papa@pollux.usc.edu (Marco Papa) writes: >>This one also has no efect on Zmosdem since Zmodem throws away Xon/Xoffs. >>Zmodem is built to work best with RTS/CTS enabled. > > Well, not quite. ZMODEM directly responds to XON/XOFF characters and >escapes them within binary files, so it does effect performance. Also, >at the serial.device level, XON/XOFF enabled slows down the device some >since it has to check for these characters. I stand corrected. Zmodem, by default, escapes Xon, Xoff, Dle, CR-@-CR and CTRL-X. For full streaming, Xon/Xoff is a loser. RTS/CTS handshaking is recommended. -- Marco -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
sbeagle@kennels.actrix.gen.nz (Sleeping Beagle) (02/14/91)
papa@pollux.usc.edu (Marco Papa) writes: > Make sure that you're using RTS/CTS handshake at those speeds (make sure that > the sparc serial port is set up that way, too). > > |This is with half duplex enabled (if that does anything in this mode!) > This doesn't doe ANYTHING at all. > |and XON/XOFF handshaking enabled. > This one also has no efect on Zmosdem since Zmodem throws away Xon/Xoffs. > Zmodem is built to work best with RTS/CTS enabled. I admit that I wasn't sure! ;-) However this doesn't mean that i wasn't getting 1800-1900 cps just with dsz (on the PC) speaking to an Amiga 500 running JRComm. And this was with only wires 2,3 and 7 connected. Things do get bad when you try and go faster though! -- ** Official Signature for Sleeping Beagle (aka Thomas Farmer)! ** sbeagle@kennels.actrix.gen.nz || Disclaimers are for sick societies ** Thomas.Farmer@bbs.actrix.gen.nz || with too many lawyers.
daveh@cbmvax.commodore.com (Dave Haynie) (02/20/91)
In article <978@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: >rick@tmiuv0.uucp writes: >>The Amiga's serial hardware has problems at bauds greater than 9600, I >>think. The 2000/2500's does. I believe the CBMSpeak on it is, "It is >>not reliable." I have ASDG's DSB board in my A2500/30. It works fine >>at 19,200. I've used it in my 3000, too, but I've not tried anything >>faster than 9600 (betwixt Amoeba III <the 3000> and XyClone <a Unix box>). > The official blurb in the RKM on serial I/O is that anything above >19.2kbps is "optimistic". In actuality, any Amiga can handle serial >output. It's serial input that gets stickey depending on the confiuration >of the system being used. The real problem with high speed serial input is buffering. For every character that comes in, you need to interrupt the CPU and have it stuff that character somewhere. 68030 machines work faster than 68000 machines in all things, interrupts included, so they tend to deal nicely with high speed transfers. The terminal program you're using will also have an effect on your maximum practical speed; it needs to know the right way to talk to serial.device, especially keeping in mind that more than one character may be available on every I/O request. And the Amiga is hardly the only one with the problem -- I used to use our VAX system here at 19,200 baud from the A2500 in my office, but dropped down to 9600 as IT kept losing stuff. The Amiga was not the problem; with the A2232 card in the system, I've had two 19,200 baud channels and one 1200 baud channel running at the same time (using ATalk-III, two direct lines, and one modem). The A2232 does make life easier, since it does its own buffering, but it can't go beyond 19,200 baud. On the other end of things, if you're running a packet oriented protocol, rather than single characters, you can get a reliable Amiga-Amiga connection going in the 150KB-200KB range. > - Certain types of HD controller can also lead to data loss, those that > are hogging the bus for DMA transfers or have device drivers that run > at excessively high priorities are the worst offenders. In general, the DMA devices won't be a problem. Even on the A2000/A2091, a typical SCSI device is going to run at about 1/2 the speed of the bus, so DMA transfes wind up in rather small packets. You may find the DMA device gets on the bus for 20-40 cycles, but probably not much longer at one shot. Any DMA device that takes the bus too long can cause problems, since when the DMA device has the bus, the CPU doesn't. Though it would be rather unnatural for a DMA device to take over the bus for long periods of time, unless for some reason it's doing large block buffering. All C= hard disk controllers use FIFOs, which buffer up maybe 16 or 32 bytes at a time. The programmed I/O controller I call "parasitic" controllers, which read or write a SCSI chip as if it were slow memory (therefore running cycles with considerable wait states, thus the term parasitic), are very deadly in combination with hard disk performance. In general, any time one of these is talking to the disk, all CPU time is eaten up. > As for the A3000, I've been able to drive it at 38.4kbps without a burp. You get a big pile of advantages in the A3000 -- faster CPU, faster memory, and especially the hard disk, which typically takes 4%-8% of your CPU time for transfers, rather than as much as 50% on A2000 based DMA devices. > -jack- -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "What works for me might work for you" -Jimmy Buffett
jprad@faatcrl.UUCP (Jack Radigan) (02/23/91)
daveh@cbmvax.commodore.com (Dave Haynie) writes: >In article <978@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: >>rick@tmiuv0.uucp writes: >The real problem with high speed serial input is buffering. For every >character that comes in, you need to interrupt the CPU and have it stuff >that character somewhere. True. Is there any consideration of a FIDO, or at least one additional byte of bufering being considered for a future PAULA? From the tests I've done, that would just about do it for baseline Amigas to not have data loss problems. >On the other end of things, if you're running a packet oriented protocol, >rather than single characters, you can get a reliable Amiga-Amiga connection >going in the 150KB-200KB range. But this would mean bypassing the serial.device and going straight to the serial.resource, right? What impact does this have on the rest of the system? >> - Certain types of HD controller can also lead to data loss, those that >> are hogging the bus for DMA transfers or have device drivers that run >> at excessively high priorities are the worst offenders. >In general, the DMA devices won't be a problem. Even on the A2000/A2091, a >typical SCSI device is going to run at about 1/2 the speed of the bus, so >DMA transfes wind up in rather small packets. Nope, check that. Certain Supra DMA controllers completely stomp all over ZMODEM downloads @ 19.2kbps if the transfer is done to disk. Little to no effect for transfers to ram: though. While I may have been mistaken as to the cause of the problem, there *is* a definate interference with certain controllers and serial input. Of course, 3/4 bitplanes and/or the lack of real fast ram can also aggrevate this condition too. >> As for the A3000, I've been able to drive it at 38.4kbps without a burp. >You get a big pile of advantages in the A3000 -- faster CPU, faster memory, >and especially the hard disk, which typically takes 4%-8% of your CPU time >for transfers, rather than as much as 50% on A2000 based DMA devices. No lie! ;-) -jack-
lron@easy.hiam.com (Dwight Hubbard) (02/23/91)
In article <1022@faatcrl.UUCP>, Jack Radigan writes: > daveh@cbmvax.commodore.com (Dave Haynie) writes: > > >In article <978@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: > >>rick@tmiuv0.uucp writes: > > >The real problem with high speed serial input is buffering. For every > >character that comes in, you need to interrupt the CPU and have it stuff > >that character somewhere. > > True. Is there any consideration of a FIDO, or at least one additional > byte of bufering being considered for a future PAULA? From the tests I've > done, that would just about do it for baseline Amigas to not have data loss > problems. Don't you mean FIFO (First In First Out) not FIDO (Dog chow with meat and and gravy or somesuch). I would like to see something like this as well, since we can't throw in an 16650 UART into our Amiga's like PC user's do when they get a fast modem. > > >On the other end of things, if you're running a packet oriented protocol, > >rather than single characters, you can get a reliable Amiga-Amiga connection > >going in the 150KB-200KB range. > > But this would mean bypassing the serial.device and going straight to the > serial.resource, right? What impact does this have on the rest of the > system? I was thinking the same thing, but you should be able to get better speed since you won't have to put up with the serial.device overhead but then at least according to an Ariticle in Transactor about this subject (before it went under) you can get about 56.5Kbps going strait to the hardware and using interupt driven I/O, it did mention above 56.5kbps that you would have to do polled I/O as interupt overhead becomes a problem. > >> - Certain types of HD controller can also lead to data loss, those that > >> are hogging the bus for DMA transfers or have device drivers that run > >> at excessively high priorities are the worst offenders. > > >In general, the DMA devices won't be a problem. Even on the A2000/A2091, a > >typical SCSI device is going to run at about 1/2 the speed of the bus, so > >DMA transfes wind up in rather small packets. > > Nope, check that. Certain Supra DMA controllers completely stomp all over > ZMODEM downloads @ 19.2kbps if the transfer is done to disk. Little to no > effect for transfers to ram: though. From what I've seen the Non-DMA controllers have this problem more than the DMA driven ones. I suspect the real problem is the driver software and not the controller per se. I know my older CLTD drive controller would have real problems at 2400bps because the driver disabled interupts for excessive periods of time, the Mast Fireball controller I'm currently using doesn't have problems with Zmodem transfers using an HST 14.4 with the serial port at 19.2Kbps and it's a DMA controller. The problem seems to be different for each brand of controller, which would lead me to belive that the problem is with the driver. As for the Supra controller if the driver is anything like the one for the 2400zi internal modem then I really doubt the hardware's the problem. -Dwight Hubbard USENET : uunet!easy!lron -Kaneohe, Hawaii CFR : 31:910/101 (Dwight Hubbard)
daveh@cbmvax.commodore.com (Dave Haynie) (02/26/91)
In article <1022@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: >daveh@cbmvax.commodore.com (Dave Haynie) writes: >>The real problem with high speed serial input is buffering. > True. Is there any consideration of a FIDO, or at least one additional >byte of bufering being considered for a future PAULA? Certainly a FIFO would be a good idea; they worked fine in the system level chips like the DMAC. Either a decent FIFO or a dedicated DMA channel like the floppy gets would solve the problem. >>On the other end of things, if you're running a packet oriented protocol, >>rather than single characters, you can get a reliable Amiga-Amiga connection >>going in the 150KB-200KB range. > But this would mean bypassing the serial.device and going straight to the >serial.resource, right? What impact does this have on the rest of the >system? It slows the system down when you're running a transfer, same way any other polled-I/O transfer slows the system down. >>In general, the DMA devices won't be a problem. > Nope, check that. Certain Supra DMA controllers completely stomp all over >ZMODEM downloads @ 19.2kbps if the transfer is done to disk. You sure that's one of the old Supra DMA controllers, or is it their new one, the non-DMA "WordSync". If their DMA controller is causing problems, they're doing something evil. No DMA device should tie up the bus unless it has data to transfer immediately, and no single hard disk can keep a DMA device device's FIFO/buffer full for long. Polled I/O devices, on the other hand, are something you would expect to see problems with. > While I may have been mistaken as to the cause of the problem, there *is* >a definate interference with certain controllers and serial input. You can _always_ make a piece of hardware that causes a problem. We spend lots of time working out ways to not cause problems with the built-in stuff, at least. I wish they had considered this problem with the original Paula, but I guess no one's perfect. They got the rest of it right... > -jack- -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "What works for me might work for you" -Jimmy Buffett
jprad@faatcrl.UUCP (Jack Radigan) (02/27/91)
daveh@cbmvax.commodore.com (Dave Haynie) writes: >Certainly a FIFO would be a good idea; they worked fine in the system level >chips like the DMAC. Either a decent FIFO or a dedicated DMA channel like >the floppy gets would solve the problem. Hope so, an A1000 can send at 38.4kbps very nicely, faster than my 12MHz 286 PeeCee, in fact. But, it can't receive at that rate. Hope you can squeeze a 4 byte FIFO in there, sure would be nice. >You sure that's one of the old Supra DMA controllers, or is it their new one, >the non-DMA "WordSync". If their DMA controller is causing problems, they're >doing something evil. No DMA device should tie up the bus unless it has >data to transfer immediately, and no single hard disk can keep a DMA device >device's FIFO/buffer full for long. Polled I/O devices, on the other hand, >are something you would expect to see problems with. Not sure which one it was, this was reported to me by a few users, all were losing data with HST modems and Supra HD controllers. I didn't know the "WordSync" was non-DMA, this may account for one who told me that the device driver for the controller was running at a priority of something like 50... -jack-
lron@easy.hiam.com (Dwight Hubbard) (02/27/91)
In article <1032@faatcrl.UUCP>, Jack Radigan writes: > daveh@cbmvax.commodore.com (Dave Haynie) writes: > > >Certainly a FIFO would be a good idea; they worked fine in the system level > >chips like the DMAC. Either a decent FIFO or a dedicated DMA channel like > >the floppy gets would solve the problem. > > Hope so, an A1000 can send at 38.4kbps very nicely, faster than my 12MHz > 286 PeeCee, in fact. But, it can't receive at that rate. Hope you can > squeeze a 4 byte FIFO in there, sure would be nice. I think a 4 byte FIFO would be insufficent, some of the Non-DMA drive controllers I've seen keep interupts disabled for up to a half a second and in that time period an HST can send 800+ bytes of data. A 4 byte FIFO isn't going to solve this problem. A dedicated DMA channel sounds like a more viable solution to this kind of problem. If a FIFO were used I would like to see at least a 16 byte one like the 16550 UARTS that PC owners have, although even a four byte FIFO would be better than what we have now. *----------------*--------------------------------* | Dwight Hubbard | UseNet: easy!lron@uunet.uu.net | | Kaneohe, HI | Genie: D.Hubbard1 | *----------------*--------------------------------*
jesup@cbmvax.commodore.com (Randell Jesup) (03/02/91)
In article <18bf2954.ARN0e27@easy.hiam.com> lron@easy.hiam.com writes: >I think a 4 byte FIFO would be insufficent, some of the Non-DMA drive >controllers I've seen keep interupts disabled for up to a half a second and >in that time period an HST can send 800+ bytes of data. A 4 byte FIFO isn't The RKM's have always said that Disable should never be held for more than 250 microseconds. 500 milliseconds is 2000 times that. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
lron@uunet.uu.net (Dwight Hubbard) (03/03/91)
In article <19397@cbmvax.commodore.com>, Randell Jesup writes: > In article <18bf2954.ARN0e27@easy.hiam.com> easy!lron@uunet.uu.net writes: > >I think a 4 byte FIFO would be insufficent, some of the Non-DMA drive > >controllers I've seen keep interupts disabled for up to a half a second and > >in that time period an HST can send 800+ bytes of data. A 4 byte FIFO isn't > > The RKM's have always said that Disable should never be held for > more than 250 microseconds. 500 milliseconds is 2000 times that. > Yep, they sure do. To bad some hard drive drivers don't seem to do so :-( BTW, I would like to add that if buffers are added I would like to see support for CTS/RTS flow control in hardware as well. All the buffers in the world aren't going to be any good unless you can keep them from overflowing and the current software based CTS/RTS flow control doesn't seem to drop RTS soon enough to stop the buffers from overflowing at 19.2K, a heavily loaded system makes the problem painfully evident. ---------------------------------------------------------------------- -Dwight Hubbard USENET : easy!lron@uunet.uu.net - -Kaneohe, Hawaii CFR : 31:910/101 (Dwight Hubbard) - ----------------------------------------------------------------------
jprad@faatcrl.UUCP (Jack Radigan) (03/04/91)
easy!lron@uunet.uu.net (Dwight Hubbard) writes: >BTW, I would like to add that if buffers are added I would like to see >support for CTS/RTS flow control in hardware as well. All the buffers >in the world aren't going to be any good unless you can keep them from >overflowing and the current software based CTS/RTS flow control doesn't >seem to drop RTS soon enough to stop the buffers from overflowing at >19.2K, a heavily loaded system makes the problem painfully evident. Check you system or get the 1.3.2 serial.device. An A500 without any true fast ram can do CTS/RTS @ 19.2kbps without data loss. Your milage may vary depending on what other things you run and have attached to it though. XON/XOFF handshake is a different matter at high rates though, it always drops a few characters. -jack-
lron@uunet.uu.net (Dwight Hubbard) (03/04/91)
In article <1047@faatcrl.UUCP>, Jack Radigan writes: > Check you system or get the 1.3.2 serial.device. An A500 without any true > fast ram can do CTS/RTS @ 19.2kbps without data loss. Your milage may vary > depending on what other things you run and have attached to it though. Then why doesn't it work under the 2.0 serial device?? ---------------------------------------------------------------------- -Dwight Hubbard USENET : easy!lron@uunet.uu.net - -Kaneohe, Hawaii CFR : 31:910/101 (Dwight Hubbard) - ----------------------------------------------------------------------
jprad@faatcrl.UUCP (Jack Radigan) (03/08/91)
easy!lron@uunet.uu.net (Dwight Hubbard) writes: >In article <1047@faatcrl.UUCP>, Jack Radigan writes: >> Check you system or get the 1.3.2 serial.device. An A500 without any true >> fast ram can do CTS/RTS @ 19.2kbps without data loss. Your milage may vary >> depending on what other things you run and have attached to it though. >Then why doesn't it work under the 2.0 serial device?? They're the same device. I've got an A3000 here and it's working fine. Are you certain it's the software and not a bum CIA chip? -jack-
lron@uunet.uu.net (Dwight Hubbard) (03/08/91)
In article <1064@faatcrl.UUCP>, Jack Radigan writes: > >In article <1047@faatcrl.UUCP>, Jack Radigan writes: > > >> Check you system or get the 1.3.2 serial.device. An A500 without any true > >> fast ram can do CTS/RTS @ 19.2kbps without data loss. Your milage may vary > >> depending on what other things you run and have attached to it though. > > >Then why doesn't it work under the 2.0 serial device?? > > They're the same device. I've got an A3000 here and it's working fine. > Are you certain it's the software and not a bum CIA chip? I checked and you're right the serial.device with 2.0 is the 1.3.2 serial device. I have 2 68000 Amiga's here and both have the same problem also several other 68000 Amiga owner's have complained about loosing data when using a HST or V.32 modem and CTS/RTS handshaking machines with 68020's and 68030's do not display this problem, but they very likely are processing the data fast enough that there is no need to drop RTS to the modem at any time. I've heard about this problem occuring with JRComm, Baud Bandit, AZComm and ATalk so I don't think it's likely that it's just my hardware or a particular piece of software. I initially thought the problem was something external to the Amiga such as serial cables without the CTS/RTS pins connected, modems with hardware handshaking disabled (&H1 &R2 on the HST) or something of that nature. Normally the problem only becomes noticable during streaming protocol transfers like Zmodem transfers were the other modem is sending a solid stream of data at maximum speed, however I have noticed that if I run a CPU bound task with a higher priority than the term program (starving the term program) when the term program get's started again there is a burst of the data that was coming across followed by blocks of data that had already been received. If I get the time I'm going to try and track down this problem unfortunetly I handle telecomunications for the Marines and with all the units coming back I'm going to be to busy installing equipment and such to do much for a few weeks. I should also add that downloads to a hard drive or floppy show this problem much worse than to the ram disk. ---------------------------------------------------------------------- -Dwight Hubbard USENET : easy!lron@uunet.uu.net - -Kaneohe, Hawaii CFR : 31:910/101 (Dwight Hubbard) - ----------------------------------------------------------------------