c9c-cb@danube.Berkeley.EDU (Edward Wang) (09/10/90)
I recently bought a external modem and Super Serial Card for my Apple IIe. I'm basically using the computer as a terminal to access the class computers on campus. However, I'm having problems. I have a DataLink Express modem put out by Applied Engineering. It can do 300, 1200, or 2400 baud. It only works okay on 300 baud. At any higher speed, characters start to drop. I get no garbage characters though. The missing characters seem to happen in three character blocks. Does anyone know what's causing this? Does this sound like a modem problem or serial card problem? By the way, there is definitely no problem with the campus's computers. My friends get perfect input on their modems. Also, I am positive that I've set all the switches on the serial card correctly. Also, the serial card that I bought was not new and was probably built in the early 1980's. However, it is a genuine Apple product. Thanks, Edward Wang
whitewolf@gnh-starport.cts.com (Tae Song) (09/14/90)
Edward Wang writes: |I recently bought a external modem and Super Serial Card for my Apple IIe. |I'm basically using the computer as a terminal to access the class computers |on campus. However, I'm having problems. I have a DataLink Express modem |put out by Applied Engineering. It can do 300, 1200, or 2400 baud. It |only works okay on 300 baud. At any higher speed, characters start to |drop. I get no garbage characters though. The missing characters seem to |happen in three character blocks. Does anyone know what's causing this? |Does this sound like a modem problem or serial card problem? | | By the way, there is definitely no problem with the campus's |computers. My friends get perfect input on their modems. Also, I am |positive that I've set all the switches on the serial card correctly. |Also, the serial card that I bought was not new and was probably built |in the early 1980's. However, it is a genuine Apple product. | | | Thanks, | Edward Wang | Hahaha... geez... there's going to be a lot reply on this... OK, yours is a simple problem, you need to enable the interrupts on the Super Serial Card. Someone will tell you exactly how since, I have a GS and don't have to bother with these silly things...:) called DIP switch... Wanna know why there called DIP switches.... >:> Just kidding...
DCS4@psuvm.psu.edu (Dave Shaffer) (09/15/90)
>Edward Wang writes: > >|I recently bought a external modem and Super Serial Card for my Apple IIe. >|I'm basically using the computer as a terminal to access the class computers >|on campus. However, I'm having problems. I have a DataLink Express modem >|put out by Applied Engineering. It can do 300, 1200, or 2400 baud. It >|only works okay on 300 baud. At any higher speed, characters start to >|drop. I get no garbage characters though. The missing characters seem to >|happen in three character blocks. Does anyone know what's causing this? >|Does this sound like a modem problem or serial card problem? >| >| By the way, there is definitely no problem with the campus's >|computers. My friends get perfect input on their modems. Also, I am >|positive that I've set all the switches on the serial card correctly. >|Also, the serial card that I bought was not new and was probably built >|in the early 1980's. However, it is a genuine Apple product. Is your IIe enhanced? I'm no expert on this, but I believe I recall reading of similar problems faced by users of unenhanced IIe models. I use an enhanced IIe with a 1200 buad datalinker modem and have not experienced the loss of characters you described.
pyue@ria.ccs.uwo.ca (Paul Yue, CCS) (09/16/90)
Howdy, This doesn't look like a hardware problem, but rather a hardware limitation. Before I got my circa 1983 Apple ||e enhanced, it would lose a lot of characters on the modem. Apparently, its display ROM was a little too slow to keep up with the transmission (this is just a guess). The problem could be solved by enabling flow control (XON/XOFF) on the communications software, eg on Kermit 2.86 I would do >set flow xon >set flow delay 3c From what I understand, flow control just uses ^S and ^Q to keep the incoming data under control. I don't know if the DIP switches can set this. Someone else will have to jump in. BTW, I'm now happily punching away at an enhanced ||e, and there doesn't seem to be any need for flow control at all. See ya soon. -- ------------------------------------------------------------------------------- Paul K. Yue pyue@{uwo.ca|nve.uwo.ca|uwovax.bitnet} uunet!watmath!ria!pyue ------------------------------------------------------------------------------- Computing and Communications Services Natural Sciences Centre, UWO London, Ontario N6A 5B7 Canada Voice:(519) 661-3525 FAX:(519) 661-3486
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/16/90)
In article <90257.155707DCS4@psuvm.psu.edu> DCS4@psuvm.psu.edu (Dave Shaffer) writes: >Is your IIe enhanced? The 80-column firmware in the enhanced Apple //e did indeed reduce the time during which interrupts were disabled while scrolling the display. In general, high-speed input via a 2-character buffered USART requires either an interrupt handler that moves the USART data into an external input buffer, or frequent polling of the USART status in order to ditto as soon as feasible. The old 80-column firmware simply took too long and incoming data could overrun the USART's tiny internal buffer while the display was being scrolled. Quite a few Apple II communication programs therefore performed their own display management rather than relying on Apple's built-in firmware. There is a similar problem when attempting to write data to disk while more data is arriving via USART; because the Disk II relies on exact CPU cycle counts for the timing of data being written directly to the disk, interrupts must be disabled for the duration of an entire block, which is a serious problem when there is a high-speed source of incoming data that must be captured before it is lost. These problems were well known in general to the computing community long before the Apple II was designed; however, the Apple II was meant to be basically a single-user hobbyist ("toy") computer that could be sold for a price that an individual could be expected to afford. Thus, the somewhat sophisticated techniques used to solve such problems in real computers were omitted from the Apple II's design. There have been some improvements since then to alleviate the problem of asynchronous (simultaneous channels of) I/O, as can be seen in the support (such as it is) for application interrupt handlers in ProDOS and in the addition of automatic buffering options in the IIGS firmware, but probably compatibility considerations will prevent the problem from being fully solved in any Apple II family member.
bill@braille.uwo.ca (Bill Carss) (09/17/90)
I have been telecommnuicating actively for only a few years (although primarily over the last year or so). I have had this recording or "capturing" problem with the DuoDisk and ProFile. The only way I have found to get around it is to establish a recording file in RAM. That way information can bdDe captrued as quickly as it arrives and then safely transferred to disk at your convenience. Of course, if there is any kind of power interuption before the info is saved, it is lost, but that has happened to moDe only a couple of times. Bill Carss bill@braille.uwo.ca (Please note the upDDlower case)
tomk@pro-sol.cts.com (Tom Kelly) (09/20/90)
In-Reply-To: message from bill@braille.uwo.ca It seems that if you turn interupts on and you software issues a control S when its copy buffer gets full, that the host should wait while the copy buffer is written to "disk" no matter what kind of disk it is. After it has been written out , the buffer is cleared and the software issues a control Q and the host should resume sending. That way nothing should ever be "lost".
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/21/90)
In article <4526@crash.cts.com> tomk@pro-sol.cts.com (Tom Kelly) writes: >It seems that if you turn interupts on and you software issues a control S >when its copy buffer gets full, that the host should wait while the copy >buffer is written to "disk" no matter what kind of disk it is. After it has >been written out , the buffer is cleared and the software issues a control Q >and the host should resume sending. That way nothing should ever be "lost". In full-duplex operation, several more characters may arrive AFTER you think you have sent the DC3 (^S) to block the transmitting system. If interrupts are off and frequent polling of the UART is not being done, some of these incoming characters can indeed be lost.
tomk@pro-sol.cts.com (Tom Kelly) (09/23/90)
In-Reply-To: message from gwyn@smoke.BRL.MIL My explaination (sic?) was with interupts ON. You describe it with interupts OFF. It would seem that we actually aggree! Do we not?