🚀 go-pugleaf

In article <02373.AA02373@spirit.kref.sub.org> rob%spirit@impch.imp.com writes:
>Hi!
>
>A friend of mine has recently bought a COURIER HST 14.4.
>Now he has trouble with his AMIGA-1000 and the HST at speeds higher than
>9.600 baud! The Amiga just looses some bytes when receiving data with high
>speeds (>9600Bit/s) (it also mixes/doubles data or spits them out too late).
>
>OUR CONCLUSIONS/QUESTIONS:
>
>-- the AMIGA is too slow for such high speeds. :-((( ?!
>   (We can't really believe it! EMIT handles rates upto 280000Bit/s(?))
Not true.  I'll explain.

>
>-- is it a SOFTWARE-bug in the serial.device or any other system part. ?
Partly this.

>
>-- is it a HARDWARE-bug ?
Also, partly this.

>Any suggestions (Commodore crew)?
>
>We're wondering why telecommunication-programs have got gadgets for speeds
>upto 57.6kBit/s, when the AMIGA normally can't handle more than 9600?
>Naturally, all settings were right, CTS/RTS enabled and so on...
>We tested it with JRCOMM V0.94,V0.99j and Platinum Online. It was always
>the same. Is there anybody driving his/her AMIGA with more than 9600 Baud?
>My friend is so disappointed about the AMIGA that he's going to buy a 386
>PC-Clone (no, that's no joke!). I'm shocked, too (I wanted to stick to the
>AMIGA, later driving UNIX)! Please help us!

Well, I just left a message here about it.  I'll just quote it again...

** Begin quote **

The problems stem from a combination of hardware and software.  The
hardware problem is the Paula chip, which implements the serial
interface.  It is slightly dumb; software must calculate parity and
provide the start and stop bits, because Paula provides little more
than a shift register.  The software must also provide the handshaking,
whether XON/XOFF or RTS/CTS (7-wire).

The software problem is from the fact that there are a lot of interrupt
sources in the Amiga, and plenty of requirements for synchronization in
a multi-tasking system.  A typical method of ensuring synchronization,
and I must say it's suitable in most cases, is to disable interrupts so
that a critical process can complete without error.  This can cause
incoming serial characters to be lost when they're coming quickly,
because the serial interrupt was delayed so long that a second character
arrived.

Increasing the size of the serial input buffer will help if your
problems arise because your terminal program task isn't operating
quickly enough to read those characters before the buffer overflows.
This should only happen if you're not using any kind of handshaking,
which is usually the case for binary file transfers.

And, of course (here comes the plug), you can solve your problems by
purchasing an add-on serial card like the one we sell.  We have smarter
hardware.  The serial chip can receive up to 4 characters without being
serviced by the CPU, without losing any data.  The serial chip also
controls the RTS/CTS hardware handshaking itself (XON/XOFF must still be
done in software).  The serial chip calculates parity, start, and stop
bits, it automatically detects break (seldom an issue).  We have run it
as fast as 250,000 baud with hardware handshaking with no data loss.

So give us a call at (703) 330-5353 and we'll set you up with a good
reliable serial board.  We're Checkpoint Technologies, and the board
is the Serial Solution.  

** end of quote **

Now this may not your actual problem.  Choosing a faster terminal
program could be all you need.
-- 
First comes the logo: C H E C K P O I N T  T E C H N O L O G I E S      / /  
                                                                    \\ / /    
Then, the disclaimer:  All expressed opinions are, indeed, opinions. \  / o
Now for the witty part:    I'm pink, therefore, I'm spam!             \/