dfh@ecs.UUCP (07/09/83)
I for one am a little disappointed in the Apple //e as compared to the Apple ][. There seems to be a significant problem with the //e's screen I/O when using communications software/hardware. For example, I tried using Datalink (a Pascal based communications program) with the Apple //e 80 column card, and it loses characters at 1200 baud. Not all the time mind you, just when the screen is filled and has to scroll up one line before the next line can be displayed. If I take out the 80 column card, the problem persists. Not only does the problem exist with the Apple 80 column cards (both the plain and 'extended' with 64K RAM), but the Smarterm II suffers the same fate. The Smarterm I appears to work fine however with Datalink, as well as the Wesper Systems 'Wizard 80' card. The problem crosses software boundaries too. Ascii Express (An Apple DOS based communications program) seems to have the same trouble, with the afore mentioned 80 column cards, as well as a Pascal based communications program of my own construction (which works fine on my Apple ][ as well as a Franlin ACE 1000). Visiterm, however, which uses its own character set seems to work fine. Softerm, a terminal emulation program also seems to work fine. It's quite clear that Softerm uses it's own screen I/O instead of 'hooks' into the monitor because it works at 9600 baud. (Nice package, by the way). Thus I conclude that there is a hardware design error with the Apple and ALS 80 column cards. There is a close connection between Apple and ALS. Perhaps it is too close? I know that apple was aware of a 'bus contention' problem between the new 'slot 3' and the rest of the bus, but I haven't heard of any fixes in the mill. Has anybody else experienced the symptoms I describe? They are probably more apparent when communicating with full duplex character-oriented services like UNIX than with line oriented (which have a short delay after sending a line) services like IBM TSO. Does Apple plan to fix the problem? David Hinnant N.C. Educational Computing Service (919) 549-0671 ...ucbvax!decvax!duke!tucc!ecs!dfh
jed@mb2c.UUCP (07/12/83)
The problem with losing characters when scrolling is indeed a problem when using the built-in scrolling functions and certain software/hardware combinations. The problem has to do with the time it takes to scroll the 1920 characters in memory (Apple-//e 80 col card). Some of the 80-col cards for the ][ (which I should add cost a lot more too) use a CRTC chip which uses an array of pointers to the lines on the screen, e.g. to scroll the screen, all the program has to do is move all of the pointers up by one and clear out an 80-byte memory area for the new line. This is obviously much faster than moving 1920 bytes. SOFTERM has no magic trick for scrolling the screen faster, in fact it scrolls slower. What it does do however is never work on the scrolling job long enough to lose a character at 9600 baud, assuming that the modem or serial interface can buffer 1 character. That is, by using instruction timings, you can figure out about how many instructions you can execute in 1/960th second and you never do more than that without checking to see if a character came in. Since the Apple is not interrupt driven from the factory, this is the only way to do it. The characters which are brought in during the scroll operation are buffered (SOFTERM uses 256 byte buffer) and then processed when the operation is completed. John Duncan (mb2c!jed) Michigan Bell (313) 424-0711