heuring@boulder.UUCP (Vincent Heuring) (01/18/85)
I: Does *ANYBODY* have a termcap for the IIe with the Apple 80 column board? Please reply via this newsgroup. II: (FLAME) I have been using my IIe to communicate with our local system at 1200 baud for a year now, and have had real frustrations with the slowness of the Apple Monitor. I need to pad linefeeds with three nulls to keep the monitor from dropping one to three characters at the beginning of lines. I have been using the Apple SuperSerial card, and could find no way around the problem. This is not a particularly big problem if one communicates with only one or two systems, but became a real hassle when dealing with a number of different ones: VAX/Unix, VAX/vms, Cyber, Lockheed Dialog, etc. I have been phoning the Apple hotline about this every few months, trying to get a) a straight answer,and b) a solution to my problem. The first few calls resulted in answers of "I don't know," "It must be your software," (stupid answer) "maybe it's the modem," (another stupid answer) etc etc. Finally, a few months ago, one of the guys admitted that it was the monitor program on the 80 col. card ( a straight answer), but his (non)solution was to hang around the local computer store and wait for an upgrade that might appear some year. arghhhhhh. First, the types that populate most computer stores are hostile to any question except "Can I buy a Lisa if I pay full price?" And second, most of them have the technical smarts of a planarian worm. What is most irritating about this is an attitude on the part of the customer service people that if there is no currently available fix to the problem, that the problem isn't a problem, it is an undocumented feature. I like Apple, and I think they are good for the industry; but let's not confuse them with a *real* computer vendor, that gets on bugs, has a real field service organization, etc. Oh, by the way, if anybody does have a fix for the monitor problem, I would appreciate hearing about it. V. Heuring Electrical and Computer Engineering Dep't. University of Colorado - Boulder.
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (01/20/85)
# # Apple //e with 80-column card # The modem interface is permitted to discard LF (maybe DC1), otherwise # passing characters to the 80-column firmware via COUT (PR#3 assumed). # Auto-wrap does not work right due to newline scrolling delay, which also # requires that you set "stty cr2". # Note: Cursor addressing is only available via the Pascal V1.1 entry, # not via the BASIC PR#3 hook. All this nonsense can be avoided only by # using a terminal emulation program instead of the built-in firmware. ab|apple2e|Apple //e:\ :bl=^G:bw:cd=4*^K:ce=4^]:cl=100^L:co#80:ho=^Y:is=^R^N:kd=^J:kl=^H:\ :kr=^U:ku=^K:li#24:me=^N:mr=^O:ms:nw=100\r:rs=^R^N:se=^N:sf=^W:so=^O:\ :sr=^V:up=^_:\ :bs:nc: ap|apple2e-p|Apple //e via Pascal:\ :cm=^^%r%+ %+ :tc=apple2e:
ags@pucc-i (Dave Seaman) (01/22/85)
> II: (FLAME) I have been using my IIe to communicate with our local system at > 1200 baud for a year now, and have had real frustrations with > the slowness of the Apple Monitor. I need to pad linefeeds with > three nulls to keep the monitor from dropping one to three characters > at the beginning of lines. The "slowness of the Apple Monitor" is not the problem. It's the Apple hardware. Scrolling the screen on an Apple involves moving 23x80 characters in memory. This requires about 3700 memory references. There isn't time to do this in the 8.3 milliseconds that you have between characters arriving on a 1200 baud line, even if you don't bother with such things as branching and incrementing. > What is most irritating about this is an attitude on the part of > the customer service people that if there is no currently available > fix to the problem, that the problem isn't a problem, it is an > undocumented feature. It's more like a documented non-feature. The Apple monitor does not actively support interrupts, which are the only solution to the problem. On the other hand, the hooks are available so that user programs can do their own interrupt processing. One of the reasons most terminal programs do not do this is that most communications cards do not adhere to the Apple standards for interrupt handling, which were established rather late in the game. See the Apple //e Reference Manual. -- Dave Seaman ..!pur-ee!pucc-i:ags
ben@moncol.UUCP (Bennett Broder) (01/22/85)
Although it is true that the firmware in the Apple Super Serial Card
loses characters at baud rates over 300 (a fact that is mentioned in
the documentation), good terminal software can easily remedy the
problem. I have used the SSC with an IIe at 9600 baud (with no
padding) using the program Softerm II by Softronics of Memphis
Tenn. The software is so good that it can even run your printer
concurrently and still not lose a character.
Ben Broder
..vax135!petsd!moncol!benee177xak@sdcc7.UUCP (Tien Nguyen{|stu) (01/25/85)
Does anyone know how to put the Super Serial Card into Terminal mode via Pascal 1.1. please mail or post your solution. Thanks, T. Nguyen UCSD sdcsvax!sdcc7!ee171xak
rbt@sftig.UUCP (R.Thomas) (01/28/85)
> > II: (FLAME) I have been using my IIe to communicate with our local system at > 1200 baud for a year now, and have had real frustrations with > the slowness of the Apple Monitor. I need to pad linefeeds with > three nulls to keep the monitor from dropping one to three characters > at the beginning of lines. I have been using the Apple SuperSerial > card, and could find no way around the problem. > ... > V. Heuring > Electrical and Computer Engineering Dep't. > University of Colorado - Boulder. One possible fix to your problem is to decrease the size of the scrolling area. The fundamental problem is that it takes a long time for the poor little old 6502 to scroll all those characters when it gets a line feed, and it does not poll the Super Serial Card for incoming characters while it is doing the scroll. I have a *real* terminal emulator that does scrolling and polling at the same time. I am very happy with it. I have it on beta test right now, but the author may make it available to the world sometime soon. Because of this fact, I have not tried out the proposed fix, but it was given to me by someone who claimed to have gotten it from Apple Tech support. For what that's worth. My source claimed that just decreasing the size of the scrolling area by 'a few' lines did the trick at 1200 baud. A 20 line screen that handles 1200 baud is better than a 24 line screen that doesn't, I always say. Rick Thomas ihnp4!btlunix!rbt
rbt@sftig.UUCP (R.Thomas) (01/28/85)
> It's more like a documented non-feature. The Apple monitor does not > actively support interrupts, which are the only solution to the problem. > On the other hand, the hooks are available so that user programs can do > their own interrupt processing. One of the reasons most terminal programs > do not do this is that most communications cards do not adhere to the > Apple standards for interrupt handling, which were established rather > late in the game. See the Apple //e Reference Manual. > -- > Dave Seaman ..!pur-ee!pucc-i:ags In fact, the Apple Super Serial Card even does not support the protocol for interrupt priority as written down in the //e reference manual. However, if you have only one interrupting card, and that is your Super Serial Card, (The most likely competition would be a clock card, and if you have a clock card you dont need to have the SSC interrupt, because you can ask the clock card to interrupt once every 4 ms or so, and poll the SSC in the clock service routine.) then the protocol is followed by default. For what it's worth. The above inforamtion can all be gleaned by a careful reading of the SSC reference manual and the //e reference manual. It's all there, you just have to know where to look. Rick Thomas ihnp4!btlunix!rbt
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (01/29/85)
> ... most communications cards do not adhere to the > Apple standards for interrupt handling, which were established rather > late in the game. All that is needed is usually a jumper between two of the fingers on the card's edge connector.