Path: utzoo!mnetor!tmsoft!torsqnt!hybrid!scifi!bywater!uunet!easy!lron From: lron@easy.hiam.com (Dwight Hubbard) Newsgroups: comp.sys.amiga.datacomm Subject: Re: 19200 baud amiga Message-ID: <18b9b671.ARN0df8@easy.hiam.com> Date: 23 Feb 91 03:54:09 GMT References: <2587@tmiuv0.uucp> <978@faatcrl.UUCP> <19116@cbmvax.commodore.com> <1022@faatcrl.UUCP> Reply-To: lron@easy.hiam.com Followup-To: comp.sys.amiga.datacomm Distribution: comp Organization: You must be talking about someone else. Lines: 63 Expires: Keywords: 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)