Vintage Terminals and scrolling behaviors

I recall the VT220s I used to use at work had a smooth scroll option, which looked better aesthetically but I found too slow to work with. There is the ‘change blindness’ phenomenon which makes it advisable to make larger changes especially if you can change the part the person is looking at.

But I think perhaps on the Tek 4014 type of terminal, you pretty much had to keep clearing the screen and then repainting, although you could get a fair amount of text on (maybe even two columns?) So it was workable to use a terminal with a paged mode of repaint.

1 Like

VT100s have this, too. It is hands down the thing that impresses visitors to my office museum the most – not the PDP-11 itself, not the concept of terminals and timesharing, not the Osborne 1, not the other 80s micros, not even the luggage-sized 5 MB RL01 disk drive – that sweet, sweet high framerate smooth scrolling. I normally turn it off because makes things like long listings too slow (it is much slower than even the 9600 bps limitation of my PDP-11 interface cards), but it is very aesthetically satisfying.

3 Likes

Yes, the Tek 4000-series terminals used storage CRTs, where the painted image was maintained by an electrostatic field on the CRT itself. This made “erasing” individual pixels (line strokes, in actuality) impossible; temporary strokes could be painted to the screen which required refresh (much like a normal CRT), but the Tek itself was not capable of maintaining that refresh, so the controlling computer had to continually send those objects to the screen. Ordinary drawing was drawn through to the electrostatic layer (essentially by sending a higher energy beam), and could only be erased by erasing the entire screen at once.

The firmware in the 4000 series terminals mitigated this by automatically line-wrapping to the center at the top of the screen once reaching the bottom of the screen, giving two-column output. The first column was only about 35 characters wide, so this was less than ideal for wide text, but for something like a simple 6.3 file listing along the left column of the screen, it gave you an additional “screen full” of text on display for free.

I have restoring a 4012 on my TODO, hopefully I can get to it during this quarantine and provide some illustration for this concept. :wink:

3 Likes

Oh yeah - the first time I saw a VT terminal smooth scroll, I fell in love with it. It sure has a huge WOW factor, and it makes life a lot more pleasant at typical BAUD rates of the day.

That was a big deciding factor for me when deciding what Amiga term emulator to use. Once I got used to smooth scrolling, I couldn’t go back.

Now - as for what the heck scrolls by so fast … the thing is, MAN and MORE will naturally stop at each page anyway. But some sort of recursive CP or RSYNC, or even a plain old directory listing might zoom by … maybe not at maximum baud rate, but the Apple doesn’t get to pick and chose when to receive each byte. So your program needs to at least poll the input as if at the max rate since you never know when the data will come in.

With something like RSYNC, I definitely prefer to NOT hit SPACE every page just to see the mostly same boring stuff scroll by. But I can usually catch something that looks oddly out of place as it zips by. Scrolling a page at a time might actually help with that. Hmm … could be a useful little (non-retrocomputing) utility to pipe output through …

This behavior didn’t carry over to the Tek 4051 computer. As I recall, it worked “just like normal” when I programmed it in BASIC.

We had 1 or 2 or these in the “Math Lab” in college that nobody used (they also had a Terak there). And they took a particular tape cartridge for storage. It was not an uncommon tape cartridge, but you weren’t going to find it at your local radio shack.

But I used it to dabble with 3D graphics. I wrote all the code in BASIC, had a wire frame car model that my friend helped me key in (wasn’t that big, maybe 100 vertexes). And then I could just zoom, shift, rotate, etc. I got all the math from a BYTE magazine article on 3D graphics. I will say that the lines on the Battlestar Galactica era Tektronix machine made my 3D models look much better than what I could do on a PET 2001. They were just wireframes, no hidden line removal or anything.

But, from a coding experience, it managed to scroll just fine. I don’t remember having to page code or anything. I know I had to constantly clear the screen to re-render the models, but I guess the refresh was fast enough during coding that it wasn’t an issue.

It’s hard to imagine what the experience would be like today running on a storage tube with a 1MHz 6800 based machine running BASIC.

If the output is important, just tee(1) it to safety while watching it.

Even the 4010/4012/4014 could do some really amazing real-time-ish stuff with the appropriate devices plugged into their backplane. The drawing circuitry was actually very fast; I don’t remember the exact bandwidth, but I figured it from the technical documentation, and it was something like half a megabyte per second, and each line took only a couple of bytes. You could push some really fancy graphics at very high rates directly to the backplane. The problem is that the connection to an outside computing device was via an I/O module, and the rates on those modules were much more limited.

The logic inside the stock 4010/4012 is very limited in its capability. The 4014 has some more sophisticated capabilities (although I’m not sure exactly what, I don’t have one) and there were some expansion boards that provided more capabilities for the 4010/4012. However, most of the standard interface options were pretty slow (my 4010/4012 modules all top out at 9600 bps), and I don’t know of an option that could persist more than a very small number of objects for any of these models. The later models, including the computer all-in-one models like that 4051, could do much more impressive things since they had directly-connected storage and I/O at high bandwidth.

I actually want to clarify that I don’t think this was actually done in firmware, as as far as I can tell those terminals have no firmware per se. It was, rather, done in logic.

Right. That was my core concept: ensure you never lose data, all data is sent to the display routines (so you don’t mess up screen or printer control codes or anything like that that they may be processing), and scrolling/display is done as well as reasonably possible in the time remaining, which may mean scrolling multiple lines in one go if you have more than one line of data buffered and waiting to display. I don’t think it needs to get any more complex than that.

Actually, according to the VT100 Technical Manual (EK-VT-TM-002), this required the advanced video option, in order to set attributes. The description of the scrolling mechanism reminds somewhat of early arcade video games (counter chains, and so on).

Here are the relevant snippets from the Technical Manual:

Interesting … my VT100 (which does not have the advanced video option, as far as I know, because it can’t do 132 column) has smooth scrolling. My VT105s do, too, but they do have the advanced video option (as I believe they all do). Perhaps a change in later revisions?

The first VT100 I saw did have the smooth scrolling. And I had the same positive reaction as you other guys. And yes, it was too slow to use in practice… but it was beautiful. I have no idea what options our terminals had, but this must have been in the early eighties, maybe '82. Maybe all VT100 terminals had that option by then? I don’t think I have ever run into a VT100 without the smooth scroll.

1 Like

That’s prompted a not very useful memory, that at university I used VT100s. I believe we had a screen editor - surely we must have - and in that case it’s the redraw speed as much as the scrolling which is helped by a fast connection.

I’m not sure I’ve ever used a VT52, but here it is anyway:

I know the BBC Micro’s VDU subsystem offers scrolling within a defined text window - is that also present in DEC’s offerings?

Maybe, this was only required for distinct scroll regions, but not for scrolling the screen in it’s entirety? The Technical Manual isn’t that clear on this. Also, it’s the second revision of that manual.

Yea, it was gorgeous, but we always turned it off. I wonder what the effective transfer rate was when it was turned on.

At our school, the terminals were all 1200 baud, and we used screen editors. Save for 4 terminals in the downstairs lab that Just So Happened to be next to the computer room. Those were 2400 baud (likely because the wire run was so short to the computer room).

We certainly enjoyed those terminals, but the speed alone wasn’t worth us striving to use them. We were pretty content to hang out in most any of the labs and work.

Upstairs, there was a printing terminal that had decent letter quality (I wouldn’t say it was “letter quality” as a term of art for dot matrix printers, but it’s letter quality was better than the standard Datasouth printer we had in the labs). For some reason this terminal was 110 Baud.

But I’d use it anyway to print english papers. It had plain, letter size paper.