Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!cbatt!cbosgd!ihnp4!houxm!ho95e!wcs From: wcs@ho95e.UUCP (#Bill_Stewart) Newsgroups: net.periphs,net.micro,net.wanted Subject: Re: update on **real** 19200 CRT Message-ID: <773@ho95e.UUCP> Date: Wed, 6-Aug-86 17:09:14 EDT Article-I.D.: ho95e.773 Posted: Wed Aug 6 17:09:14 1986 Date-Received: Sat, 9-Aug-86 02:44:37 EDT References: <671@mordred.purdue.UUCP> <71@winfree.UUCP> <2349@cbosgd.UUCP> <604@ulowell.UUCP> <15071@ucbvax.BERKELEY.EDU> <855@usl.UUCP> Reply-To: wcs@ho95e.UUCP (Bill Stewart 1-201-949-0705 ihnp4!ho95c!wcs HO 2G202) Organization: AT&T Bell Labs, Holmdel NJ Lines: 42 Keywords: scrolling speed Xref: watmath net.periphs:1170 net.micro:15288 net.wanted:9361 The general concensus has been that not many PC-priced things can emulate a terminal at 19200 without doing *any* flow control, and that the primary limitation is the time to bitblt the whole screen up one line. I'm curious as to the type of application that really needs this capability. You're obviously not planning to *read* the data as it scrolls by continuously: 1920 char/sec * 60 sec/min / 6 char/word = 19200 words/minute "Evelyn Wood's *mother* can't read that fast!" 1920 char/sec / <=80 char/line >=24 lines/sec >=1 screen/sec. That's pretty fast. Not quite movies, but fast. I doubt you could read any of it as it's scrolling. Some possibilities: - You're trying to do a status display - One useful approach is *don't scroll* - wrap around to the top of the screen instead of scrolling it. This is a bit like "more -c", and has been referred to as "MIT Scrolling". This way, you still have to blit the characters onto the line, but you never have to move them once they're there - cuts down on characters drawn by 24x. Even a cheap 4.77 MHz system ought to be able to handle this, and you shouldn't have to program the video chips yourself. - the stuff is bursty, like from an IBM 3270 cluster controller. - In this case you could buffer it up, and display what fits unless there are cursor movement characters that make it tough. - You're doing interactive editing over a brain-damaged network. Again, the stuff is probably bursty, and you might be able to live with buffering. Alternatively, maybe you can put pad characters into the data stream - especially on the newlines and any cursor movement characters. Of course, the real way to make the application work would be to have a video display chip that used *indirect* accesses to it's memory - instead of always getting line 0 from addresses 0-79, it could get them from p[0]+0 to p[0]+79. This would let you scroll by blitting an array of 24 or so pointers, instead of the whole screen. Probably the pointers should go in a dual-ported RAM, since you'll be addressing them a lot? Video-retrace management might become a lot simpler - switching between blocks of memory during a retrace could be easy. -- # Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs