From: jrd@cc.usu.edu
Newsgroups: comp.unix.sysv386
Subject: Re: Wyse160 vs IBMPC+Kermit
Date: 10 Apr 92 11:05:35 MDT
Organization: Utah State University

In article <1992Apr8.124233.16330@compuram.bbt.se>, pgd@compuram.bbt.se (Per Lindqvist) writes:
> jrd@cc.usu.edu writes:
> : 
> : 	Some informal testing here shows that an average PC's video system,
> : clone VGA board, runs around 9600 baud effective, limited mostly by screen
> : scrolling rates. Some are slower, some video boards are nicely faster.
> 
> I have written a high-speed screen driver (for 386BSD), and it gives
> over 90000 chars/second both scrolling and non-scrolling, which
> translated to around 900000 baud, if run over a serial line. For a
> 16-bit architecture I would expect half these numbers. I also think
> you can increase this speed, maybe double it or more, by writing
> assembly code for the time-critical loop.
> 
> So the video system is obviously capable of much higher speeds than
> what the current crop of pc programs gives. It has always been a
> mystery to me why terminal emulation programs are so slow on a pc,
> even on a fast 386 machine.  They commonly drop characters at rates
> over 19200 baud (1920 chars/second). (I have not tried the newest kermit)
> 
> Now, different VGA cards might have different number of wait-states
> for memory access, so your mileage might vary.
> 
> -- 
> Per Lindqvist
> 
> Internet: pgd@compuram.bbt.se   Fidonet: Per Lindqvist @ 2:201/332
-----------------------
	MSK is in assembly language. Things to remember: there is a hardware
cursor on the screen which needs maintenance, and one is far better off
letting the Bios do that. MSK is Windows and DV aware so all video changes
are posted to those guys too. And it has to take the steps to do snow removal
for the older CGA boards. As you say, video memory speeds differ dramatically 
and I find the 90,000 char/sec figure to be extremely high. Not questioning
your values but pointing out they are not representative of the standard
equipment in the field today. Dropped characters result from system effects
outside a comms program, such as interrupts off by some video Bios scrolling
routines and by DOS' PRINT TSR and so on. Sorry to have mentioned the last
in a Unix forum.
	In addition, terminal emulators are naturally one character at a
time systems, with a little to a lot of things to do with each, depending
on how sophisticated the emulator is. A simple block write will be far faster
than a per character system which has to reach down to the comms link for
each new character. PC terminal emulators also have to do comms link
maintenance on each read/write, if nothing else than to scan for XON/XOFF
and link status (CD/DSR or network path down, etc).
	For what it's worth dept. Tie a regular terminal to the serial port
of a PC and run a comms program talking to a fast host on another link. Ask
the program to copy the traffic to the terminal. See if the terminal can
sustain the speeds the PC emulator can. Good luck because at 9600 baud the
terminals around here all run out of steam right away (no flow control allowed
for the terminals). My experience is real terminals are lucky to sustain
4800 baud, less if they are slow scrollers.
	Joe D.