crmeyer@nobbs.physics.ucsb.edu (12/04/90)
I recently aquired a Kaypro II ('83 type) and wanted to use it to
telecomunicate at 9600 baud. Using the included TERM program, it
seemed that the program dropped the first several characters of each
line. Does anyone have any software or hardware based solutions that
they could reccommend? I vaugly remember a similar question being asked
recently, but did not have the Kaypro at that point and did not save the
messages :(. If 9600 baud is too fast, will it work correctly at
2400 baud? I know 1200 is OK.
Thanks!
+-----------------------------------+
| Charles R. Meyer |
| |
| Internet: crmeyer@voodoo.ucsb.edu |
| Bitnet: crmeyer@voodoo |
| HEPnet: voodoo::crmeyer |
+-----------------------------------+ fzsitvay@techbook.com (Frank Zsitvay) (12/05/90)
In article <7632@hub.ucsb.edu> crmeyer@nobbs.physics.ucsb.edu writes: >I recently aquired a Kaypro II ('83 type) and wanted to use it to >telecomunicate at 9600 baud. Using the included TERM program, it >seemed that the program dropped the first several characters of each >line. Does anyone have any software or hardware based solutions that >they could reccommend? I vaugly remember a similar question being asked >recently, but did not have the Kaypro at that point and did not save the >messages :(. If 9600 baud is too fast, will it work correctly at >2400 baud? I know 1200 is OK. i use imp245 (of irv hoff fame) and at 2400 baud it loses the third char of every line on my II/83. i imagine this is due to the screen handling routines in ROM, as it apparently takes more time to handle a carriage return than it does to put a char on the screen. the best solution would be to use a lower baud rate until you can either increase the processor speed or install a rom that handles the screen quicker. at 2400 baud, i have no problems when i configure the host system to insert 3 nulls after every carriage return. at 9600 baud you'd probably need 40 or 50 of them. -- fzsitvay@techbook.COM - but don't quote me on that.... American Oil Company motto - Bend over, We'll pump!!!
) (12/14/90)
In article <1990Dec5.125959.2947@techbook.com>, fzsitvay@techbook.com (Frank Zsitvay) writes: > In article <7632@hub.ucsb.edu> crmeyer@nobbs.physics.ucsb.edu writes: > > i imagine this is due to the screen handling routines in ROM, as it > apparently takes more time to handle a carriage return than it does to > put a char on the screen. On mine, it's due to having to scroll the screen contens up a line. I've got an 84 model or three, and it keeps chars fine after a screen clear until it hits line 25 and then begins to scroll and lose chars 3 to 6 of every line. Really annoying. Got the uC Max Rom and it worked until I got a Maestro 2400ZXR modem. Now it's just as bad as before with 1200 baud! I changed the 6845 too and it does make a difference, but not enough. We're gonna have to fix this one for good Guys! Damn. > > the best solution would be to use a lower baud rate until you can either > increase the processor speed or install a rom that handles the screen > quicker. at 2400 baud, i have no problems when i configure the host system > to insert 3 nulls after every carriage return. at 9600 baud you'd probably > need 40 or 50 of them. My prob is that not all BBS'es let you use Nulls anymore. Why the newest & "best" BBS software doesn't do this is beyond me! Ronn
mlinar@pollux.usc.edu (Mitch Mlinar) (12/21/90)
With the KayPLUS ROM, I can run at a peak of 4800 baud. I can't quite remember, but I think that consecutive screen-clears will ultimately cause a char to be dropped. The uC ROM is no better than the Kaypro ROM regarding screen update speed. In other words, it is not very good. However, one should note that the 6845 setup on the Kaypro is a poor h/w job; the video s/w is stuck with all the work and handshaking and timing -- no fun at all. The uC and Kaypro original s/w tried to compensate and ended up with an effective but slower solution. -Mitch
ewen@actrix.gen.nz (Ewen McNeill) (12/22/90)
In article <28971@usc> mlinar@pollux.usc.edu (Mitch Mlinar) writes: > > With the KayPLUS ROM, I can run at a peak of 4800 baud. I can't quite > remember, but I think that consecutive screen-clears will ultimately cause > a char to be dropped. > IMHO that is a little silly. My terminal program (runs in the native mode of my CP/M machine) traps that. I did this mostly because the screen is bit-mapped (16K) and takes _ages_ to clear (well, ages in processor time!). Some of the BB systems I know (Opus particularly) send 3 or 4 clear screen sequences. I would have thought that any reasonable bios/comms program would have the same trap. -- Ewen McNeill. Email: ewen@actrix.gen.nz
mlinar@eve.usc.edu (Mitch Mlinar) (12/22/90)
In article <1990Dec21.215841.23232@actrix.gen.nz> ewen@actrix.gen.nz (Ewen McNeill) writes:
## remember, but I think that consecutive screen-clears will ultimately cause
## a char to be dropped.
##
#IMHO that is a little silly. My terminal program (runs in the
#native mode of my CP/M machine) traps that. I did this mostly
#because the screen is bit-mapped (16K) and takes _ages_ to clear
#(well, ages in processor time!). Some of the BB systems I know
#(Opus particularly) send 3 or 4 clear screen sequences.
#I would have thought that any reasonable bios/comms program would
#have the same trap.
#
No. Not true. I don't know of any BIOSes in Kaypro/Xerox land that
trap multiple screen clears. COMM programs (by and large) do not know
the clear screen sequence for the local terminal or, if they do, do
not check for repeating sequences.
Otherwise, I agree that multiple sequential screen clears are goofy and
unnecessary.
-Mitch