Classic_-_Concepts@cup.portal.com (04/12/90)
Could someone please enlighten me on specific problems/solutions with using 19200 serial communications on the Amiga. I have no problems at 9600 but can't get the results I expect at 19200 (for null modem and printer communications). When I built the cable, I provided for both XON/XOFF and RTS/CTS communication and have tried both, with no luck. The cable's not the culprit. Also, are there optimum settings in the Preferences buffer for this type of data transfer? Any leads/help appreciated. LadyHawke (By the way, I used good quality shielded cable, good for distances over 50 feet; it runs about 40 feet.)
ckp@grebyn.com (Checkpoint Technologies) (04/14/90)
In article <28818@cup.portal.com> Classic_-_Concepts@cup.portal.com writes: > > Could someone please enlighten me on specific problems/solutions with >using 19200 serial communications on the Amiga. I have no problems at 9600 >but can't get the results I expect at 19200 (for null modem and printer >communications). When I built the cable, I provided for both XON/XOFF and >RTS/CTS communication and have tried both, with no luck. The cable's not >the culprit. Also, are there optimum settings in the Preferences buffer >for this type of data transfer? Any leads/help appreciated. LadyHawke >(By the way, I used good quality shielded cable, good for distances over >50 feet; it runs about 40 feet.) 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.
papa@pollux.usc.edu (Marco Papa) (04/14/90)
Both Checkpoint's Serial Solution and ASDG's Dual Serial Board should provide better error-free transmission than the one provided by the built-in Amiga serial support, mainly because they use an serial input buffer larger than one byte. We have experienced this ourselves when we tested ASDG's DSB. -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=