paul@vixie.UUCP (Paul Vixie Esq) (07/10/86)
Quite a few people have responded to my request for 19200 CRTs. The unoffical
tally shows the Wyse 50 in the lead, closely followed by a Televideo 950. The
950's keyboard removes it from serious consideration, but I'm looking into the
Wyse. I'll post a a real summary when I stop getting replies.
However, due to user hosiness (I erred), I lost one reply. Someone from Encore
Computers sent me a table comparing the aggregate output speeds of various
terminals; I absent-mindedly said "s * Mail/crt19200" in the BSD Mail program;
it didn't print any error messages, but since there was no "Mail" directory
where I was, it didn't save it either. I typed "d *" and "q", then "oh s--t".
So, could the fellow from Encore please resend his message? It was one of
the most informative of those I received, and its loss is/was frustrating.
Paul Vixie
{fortune,qantel}!vixie!paulbdale@winfree.UUCP (07/13/86)
In article <109@vixie.UUCP> paul@vixie.UUCP (Paul Vixie Esq) writes: >...The unoffical >tally shows the Wyse 50 in the lead, closely followed by a Televideo 950. The >950's keyboard removes it from serious consideration, but I'm looking into the >Wyse. > Paul Vixie > {fortune,qantel}!vixie!paul Paul -- Stay away from the Wyse-50. I bought about a half dozen at my former job, and loved them dearly (especially the keyboards!) until I started running Emacs on them... then I found out the hitch. The Wyse-50 emulates the Televideo and similar terminals, and eats a screen location every time it changes attribute modes on the screen. So, for example, an emacs mode line done in inverse video will get horribly trashed as time goes on... rewriting the screen with sort of fix it, but you LOSE a location on the screen (it shows up as a blank) every time you change from normal to inverse to whatever. Wyse makes another terminal called the Wyse-75. I've not used one yet (just moved from Pittsburgh to Colorado Springs and am still getting settled), but it is supposedly fully VT100 compatible and has the same glorious keyboard as the 50. Don't have any idea if it will do 19,200... but I ran all the 50's at that speed. Find a local sales rep who will give you one to demo for a couple days. And let me know what you think. Sounds like it could be a winner. Bdale uucp: {bellcore, crash, hp-lsd, pitt, symmetric}!winfree!bdale arpa: bdale@g.cs.cmu.edu (forwards)
terry@brl-smoke.UUCP (07/16/86)
In article <65@winfree.UUCP> bdale@winfree.UUCP (Bdale Garbee) writes: >In article <109@vixie.UUCP> paul@vixie.UUCP (Paul Vixie Esq) writes: ... >Wyse makes another terminal called the Wyse-75. I've not used one yet (just I have a Wyse-75 terminal which I have used for about 2 years now. I had it connected to a VAX 750 as the sole user at 19.2K baud and can't remember having any problems with this configuration. However, I would still suggest that you try it first. Bill Bogstad bogstad@hopkins-eecs-bravo.arpa
shannon@sun.UUCP (07/16/86)
> Paul -- Stay away from the Wyse-50. I bought about a half dozen at my former > job, and loved them dearly (especially the keyboards!) until I started running > Emacs on them... then I found out the hitch. The Wyse-50 emulates the > Televideo and similar terminals, and eats a screen location every time it > changes attribute modes on the screen. So, for example, an emacs mode line > done in inverse video will get horribly trashed as time goes on... rewriting > the screen with sort of fix it, but you LOSE a location on the screen (it > shows up as a blank) every time you change from normal to inverse to whatever. Sounds like a reason to stay away from emacs if it can't deal with an otherwise excellent terminal that vi has no problems with! :-) I believe there is a way to run the Wyse-50 so that it uses half-intensity for standout mode, which doesn't take a screen position. The Wyse-50 also emulates other terminals, perhaps one of them doesn't have the "magic cookie glitch" problem. The only problem I have with the Wyse-50 is the "FUNCT" key - tear if off and throw it away, it's in the wrong place! Also look at the Wyse-30, a cheaper version of the Wyse-50 that may do what you need. Bill Shannon
narten@purdue.UUCP (Thomas Narten) (07/17/86)
In article <65@winfree.UUCP> bdale@winfree.UUCP (Bdale Garbee) writes: >Paul -- Stay away from the Wyse-50. I bought about a half dozen at my former >job, and loved them dearly (especially the keyboards!) until I started running >Emacs on them... then I found out the hitch. The Wyse-50 emulates the >Televideo and similar terminals, and eats a screen location every time it >changes attribute modes on the screen. So, for example, an emacs mode line >done in inverse video will get horribly trashed as time goes on... rewriting >the screen with sort of fix it, but you LOSE a location on the screen (it >shows up as a blank) every time you change from normal to inverse to whatever. >Paul -- Stay away from the Wyse-50. I bought about a half dozen at my former >job, and loved them dearly (especially the keyboards!) until I started running >Emacs on them... then I found out the hitch. The Wyse-50 emulates the >Televideo and similar terminals, and eats a screen location every time it >changes attribute modes on the screen. So, for example, an emacs mode line >done in inverse video will get horribly trashed as time goes on... rewriting >the screen with sort of fix it, but you LOSE a location on the screen (it >shows up as a blank) every time you change from normal to inverse to whatever. We have lots of Wyse50s and we run emacs on them without problems. For a long while though, we had trouble with a character position getting lost. This was easily duplicated by splitting the screen into 2 windows, then scrolling backwards in the lower window (the one below the status line). The first character of the lower window would appear on the previous line, which was the status line. Our problem was not with the terminals, but with the version of Unipress emacs we were using. We finally fixed it and the terminals work great. Are you really sure that the terminals are at fault? We have over 75 here, and next to bit mapped displays (attached to workstations), they are our terminal of choice. -- Thomas Narten narten@purdue.EDU {ucbvax, ihnp4, allegra}!purdue!narten
john@frog.UUCP (John Woods, Software) (07/17/86)
>In article <109@vixie.UUCP> paul@vixie.UUCP (Paul Vixie Esq) writes: >>...The unoffical >>tally shows the Wyse 50 in the lead, closely followed by a Televideo 950. >>The 950's keyboard removes it from serious consideration, but I'm looking >>into the Wyse. > > Paul Vixie > > {fortune,qantel}!vixie!paul >Paul -- Stay away from the Wyse-50. I bought about a half dozen at my former >job, and loved them dearly (especially the keyboards!) until I started >running Emacs on them... then I found out the hitch. The Wyse-50 ... >eats a screen location every time it changes attribute modes on the screen. The solution we've found here is to use "protected" mode for inverse video (sorry, only one mode per family): declare to the terminal (during the initialization string) that protected regions are to be inverse video, and then do inverse video by protecting regions of the screen. Disclaimer: I hate the Wyse 50, *especially* the keyboard. But they work, and if you are clever, you can get around the nauseating screen glitch. -- John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101 ...!decvax!frog!john, ...!mit-eddie!jfw, jfw%mit-ccc@MIT-XX.ARPA "Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining." Jeff Raskin, interviewed in Doctor Dobb's Journal
ron@brl-sem.ARPA (Ron Natalie <ron>) (07/19/86)
In article <5140@sun.uucp>, shannon@sun.uucp (Bill Shannon) writes: > > Paul -- Stay away from the Wyse-50. I bought about a half dozen at my former > > job, and loved them dearly (especially the keyboards!) until I started running > > Emacs on them... then I found out the hitch. The Wyse-50 emulates the > > Televideo and similar terminals, and eats a screen location every time it > > changes attribute modes on the screen. Isn't the Wyse-50 the stupid terminal that screws up if you have the control key depressed while it is typing? I use a Wyse 75 which works well with EMACS, but I don't know about it at 19,200 baud. Unfortunately VISUAL stopped making their best terminal, the VISUAL 200, and now makes a whole bunch of crud that looks like a cross between a VT100 and a Tektronix. -Ron
bdale@winfree.UUCP (Bdale Garbee) (07/20/86)
In article <671@mordred.purdue.UUCP> narten@purdue.UUCP (Thomas Narten) writes: >Our problem was not with the terminals, but with the version of Unipress >emacs we were using. We finally fixed it and the terminals work great. Are >you really sure that the terminals are at fault? We have over 75 here, and >next to bit mapped displays (attached to workstations), they are our >terminal of choice. The problem we ran into was specifically with inverse video and underlining, in that we seemed to always get a "space" added in before and after each line segment that was in a different mode. We were running Gosling's Emacs, and had access to sources. I don't think it was the software's fault, though I'm always willing to admit I'm wrong when things are demonstrated otherwise. (or should I have said other-Wyse? sorry, couldn't help that...) I'd still strongly suggest that anyone buying a terminal they're going to have to "live with" talk to a local distributor and get one in on demo for a week or two, so you can see if it really does what you want/need. I've had no trouble in the past getting them to do this, though it sometimes takes some fast talking, and the lure of "and I've got friends who might be interested". BTW: I'm currently convinced that selling my terminals and buying single- floppy 8Mhz PC clones with Amdek 310A monitors on Hercules-compatible monochrome video cards and using Kermit to make them into terminals part time is going to be a BIG win. Think about it, you can build the required PC clone for about $600-$700 last time I checked, and it WILL do 19200 ok with the faster processor and interrupt-driven I/O. Plus you've got more micros to play with! Bdale
elg@usl.UUCP (Eric Lee Green) (07/20/86)
>> Paul -- Stay away from the Wyse-50. I bought about a half dozen at my former >> job, and loved them dearly (especially the keyboards!) until I started running >> Emacs on them... then I found out the hitch. The Wyse-50 emulates the >> Televideo and similar terminals, and eats a screen location every time it >> changes attribute modes on the screen. So, for example, an emacs mode line >> done in inverse video will get horribly trashed as time goes on... rewriting >> the screen with sort of fix it, but you LOSE a location on the screen (it >> shows up as a blank) every time you change from normal to inverse to whatever. This person is obviously using an older version of Gosling Emacs, which suffers from a bad case of BRAIN DAMAGE (almost as big a case of B.D. as the people who invented "magic cookie" attributes in the first place). We were running Gosling Emacs on our Pyramids, with a terminal room full of TVI910s, and it did the same thing to them. Switch to GNU Emacs. It may be big, but at least it handles non-VT100 terminals the correct way. We have no problems with TVI910s and GNU Emacs. In fact, Gosling Emacs is history at this site... the sysadmin zapped it off of disk, installed GNU, and our troubles were over. -- -- Computing from the Bayous, -- Eric Green {akgua,ut-sally}!usl!elg (Snail Mail P.O. Box 92191, Lafayette, LA 70509)
mouse@mcgill-vision.UUCP (der Mouse) (07/27/86)
>> ...The unoffical tally shows the Wyse 50 in the lead, closely >> followed by a Televideo 950. The 950's keyboard removes it from >> serious consideration, What's wrong with the 950's keyboard? It's my second favorite keyboard (first is a Lisp Machine, not really comparable). >> but I'm looking into the Wyse. > Paul -- Stay away from the Wyse-50. I bought about a half dozen at > my former job, and loved them dearly (especially the keyboards!) > until I started running Emacs on them... then I found out the hitch. > The Wyse-50 emulates the Televideo and similar terminals, and eats a > screen location every time it changes attribute modes on the screen. > So, for example, an emacs mode line done in inverse video will get > horribly trashed as time goes on... rewriting the screen with sort of > fix it, but you LOSE a location on the screen (it shows up as a > blank) every time you change from normal to inverse to whatever. This is not a problem with the terminal, real TeleVideos (at least the older ones, like the 950) do that too. This is a problem with Emacs, compunded by the termcap entry you have. I cannot speak about the 50, but I know that the 950, which works the same way, had the same problem here. The trouble is that the Emacs screen updater does not recognize the sg termcap capability, causing terminals with non-zero sg to lose. What you need is to use bright for standout rather than inverse video (bright is the only attribute that doesn't take up a position). Presumably whoever built the termcap entry for the 950 paid too much attention to the note in the documentation that says that "if a terminal has multiple flavors of standout mode [...], the preferred mode is inverse video by itself [...]". For example, the tvi950 entry shipped with 4.2 reads (in part) :se=\EG0:sg#1:so=\EG4: which uses inverse video for standout, and says that changing takes a character position. This is unusable, because too many programs don't understand sg. So we are running with :se=\E):so=\E(: (and no sg). This works fine. I am typing this in Emacs on a 950, with bright for the modeline, and everything is OK.... If anyone wants my tvi950 termcap entry they are welcome to it---just send me mail. -- der Mouse USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse think!mosart!mcgill-vision!mouse Europe: mcvax!decvax!utcsri!mcgill-vision!mouse ARPAnet: utcsri!mcgill-vision!mouse@uw-beaver.arpa "Come with me a few minutes, mortal, and we shall talk."
elg@usl.UUCP (Eric Lee Green) (07/27/86)
In article <71@winfree.UUCP> bdale@winfree.UUCP (Bdale Garbee) writes: >In article <671@mordred.purdue.UUCP> narten@purdue.UUCP (Thomas Narten) writes: >>Our problem was not with the terminals, but with the version of Unipress >>emacs we were using. We finally fixed it and the terminals work great. Are >>you really sure that the terminals are at fault? We have over 75 here, and > >The problem we ran into was specifically with inverse video and underlining, >in that we seemed to always get a "space" added in before and after each >line segment that was in a different mode. We were running Gosling's Emacs, >and had access to sources. I don't think it was the software's fault, though >I'm always willing to admit I'm wrong when things are demonstrated otherwise. >(or should I have said other-Wyse? sorry, couldn't help that...) We have a terminal room of TVI910 terminals, which are functionally similiar to the Wyse 50. When using Gosling Emacs, we would have the same problem as mentioned above ("spaces" in mode lines). We solved the problem simply: by deleting Gosling Emacs off of disk, and replacing it with GNU Emacs 17.56. Problem solved. Q.E.D. Definitely a software problem and not a problem with the terminal. By the way, I got a letter from someone who claims that when termcap support was added to Gosling Emacs, they didn't have a brain-damaged terminal available, and since it was just an academic hack and they had no idea anybody would actually try to SELL the thing, they didn't bother putting in support for terminals with "magic cookies" (i.e. terminals that eat a byte of display space for attributes, such as the Wyse 50, Televideo line, Lear-Siegler, etc.). Eric -- -- Computing from the Bayous, -- Eric Green {akgua,ut-sally}!usl!elg (Snail Mail P.O. Box 92191, Lafayette, LA 70509)
mark@cbosgd.UUCP (Mark Horton) (07/28/86)
In article <71@winfree.UUCP> bdale@winfree.UUCP (Bdale Garbee) writes: >BTW: I'm currently convinced that selling my terminals and buying single- >floppy 8Mhz PC clones with Amdek 310A monitors on Hercules-compatible >monochrome video cards and using Kermit to make them into terminals part time >is going to be a BIG win. Think about it, you can build the required PC clone >for about $600-$700 last time I checked, and it WILL do 19200 ok with the >faster processor and interrupt-driven I/O. Plus you've got more micros to >play with! Before you decide to do this, I suggest you buy one, get your software running, and see if you like it. We have lots of users here using AT&T 6300's as terminals. (The 6300 has an 8MHz 8086 which will do at least as well as what you describe.) The terminal emulation programs don't come anywhere near 19200 bps; typical throughput is more likd 2400 bps or so. (I can't remember the exact figures, it might have been as high as 4000 bps. But it was nowhere near 19200. And it does vary from program to program.) The 6300 display board does snow, just like the official IBM color card, so if you can arrange to get a non-snowing card, and have your program know about it, you might speed things up a bit. The other problem is that the typical PC comes with a horribly braindamaged keyboard. Most terminals come with reasonable keyboards, except the VT200 series and clones. You can get a Keytronics keyboard, but you may not like the feel, and they will add $200 to your cost for the 5151. (If you can find a 5150 and like it, it may cost considerably less.) Mark
page@ulowell.UUCP (Bob Page) (07/29/86)
In article <71@winfree.UUCP> bdale@winfree.UUCP (Bdale Garbee) writes: >BTW: I'm currently convinced that selling my terminals and buying single- >floppy 8Mhz PC clones with Amdek 310A monitors on Hercules-compatible >monochrome video cards and using Kermit to make them into terminals part time >is going to be a BIG win. Think about it, you can build the required PC clone >for about $600-$700 last time I checked, and it WILL do 19200 ok with the >faster processor and interrupt-driven I/O. Plus you've got more micros to >play with! Since you're thinking about going micro-based, check out the Amiga. I use it, along with Commodore's "Amigaterm" terminal program. Has 80/128 column display, 24/48 rows of text (you need a long persistence monitor for 48 rows due to interlace flicker), XMODEM and Compuserve B protocols, hardware or software handshaking, you pick the colors of text/background, and it works great at 19200! Of course, you can still multitask all you want (recalculate your spreadsheet while you download a file, etc). Nice to have a window-based system. Emulates vt100, vt52, amiga (whatever THAT is!) and ANSI. I've only used vt100, which works fine. I've never seen a PC-based package (hardware + terminal program) that could keep up at 19.2, but the Amiga does so, effortlessly. I don't work for Commodore or Commodore-Amiga, by the way. I *am* the moderator of mod.amiga, though. ..Bob -- UUCP: wanginst!ulowell!page Bob Page, U of Lowell CS Dept VOX: +1 617 452 5000 x2233 Lowell MA 01854 USA
gemini@homxb.UUCP (Rick Richardson) (07/29/86)
> Before you decide to do this, I suggest you buy one, get your software > running, and see if you like it. We have lots of users here using AT&T > 6300's as terminals. (The 6300 has an 8MHz 8086 which will do at least > as well as what you describe.) The terminal emulation programs don't come > anywhere near 19200 bps; typical throughput is more likd 2400 bps or so. > (I can't remember the exact figures, it might have been as high as 4000 > bps. But it was nowhere near 19200. And it does vary from program to > program.) > > The 6300 display board does snow, just like the official IBM color card, > so if you can arrange to get a non-snowing card, and have your program > know about it, you might speed things up a bit. 19.2 Kbs ought to be easily achievable in a standalone situation as the original poster suggested, even on a stock IBM PC running at 4.77Mhz. The key is to use a truly dual ported video card, so you won't have to wait for retrace. At 1920 cps coming in from the 8250 you have about 500 usec to handle each interrupt. That's about 125 "average" instructions on a stock PC, or 250 on a fast clone. Now, reading the 8250 and putting the character in the video RAM is maybe a handfull of instructions. The tricky part is display scroll, which can happen in one of two ways: software or hardware. The software approach (used by IBM in the BIOS) requires a block move of 4000 bytes which takes about 4 msec. This is much too long if a series of new lines come along. But, you can scroll the display by simply moving the base address in the 6845 CRT controller with just a few instructions. The second home brew terminal I built used a BELLMAC-8 uP and 6845 CRT controller and scrolled the screen in this exact manner. > > The other problem is that the typical PC comes with a horribly braindamaged > keyboard. Most terminals come with reasonable keyboards, except the > VT200 series and clones. You can get a Keytronics keyboard, but you > may not like the feel, and they will add $200 to your cost for the 5151. > (If you can find a 5150 and like it, it may cost considerably less.) > > Mark > This one is easily fixed on any keyboard with removable tops. Just move the key (like Escape on an AT keyboard) to where it belongs, and adjust the keybaord lookup table accordingly. I've done it on my keyboard. It works. Most of the PC clones come with "AT" style keyboards, so you just have to exchange the Esc, tilda, and backspace keys to get a decent arrangement. Keyboard feel is a matter of personal taste. You may have to shop around to find the feel you like. I personally would opt for a genuine IBM AT keybaord. Conclusion: you CAN turn a $600 PC clone into a terminal capable of at least 9600 baud without flow control, and probably the full 19200, if you are willing to write tuned assembler at the raw metal level. Rick Richardson, PC Research, Inc. (201) 922-1134, (201) 834-1378 @ AT&T-CP ..!ihnp4!castor!{rer,pcrat!rer} <--Replies to here, not to homxb!gemini, please.
jhc@mtune.UUCP (07/30/86)
In article <1828@homxb.UUCP> gemini@homxb.UUCP (Rick Richardson) writes: >> Before you decide to do this, I suggest you buy one, get your software >> running, and see if you like it. We have lots of users here using AT&T >> 6300's as terminals. (The 6300 has an 8MHz 8086 which will do at least >> as well as what you describe.) The terminal emulation programs don't come >> anywhere near 19200 bps; typical throughput is more likd 2400 bps or so. >> (I can't remember the exact figures, it might have been as high as 4000 >> bps. But it was nowhere near 19200. And it does vary from program to >> program.) > >19.2 Kbs ought to be easily achievable in a standalone situation as >the original poster suggested, even on a stock IBM PC running at 4.77Mhz. >The key is to use a truly dual ported video card, so you won't have to >wait for retrace. At 1920 cps coming in from the 8250 you have >about 500 usec to handle each interrupt. That's about 125 >"average" instructions on a stock PC, or 250 on a fast clone. >Now, reading the 8250 and putting the character in the video >RAM is maybe a handfull of instructions. The tricky part is display scroll I can comment from significant personal experience here, especially with the AT&T PC 6300. One point is generic, and I presume that the IBM does the same thing (in the other point) although I haven't looked at the BIOS sources. First: emulating a terminal is *SLOW*. Rick is correct in stating that reading a character from a UART and writing it to a screen should take a few (<100) instructions. Unfortunately going through all the lookup tables, and modifying the program's behavious depending on the last character received, takes a lot of cycles. If you can set up a situation where you don't need to emulate then this is fastest. Second: The BIOS in the AT&T PC6300 executes a loop something like this when it writes to the screen: di loop: inb <display status> beq <retrace>, loop outb screen, char which means that anytime you write to the screen it busy-waits until the display is retracing. This is bad enough in the normal case, but I think that it actually waits for horizontal retrace, so when the display is in flyback it busy-waits. Now I am unable to comment on the competence of the Olivetti engineers who wrote that code, and I'm not a BIOS expert, but it did seem to me that one additional byte would have made everything a lot easier: loop: di inb <display status> ei beq <retrace>, loop outb screen, char NB the display status read and test had to be atomic. This does not clear up the vertical retrace stuff, and I don't know enough about the hardware to comment on that. Anyone know what the IBM PC does? -- Jonathan Clark [NAC,attmail]!mtune!jhc My walk has become rather more silly lately.
gemini@homxb.UUCP (Rick Richardson) (07/30/86)
>> In article <1828@homxb.UUCP> gemini@homxb.UUCP (Rick Richardson) writes: >>19.2 Kbs ought to be easily achievable in a standalone situation as >>the original poster suggested, even on a stock IBM PC running at 4.77Mhz. >>The key is to use a truly dual ported video card, so you won't have to >>wait for retrace. At 1920 cps coming in from the 8250 you have >>about 500 usec to handle each interrupt. That's about 125 >>"average" instructions on a stock PC, or 250 on a fast clone. >>Now, reading the 8250 and putting the character in the video >>RAM is maybe a handfull of instructions. The tricky part is display scroll > > Jonathan Clark writes: >emulating a terminal is *SLOW*. Rick is correct in stating that >reading a character from a UART and writing it to a screen should take >a few (<100) instructions. Unfortunately going through all the lookup >tables, and modifying the program's behavious depending on the last >character received, takes a lot of cycles. If you can set up a >situation where you don't need to emulate then this is fastest. The amount of work needed to emulate a terminal depends upon what terminal is being emulated, of course. To continue with my analysis of the problem, I can relate the facts of the first terminal I homebrewed, which was a 6800 uP with a dual ported display RAM. The entire ASSEMBLER code for emulating a VT52 with insert/delete line fit into a 2708 EPROM (1K)! The second terminal (Bellmac-8 uP, 6845 CRTC, dual ported display RAM) emulated an HP2645 and the "C" code fit in 16K. The second terminal also included both "Breakout" and "Space Invaders" local modes (No kidding, you could play games locally!). As I recall, the display code was basically a switch on the current state of Escape processing followed by a switch on the current character, followed by the actual work to be done for that combination of state/input character. Even in "C", I'm sure this was less than 100 instructions for each input character. > >Second: >The BIOS in the AT&T PC6300 executes a loop something like this when it >writes to the screen: > > di >loop: > inb <display status> > beq <retrace>, loop > outb screen, char > >which means that anytime you write to the screen it busy-waits until >the display is retracing. This is bad enough in the normal case, but I >think that it actually waits for horizontal retrace, so when the >display is in flyback it busy-waits. > >Anyone know what the IBM PC does? The IBM PC with CGA adapter has the same sort of loop; the display RAM is not dual ported. I believe that many of the clone cards ARE dual-ported and so don't require this sort of nonsense. The Video-7 VEGA EGA that I use is also dual ported: you can write the display RAM anytime you want to. As I stated before, if you want to run true 19.2 Kbaud, you'll need to use one of these dual ported display adapters AND you'll need to use the hardware scroll feature of the 6845 CRTC. Don't even think of using BIOS. Rick Richardson, PC Research, Inc. (201) 922-1134, (201) 834-1378 @ AT&T-CP ..!ihnp4!castor!{rer,pcrat!rer} <--Replies to here, not to homxb!gemini, please.
mazlack@ernie.Berkeley.EDU (Lawrence J. Mazlack) (07/31/86)
In article <604@ulowell.UUCP> page@ulowell.UUCP (Bob Page) writes: >In article <71@winfree.UUCP> bdale@winfree.UUCP (Bdale Garbee) writes: >>BTW: I'm currently convinced that selling my terminals and buying single- >>floppy 8Mhz PC clones with Amdek 310A monitors on Hercules-compatible >>monochrome video cards and using Kermit to make them into terminals part time >>is going to be a BIG win. Think about it, you can build the required PC clone >>for about $600-$700 last time I checked, and it WILL do 19200 ok with the >>faster processor and interrupt-driven I/O. Plus you've got more micros to >>play with! > >Since you're thinking about going micro-based, check out the Amiga. >I use it, along with Commodore's "Amigaterm" terminal program. Has >80/128 column display, 24/48 rows of text (you need a long persistence >monitor for 48 rows due to interlace flicker), XMODEM and Compuserve B >protocols, hardware or software handshaking, you pick the colors of >text/background, and it works great at 19200! Of course, you can >still multitask all you want (recalculate your spreadsheet while you >download a file, etc). Nice to have a window-based system. > >Emulates vt100, vt52, amiga (whatever THAT is!) and ANSI. I've >only used vt100, which works fine. I've never seen a PC-based >package (hardware + terminal program) that could keep up at 19.2, >but the Amiga does so, effortlessly. > >I don't work for Commodore or Commodore-Amiga, by the way. >I *am* the moderator of mod.amiga, though. > >..Bob >-- >UUCP: wanginst!ulowell!page Bob Page, U of Lowell CS Dept >VOX: +1 617 452 5000 x2233 Lowell MA 01854 USA Bob: Could you send me an exact list of hardware/software that I would need to do this. I could then explore doing it with my purchasing people. (My micro choice is a Mac - hardly a cost effective way of achieving a 19200 baud terminal.) Larry Mazlack UUCP {tektronix,dual,sun,ihnp4,decvax}!ucbvax!ucbernie!mazlack New style mazlack@ernie.berkeley.edu ARPA | CSNET mazlack%ernie@berkeley.ARPA BITNET mazlack@ucbernie.BITNET telephone (415) 528-0496 snail CS Dept, 571 Evans, U. California, Berkeley, CA 94720
sandersr@ecn-pc.UUCP (Robert C Sanders) (08/01/86)
In article <1832@homxb.UUCP> gemini@homxb.UUCP (Rick Richardson) writes: >>> In article <1828@homxb.UUCP> gemini@homxb.UUCP (Rick Richardson) writes: >>>19.2 Kbs ought to be easily achievable in a standalone situation as >>>the original poster suggested, even on a stock IBM PC running at 4.77Mhz. >>>The key is to use a truly dual ported video card, so you won't have to >>>wait for retrace. At 1920 cps coming in from the 8250 you have >>>about 500 usec to handle each interrupt. That's about 125 >>>"average" instructions on a stock PC, or 250 on a fast clone. >> >>Anyone know what the IBM PC does? > [ much - much deleted ] All this talk about 19200 bu problems. (tisk, tisk) I *KNOW* for a fact that IBM PC at 4.77 MHz using a standard CGA can emulate a full VT102 at 19200 baud. I am doing it right now!! I have measured the line, and sure enough, it is throughputting at 19200. I use Mark Of The Unicorn's PC/InterComm program on the PC end, and a direct port to a DH unit on a VAX. It will and does run 19200 baud. The screen does not flicker, and you should even see Kermit zip along. Anyway, EMACS, VI and even RN run perfectly fine; I have never had any of the problems. The termcap that I use is the "dt80", with the SO and SE characters changed to show bright (the PC goes blue when it gets a \E[4h ); the termcap includes *NO* pad characters. Note the the "dt80" termcap is identical to the "vt100-np" termcap without the initialization sequence for setting the tab stops. - bob -- Continuing Engineering Education Telecommunications Purdue University ...!ihnp4!pur-ee!pc-ecn!sandersr Let's make like a BSD process, and go FORK-OFF !! -- bob (and "make" a few children while we're at it ...)
gemini@homxb.UUCP (Rick Richardson) (08/01/86)
> All this talk about 19200 bu problems. (tisk, tisk) I *KNOW* for a fact > that IBM PC at 4.77 MHz using a standard CGA can emulate a full VT102 at > 19200 baud. I am doing it right now!! I have measured the line, and > sure enough, it is throughputting at 19200. I use Mark Of The Unicorn's > PC/InterComm program on the PC end, and a direct port to a DH unit on a > VAX. It will and does run 19200 baud. The screen does not flicker, and > you should even see Kermit zip along. Anyway, EMACS, VI and even RN run > perfectly fine; I have never had any of the problems. The termcap that > I use is the "dt80", with the SO and SE characters changed to show bright > (the PC goes blue when it gets a \E[4h ); the termcap includes *NO* pad > characters. Note the the "dt80" termcap is identical to the "vt100-np" > termcap without the initialization sequence for setting the tab stops. > - bob > Continuing Engineering Education Telecommunications > Purdue University ...!ihnp4!pur-ee!pc-ecn!sandersr The talk is about 19200 *without ANY flow control*. There is no way an IBM PC can do 19200 *and* use software scrolling. The scroll operation takes much too long; you have to be able to block move 4k bytes in <500usec or 122nsec/byte! An 8088 takes ~2usec/byte. Check this by sending *a long series newlines* and watch the line for XON/XOFF or RTS/CTS handshaking. If none occur, then PC/InterComm is really doing 19200, and must be using hardware scroll. Else, it's just doing a good job with the average 19200 case, which is not what the original poster was looking for. Or, it's just trashing some of the newlines, and you probably won't notice! Better test: send "a<newline> b<newline> c<newline> ..." repeated for several minutes. Watch the screen to make sure everything gets displayed, and watch the line monitor for flow control. Rick Richardson, PC Research, Inc. (201) 922-1134, (201) 834-1378 @ AT&T-CP ..!ihnp4!castor!{rer,pcrat!rer} <--Replies to here, not to homxb!gemini, please.
page@ulowell.UUCP (Bob Page) (08/02/86)
mazlack@ernie.Berkeley.EDU.UUCP (Lawrence J. Mazlack) wrote in article <15071@ucbvax.BERKELEY.EDU>: >Bob: > >Could you send me an exact list of hardware/software that I would need to >do this. I could then explore doing it with my purchasing people. (My >micro choice is a Mac - hardly a cost effective way of achieving a 19200 >baud terminal.) OK, the EXACT list of hardware/software is: 1. Amiga A-1000 CPU Box, 2. Any monitor (the Amiga produces RGB I, RGB Analog, and Composite), 3. Amigaterm terminal program, 4. A link to your other 19.2 end (I assume you already have this). Assuming you buy a cheap b/w composite monitor (sorta like going to Sears to buy $15 tires for your Ferrari :-), the Amiga will go for about $1000, depending on your dealer (they're $1295 list). Like I said before, I haven't seen Amigaterm in the stores yet; mine's a 'demo' copy. If it retailed for >$150 I'd be VERY surprised. Good luck with your marketing people. ..Bob PS Again, no connection with Commodore or Amiga-Commodore.
elg@usl.UUCP (Eric Lee Green) (08/04/86)
In article <15071@ucbvax.BERKELEY.EDU> mazlack@ernie.Berkeley.EDU.UUCP (Lawrence J. Mazlack) writes: >In article <604@ulowell.UUCP> page@ulowell.UUCP (Bob Page) writes: >>Since you're thinking about going micro-based, check out the Amiga. >>text/background, and it works great at 19200! Of course, you can >>still multitask all you want (recalculate your spreadsheet while you >>download a file, etc). Nice to have a window-based system. >>..Bob >>UUCP: wanginst!ulowell!page Bob Page, U of Lowell CS Dept > >Could you send me an exact list of hardware/software that I would need to >do this. I could then explore doing it with my purchasing people. (My >micro choice is a Mac - hardly a cost effective way of achieving a 19200 >baud terminal.) A Macintosh won't run at 19200 baud. To scroll the screen, it needs to move 32K of RAM. I would estimate it takes at least 20 clock cycles per word to move it, which would be roughly 320,000 clock cycles for the whole thing. That's only 25 newlines per second that would be allowed before the terminal started falling behind... lines would need to average over 77 characters to not lose text at 19200 baud. Obviously, a Macintosh would simply not work as a 19200 baud terminal... simply too slow due to insufficient hardware support for high-speed bit moves. Hmm, the Amiga blitter would take 32,000 cycles, which is 250 newlines per second that would be allowed... adequate, perhaps, you would still fall behind on lots of under-8-character lines. An Amiga with educational discounts sells for about $1600 full-blown, still too expensive, but it's kinda like a SUN for poor people... The 8Mhz. PC-clone would take about about the same amount of time to scroll 2000 bytes, using the CPU to do the data movement. As someone pointed out, if your CRT controller supports scrolling, a scroll is only about 200 cycles of tightly hewn assembly code (clear the new bottom line, move the pointers, presto)... but PC-Kermit would almost certainly use the BIOS routines, which probably don't take advantage of any such features. A PC-drone with Hercules card and monitor would probably cost around $1200... inexpensive, but cheap. By the way, method of calculation: newlines_per_second = 8,000,000/newline_cycles (8Mhz = clock cycles per second) minimum_line_length = 1920/newlines_per_second minimum_line_length is minimum average line length necessary to not fall behind due to newline scrolling speed. 1920 is of course characters per second. None of the mentioned computers should have too much problem with just placing characters upon the screen matrix -- it'd take pretty much to eat up 4166 clock cycles unless the terminal program was written in interpretive BASIC :-). This inner loop would probably need to be in machine language. Most PC "C" compilers I have seen are memory hogs that produce awful code. Terminal commands, however, would definitely be a speed problem... some fairly heavy padding may be needed for deleting and inserting lines, which on the average require moving half the screen. Geez, one sure can get carried away with a calculator! -- If I am elected no one will ever have to do their laundry again! (YOW!) -- -- Computing from the Bayous, -- Eric Green {akgua,ut-sally}!usl!elg (Snail Mail P.O. Box 92191, Lafayette, LA 70509)
wcs@ho95e.UUCP (#Bill_Stewart) (08/07/86)
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
mouse@mcgill-vision.UUCP (08/08/86)
In article <839@usl.UUCP>, elg@usl.UUCP (Eric Lee Green) writes: > In article <71@winfree.UUCP> bdale@winfree.UUCP (Bdale Garbee) writes: >> The problem we ran into was specifically with inverse video and >> underlining, in that we seemed to always get a "space" added in >> before and after each line segment that was in a different mode. We >> were running Gosling's Emacs, and had access to sources. I don't >> think it was the software's fault, > We have a terminal room of TVI910 terminals, which are functionally > similiar to the Wyse 50. When using Gosling Emacs, we would have the > same problem as mentioned above ("spaces" in mode lines). We solved > the problem simply: by deleting Gosling Emacs off of disk, and > replacing it with GNU Emacs 17.56. Problem solved. Q.E.D. > Definitely a software problem and not a problem with the terminal. I am *fed* *up* with all these postings claiming that this problem is due to this or that, for they all miss something! It is really three things put together: 1- TVI was silly enough to build a magic-cookie terminal, 2- There's no magic-cookie support in Gosmacs, and 3- Someone hacked out a TVI termcap entry carelessly. The simplest way to fix it is to clean up the tvi termcap entry. Get rid of the silly \EG so and se strings and use \E( and \E) (bright and dim). Provided you never use protect mode, which is inappropriate for Emacs anyway, this works fine (it's what we're using). Replacing with GNUmacs is a much more drastic solution. We have not taken that route because there was no documentation on GNUmacs lisp and the MockLisp converter broke on our local extensions to MLisp (we have source and I have extended Gosmacs a good deal). Absent the GNUmacs lisp documentation there were just two choices: rewrite it all from scratch (which would have been difficult without the docs) or forget GNUmacs. We chose the latter. I'm not sorry, especially considering how bizarre the keybindings of GNUmacs are to someone used to Gosmacs (I mean, really, help on backspace?! Pause on scroll-one-line-up?!). -- der Mouse USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse think!mosart!mcgill-vision!mouse Europe: mcvax!decvax!utcsri!mcgill-vision!mouse ARPAnet: utcsri!mcgill-vision!mouse@uw-beaver.arpa "Come with me a few minutes, mortal, and we shall talk." - Thanatos (Piers Anthony's Bearing an Hourglass)
randy@chinet.UUCP (randy) (08/08/86)
In article <773@ho95e.UUCP> wcs@ho95e.UUCP (Bill Stewart 1-201-949-0705 ihnp4!ho95c!wcs HO 2G202) writes: >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. My main problem with buffered flow control term programs is this. When you do a ls, or a cat of a large file and are looking for a particular line. A couple of screenfulls go by, and you see what you want to peruse. Hit the ctrl s and watch 6 more buffered screens go by! Same thing with the intr char. I wish the comm programs would give the option of doing *no* buffering. Then keyboard commands would be a little more interactive. -- .. that's the biz, sweetheart... Randy Suess chinet - Public Access UN*X (312) 545 7535 (h) (312) 283 0559 (system) ..!ihnp4!chinet!randy
tainter@ihlpg.UUCP (Tainter) (08/08/86)
> 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 Terak 8510 micros use just such a scheme. Have you ever seen a 19.2 soft scrolling screen? Fun stuff for bursty material. --j.a.tainter For those what don't know: Soft scrolling is when the display moves 1 pixal row at a time to scroll your display. The Terak 8510 is an LSI-11 graphics micro (10 years old--much better than an IBM PC, but too expensive to manufacture).
sandersr@ecn-pc.UUCP (Robert C Sanders) (08/12/86)
In article <475@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP writes: >In article <839@usl.UUCP>, elg@usl.UUCP (Eric Lee Green) writes: >> In article <71@winfree.UUCP> bdale@winfree.UUCP (Bdale Garbee) writes: >>> The problem we ran into was specifically with inverse video and >>> underlining, in that we seemed to always get a "space" added in >>> before and after each line segment that was in a different mode. We >>> were running Gosling's Emacs, and had access to sources. I don't >>> think it was the software's fault, >> We have a terminal room of TVI910 terminals, which are functionally >> similiar to the Wyse 50. When using Gosling Emacs, we would have the >> same problem as mentioned above ("spaces" in mode lines). We solved >> the problem simply: by deleting Gosling Emacs off of disk, and >> replacing it with GNU Emacs 17.56. Problem solved. Q.E.D. >> Definitely a software problem and not a problem with the terminal. >I am *fed* *up* with all these postings claiming that this problem is >due to this or that, for they all miss something! It is really three >things put together: >1- TVI was silly enough to build a magic-cookie terminal, >2- There's no magic-cookie support in Gosmacs, and >3- Someone hacked out a TVI termcap entry carelessly. >The simplest way to fix it is to clean up the tvi termcap entry. Get >rid of the silly \EG so and se strings and use \E( and \E) (bright and >dim). Provided you never use protect mode, which is inappropriate for >Emacs anyway, this works fine (it's what we're using). This is wrong way to adjust the termcap entry, and screws-up the termcap even further. You should read the manual (termcap(5)), and look at the following: TERMCAP(5) UNIX Programmer's Manual TERMCAP(5) NAME termcap - terminal capability data base SYNOPSIS /etc/termcap [ a lot deleted ...] CAPABILITIES (P) indicates padding may be specified (P*) indicates that padding may be based on no. lines affected Name Type Pad? Description [ a lot deleted ...] ms bool Safe to move while in standout and underline mode se str End stand out mode sg num Number of blank chars left by so or se so str Begin stand out mode uc str Underscore one char and move past it ue str End underscore mode ug num Number of blank chars left by us or ue ul bool Terminal underlines even though it doesn't overstrike us str Start underscore mode xs bool Standout not erased by writing over it (HP 264?) Usually, for terminals that do not have underline, but have "bright" capability, the 'us' sequence sends the underline code; the "bright", "dim", "normal" given in the previous posting. GNUemacs programs around some the faults in the termlib by looking at the termcap for 'sg' and 'ug', and corrects for it. We here at Purdue's ECN have many, many Lear Siegler ADM5 terminals, which are brain-damaged the same way at the TVI (or my TEC at home) -- they all leave a space for the "\EG" standout/standend sequence. You have to look for this, and display the inversed string one position earlier, and start the next one also one space earlier. Therefore, IT IS A FUNCTION OF THE SOFTWARE TO LOOK FOR THIS TERMCAP ENTRY AND CORRECT FOR IT!! Also, look at the termcap for your TVI: does it have the 'sg#1' entry? Ours does, and VI and EMACS run fine. - bob -- Continuing Engineering Education Telecommunications Purdue University ...!ihnp4!pur-ee!pc-ecn!sandersr Let's make like a BSD process, and go FORK-OFF !! -- bob (and "make" a few children while we're at it ...)