rob@spirit.kref.sub.org (Roland Bless) (04/11/90)
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). He tested it with different Kickstarts, Workbenchs, serial-devices and port-handlers. He thought that it is maybe his A-1000, so we tested it with my AMIGA-2000 (A-2000B Rev4.3, European/PAL-Model, A2058, A2090-ST1096N). The effects are the same! You can simply test it with a telecommunications- program and the HST typing "ati4", "ati6" or "ati7" at speeds higher 9.600 Baud (we tested it at 38.400 and 14.400). The results are shown below at the end of this (long [sorry!]) posting. We both have WB V34.28 and ARP V39.1. The serial.device is V 34.12, although it doesn't seem too make any differences. The effect was recognized for the first time, when he downloaded data with 14.400 Bit/s. Downloading with 9.600 Baud seems to be error-free, but then the AMIGA is no longer multitasking, because the system is so enormously slowed down. The HST-modem was tested with a PC-Clone 386SX and worked without any error, so the modem is not the bug. The problem is the connection between modem <-> computer. OUR CONCLUSIONS/QUESTIONS: -- the AMIGA is too slow for such high speeds. :-((( ?! (We can't really believe it! EMIT handles rates upto 280000Bit/s(?)) -- is it a SOFTWARE-bug in the serial.device or any other system part. ? -- is it a HARDWARE-bug ? -- did we made a simple/dull fault ? 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! Here the typical test results (they are not normal HST responses..): | ati4 | USRobotics Courier 14400 HST Settings... | | B0 C1 E1 F1 M3 Q0 V1 X4 | BAUD=38400 PARITY=N WORDLEN=8 | DIAL=PULSE ON HOOK TIMER | | &A0 &B1 &C1 &D2 &G | S08=002 S09=006 S10=020 S11=070 &H1 &I0 &J0 &K1 | &L0 &M4 &N0 &P0 &R1 &S0 &X0 &Y1 | | S00=000 S01=000 S02=043 S03=013EN=8 | DIAL=PULSE ON HOOK TIMER | | &A0 &B1 &C1 &D2 &G | S08=002 S09=006 S10=020 S11=070 | S12=050 S13=000 S14=000 S15=000 | S16=000 S17=000 S18=000 S19=000 | S20=000 S21=010 S22=017 S23=019 | S24=000 S25=000 S26=010 S27=000 | S28=000 S38=000 | | L S04=010 S05=008 S06=002 S07=120 | S08=002 S09=006 S10=020 S11=070 | S12=0 S13=000 S14=000 S15=000 | S16=000 S17=000 S18=000 S19=000 | S20=000 S21=010 S22=017 S23=019 | S24=000 S25=000 S26=010 S27=000 | S28=000 S38=000 | | LAST DIALED #: | | OK | ati6 | USRobotics Courier 14400 HST Link Diagnostics... | | Chars sent 06 S10=020 S11=070 | S12=0 S13=000 S14=000 S15=000 | S16=000 S17=000 S18 0 Chars Received 0 | Chars lost 0 | Octets sent 0 Octets Received 0 | Blocks sent 0 Blocks Received 0 | Blocks resent 0 | | Ret27=000 | S28=000 S38=000 | | LAST DIALED #: | | OK | S21=010 S22=017 S23=019 | S24=000 S25=000 S26=010 S27=000 | S28=000 S38=000 | | LAST DIALED #: | | OK | 6=010 S27=000 | S28=000 S38=000 | | LAST DIALED #: | | OK | nsequested 0 Retrains Granted 0 | Line Reversals 0 Blers 0 | Link Timeouts 0 Link Naks 0 | | Data Compression Off | Equalization Long | Fallback Disabled | | No Connection | | OK | ati7 | Configuration Profile... | | Product type External | Options H 0 Blers 0 | Link Timeouts 0 | Epr 64k | Ram 8k | | Supervisor date 09/29/89 | IOP date 05/17/89 | DSP date 09/18/89 | | Supervisor rev 1.2 | IOP rev 1.0 | DSP rev 2 | | OK Bye, Roland -- R o l a n d B l e s s | UUCP: rob@spirit.kref.sub.org | Duesseldorf - FRG | or rob%spirit@impch.imp.com (on failure) | voice +49 211 623817 | FAX: +49211623818 BTX:0211623818-0001 | private UUCP-site | "They built machines that they can't control" STING | -----------s-p-i-r-i-t-s---i-n---t-h-e---m-a-t-e-r-i-a-l---w-o-r-l-d----------+
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (04/12/90)
>In <Apr.12.13.47.28.1990.7927@pilot.njin.net>, limonce@pilot.njin.net (Tom Limoncelli) writes: >You asked "why do term program permit high baud-rates when they can't >handle them?" Well, it's because most aren't tested at high baud >rates. Commercial software does get good testing and you'll only see >the baud rates listed that they can actually do. (Oops, I should say >"*good* commercial software gets good testing). If you notice, >VT100 2.9A only lists the tested baud rates. The next version will >include 19.2Kbps because I've tested it at that rate. Well, there's testing and then there's testing, and there's different conditions... One reason Aterm 7.3.1 has 19,200 and MIDI is because it works at those speeds, reliably. Of course I would throw in a caveat or two, saying that it will not handle those rates while printing to screen and having a sustained data stream arriving. I would aslo recommend that the serial buffer as set in preferences be at the highest setting available (currently 16K). I might also have a 'mileage may vary' disclaimer stating that these rates are attainable on my system, with particular hardware attached (disk controllers, etc.), and under the conditions I usually run (other tasks, other IO, etc.). So, not all terminal programs have those rates on the menu just for show or just because they haven't been tested. >[comments about ASDG's serial board.. deleted] I agree. ASDG puts out nice stuff. -larry -- Entomology bugs me. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
lofaso@titan.tsd.arlut.utexas.edu (Bernie Lofaso) (04/12/90)
In article <02373.AA02373@spirit.kref.sub.org>, rob@spirit.kref.sub.org (Roland Bless) writes: > -- the AMIGA is too slow for such high speeds. :-((( ?! > (We can't really believe it! EMIT handles rates upto 280000Bit/s(?)) > > -- is it a SOFTWARE-bug in the serial.device or any other system part. ? > > We tested it with JRCOMM V0.94,V0.99j and Platinum Online. It was always I strongly suspect that it is the terminal programs that you are using that cannot keep up with the hardware. Many years ago I used an A1000 as a dumb terminal and operated it at 19,200 baud. I tried several terminal programs before I found one that would operate at that speed, but had no problems afterward. Unfortunately, that was about 4 years ago and I don't remember what I used. Since I was working for an Amiga retailer part-time back then it could have been a commercial product or maybe PD. Bernie Lofaso
smaug@eng.umd.edu (Kurt Lidl) (04/12/90)
In article <02373.AA02373@spirit.kref.sub.org> rob%spirit@impch.imp.com writes: >Now he has trouble with his AMIGA-1000 and the HST at speeds higher than >9.600 baud! The Amiga just loses some bytes when receiving data with high >speeds (>9600Bit/s) (it also mixes/doubles data or spits them out too late). > >[much about switching the low-level system drivers, kickstarts, et al] > >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? It can handle speeds up to 19.2 kbps quite OK. >We tested it with JRCOMM V0.94,V0.99j and Platinum Online. Try VT100 v2.9A and see it EVER drops a character. Try Dnet at 19.2 Kbps and see if it ever fails. I have used both of these packages at the above speeds and never had a problem. I did notice that the Dnet throughput was lower at 38.4 Kbps than at 19.2kps, so there appears to be some sort of interaction at *that* speed, but nothing lower than that... Matt didn't have much to say about the slower rates at 38.4, so I guess he never got around to fully tuning the software/isolating the bottleneck in the Dnet code at that speed. Dnet was under AmigaDOS 1.2 on a B2000, with a 68010. VT100 under AmigaDOS 1.2 and 1.3, same machine as above. I seem to remember hearing the Bryce was giving the serial drivers a work-over for 1.4, or maybe a few too many of my neurons mis-fired at the wrong time. Maybe some of the folks at Commodore could hint if 1.4 will have improved serial driver support... >R o l a n d B l e s s | UUCP: rob@spirit.kref.sub.org | -- /* Kurt J. Lidl (smaug@eng.umd.edu) | Unix is the answer, but only if you */ /* UUCP: uunet!eng.umd.edu!smaug | phrase the question very carefully. */
limonce@pilot.njin.net (Tom Limoncelli) (04/13/90)
In article <02373.AA02373@spirit.kref.sub.org> rob@spirit.kref.sub.org (Roland Bless) writes: [ The Amiga can't handle high baud rates.] > He tested it with different Kickstarts, Workbenchs, serial-devices and > port-handlers. He thought that it is maybe his A-1000, so we tested it with > my AMIGA-2000 (A-2000B Rev4.3, European/PAL-Model, A2058, A2090-ST1096N). First of all, use AmigaDOS 1.3. There were improvements to the serial.device. Also, just for completeness, you might want to use AmigaDOS 1.3.2 since it's always nice to be running with the latest bug-fixes. You did a pretty good analysis, but you had one big flaw: You used 2 slow terminal programs. JRcomm is good, but not at high speeds. Platinum Online is a silly little program that is not well respected. Try VT100 2.9A (free) or ATalk-III+ (commercial). You asked "why do term program permit high baud-rates when they can't handle them?" Well, it's because most aren't tested at high baud rates. Commercial software does get good testing and you'll only see the baud rates listed that they can actually do. (Oops, I should say "*good* commercial software gets good testing). If you notice, VT100 2.9A only lists the tested baud rates. The next version will include 19.2Kbps because I've tested it at that rate. So, obviously the question is, "where is the problem?". Well, basically the serial.device in pre-1.3 AmigaDOS wasn't so hot, and 1.3 only has a couple improvements. Commodore has stated that there will be a new serial.device someday (presumably in 1.4) that will have been re-written from scratch and will be quite fast. Obviously the Amiga can handle it. It just takes good software. (I say that because the ASDG serial board doesn't have its own CPU and they get great results. Results so good that ASDG posted that it seems futile to produce a board with a CPU now that they've seen what a well-matched hardware/software design can do on the Amiga). [I'm not speaking for ASDG, I'm just a happy customer.] So, basically the solution is to get better software: (1) get a new application and (2) get 1.4. Sadly, you can only do #1 right now. -- tlimonce@drew.edu Tom Limoncelli As seen in USA Today & tlimonce@drew.uucp +1 201 408 5389 Rec.Humor.Funny! tlimonce@drew.Bitnet Stock quote: Commodore stock closed limonce@pilot.njin.net at $7.25 (-.25) on 4-11-1990.
root@sbcs.sunysb.edu (Systems Staff) (04/13/90)
In article <1990Apr12.133830.17051@eng.umd.edu> smaug@eng.umd.edu (Kurt Lidl) writes: >In article <02373.AA02373@spirit.kref.sub.org> rob%spirit@impch.imp.com writes: >>Now he has trouble with his AMIGA-1000 and the HST at speeds higher than >>9.600 baud! The Amiga just loses some bytes when receiving data with high >>speeds (>9600Bit/s) (it also mixes/doubles data or spits them out too late). >> >>[much about switching the low-level system drivers, kickstarts, et al] >> >>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? This is an entirely empirical statement, but I am able to run SLIP at 38.4K baud and still compile, etc at the same time. I would say that the max speed you can run the port at depends a lot on the Disable()/Enable() (and perhaps Forbid()/Permit()) behaviour of other applications you have running on the system. The funny thing in all of this is that my 2630 equipped system can run right along merrily talking SLIP @ 38.4K to a Sparcstation that dogs badly under the serial load. Before you jump to conclusions about Sparc vs 68030 or SunOS vs AmigaDOS, the problem is apparently the bad SysV serial software Sun uses for tty streams modules (at least according to the author of the sparc SLIP code). Well, it is nice to say we really can do some things "better" on the Amiga, anways ;-) Device drivers seems to be one of those things AmigaDOS does very well compared to other OS'. >>R o l a n d B l e s s | UUCP: rob@spirit.kref.sub.org | >/* Kurt J. Lidl (smaug@eng.umd.edu) | Unix is the answer, but only if you */ Rick Spanbauer State U of NY/Stony Brook
papa@pollux.usc.edu (Marco Papa) (04/13/90)
In article <Apr.12.13.47.28.1990.7927@pilot.njin.net> limonce@pilot.njin.net (Tom Limoncelli) writes: >In article <02373.AA02373@spirit.kref.sub.org> rob@spirit.kref.sub.org (Roland Bless) writes: |[ The Amiga can't handle high baud rates.] | || He tested it with different Kickstarts, Workbenchs, serial-devices and || port-handlers. He thought that it is maybe his A-1000, so we tested it with || my AMIGA-2000 (A-2000B Rev4.3, European/PAL-Model, A2058, A2090-ST1096N). | |First of all, use AmigaDOS 1.3. There were improvements to the |serial.device. Also, just for completeness, you might want to use |AmigaDOS 1.3.2 since it's always nice to be running with the latest |bug-fixes. Even better: you *SHOULD* run 1.3.2, because that release came with a new serial device that fixes a few bugs (that used to crash the Amiga) and improves performance somewhat. |You did a pretty good analysis, but you had one big flaw: |You used 2 slow terminal programs. JRcomm is good, but not at high |speeds. Platinum Online is a silly little program that is not well |respected. Try VT100 2.9A (free) or ATalk-III+ (commercial). Thanks for the recommendation. In fact, we had both Courier HSTs and Trailblazers in early 1989, when we added support for such modems. With the Courier HST it is imperative to use RTS/CTS handshake (no X-on/X-off). Make sure that the cable uses the RTS and CTS lines correctly, and you also might want to play with the input buffer size (A-Talk III accepts your Serial Device Preferences). There are two types of problems to consider: terminal emulations and file transfers. 1. Terminal Emulations A Good terminal emulator should be able to keep up with 9600, *WHEN NOT SCROLLING*. If it can't keep up with it, then you bought a lemon :-) SCROLLING at high speeds is not feasable, unless the emulator bypasses a lot of software (i.e. it handles only 1 fixed font, for example). 2. File Transfers There should never be any problem with "half-duplex" transfers like XMODEM or KERMIT at speeds up to 19,200, since the packets are small and there is a large turnaround time (due to the acknowledgement). When using "streaming" mode protocols, such as ZMODEM or YMODEM-g, you MUST use hardware handshaking, "optimize" the input buffer size and such things. We were able to use 19.2K or 38.4K Amiga<->Modem speeds, though at 38.4K we did get some CRC errors, which are the result of "overrruns" on the serial port. Note that when I say "you must use RTS/CTS", I mean that your host also has to be set up to support it, otherwise you'll still get overruns. |You asked "why do term program permit high baud-rates when they can't |handle them?" Well, it's because most aren't tested at high baud |rates. Commercial software does get good testing and you'll only see |the baud rates listed that they can actually do. (Oops, I should say |"*good* commercial software gets good testing). If you notice, |VT100 2.9A only lists the tested baud rates. The next version will |include 19.2Kbps because I've tested it at that rate. Agreed. VT100 2.9A does indeed work with at speeds. A-Talk III also includes support for 57.6K, since the serial port works just fine "SENDING" at those speeds (and higher). We use it to send files to 80x86 systems, that can keep up at those speeds on input, since they do not multitask. One thing that you might notice on the Amiga at high speeds, is the fact that the mouse will not move or will jerk when moved. There are just not enough cycles available on a stock 68000 Amiga. The situation is much better with a 68020 or 68030-based Amiga. |So, basically the solution is to get better software: (1) get a new |application and (2) get 1.4. Sadly, you can only do #1 right now. Nah. I can do #2, too :-) -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
ckp@grebyn.com (Checkpoint Technologies) (04/14/90)
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! \/
davidm@uunet.UU.NET (David S. Masterson) (04/14/90)
In article <1990Apr12.133830.17051@eng.umd.edu> smaug@eng.umd.edu (Kurt Lidl) writes: Dnet was under AmigaDOS 1.2 on a B2000, with a 68010. VT100 under AmigaDOS 1.2 and 1.3, same machine as above. But was this with the stock serial port on the 2000 or was it with a serial expansion board? -- =================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mt. View, CA 94043 =================================================================== "If someone thinks they know what I said, then I didn't say it!"
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (04/14/90)
In article <Apr.12.13.47.28.1990.7927@pilot.njin.net> limonce@pilot.njin.net (Tom Limoncelli) writes: [...] >basically the serial.device in pre-1.3 AmigaDOS wasn't so hot, and 1.3 >only has a couple improvements. [...] >Obviously the Amiga >can handle it. It just takes good software. >(I say that because the ASDG serial board doesn't have its own CPU and >they get great results It isn't quite that simple. The ASDG serial board has a several byte buffer, so they do have a real hardware advantage over the stock Amiga serial port. With the standard serial port, you have to get each byte. If your receiver buffer full interrupt handler isn't fast enough, or you get locked out for awhile (e.g., by the input.device Disable()ing excessively), then the data is gone. With the ASDG board (and the Checkpoint board, I believe--dunno about any of the others) the interrupt routine has a lot more time to do it's work before the hardware buffer gets overrun. So it should always be possible to run the ASDG board faster than the Amiga serial port, assuming equally good software. -Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell University
Sullivan@cup.portal.com (sullivan - segall) (04/15/90)
> >** 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). > Hey, this is EXACTLY what I need. Does anyone know what the maximum sustained serial output rate is for the PAULA chip w/o start and stop bits? (I need to output a serial data stream that is *continuous* ie: has no start or stop bits, only periodic synch words.)... hmmm. Btw: just looked in the hardware manual at the description of the output register and it seems to enforce one start bit. Oh well. -Sullivan Segall _________________________________________________________________ /V\ Sullivan was the first to learn how to jump without moving. ' Is it not proper that the student should surpass the teacher? To Quote the immortal Socrates: "I drank what?" -Sullivan _________________________________________________________________ Mail to: ...sun!portal!cup.portal.com!Sullivan or Sullivan@cup.portal.com