What is Page Memory good for?

[j4james]

I saw you were recently asking for input on what page memory is good for, so I thought I'd offer my thoughts based on what I've read, and also how I've been using pages myself.

Data entry

Quoting the VT330/VT340 Programmer Reference Manual (Text Programming), in the section "What is page memory?", page 103:

Page memory lets you store more text locally in the terminal.
Page memory can provide a faster response time. While the terminal displays one page, the host can write to another.

They don't say this explicitly, but my guess is that this would typically have been used for data entry applications, likely combined with the block editing functionality.

For example, you may have terminals in offices around the country connected to a central database with customer data that you need to view and/or update remotely. If you've got a data entry form that spans multiple pages, you don't want to have to keep redrawing that every time you deal with a new customer.

So what you do is render the initial form design at startup (and this can cover multiple pages which are loaded in the background). Then looking up a new record just fills in the appropriate fields without having to redraw all of the surrounding content (and again, fields on the secondary pages can be loaded in the background).

If it's necessary to edit something, you'd typically use the block editing functionality to markup the editable areas of the page. And that way the user can enter the data locally, without a slow roundtrip connection to the central office for every keystroke. Once the form has been completely filled in, it can all be sent to the backend with a single write (possibly one write per page - I'm not overly familiar with the block editing functionality).

Pop-up dialog and menus

This requires additional extensions that were only available on the later VT models, so I don't think it would work on the VT340, but quoting the VT420 Programmer Reference Manual, page 7:

Page memory provides a storage space for pop-up menus and a means for instant screen updates.

Lets say you need to pop-up a dialog in an editor that's currently viewing a document. When you close that dialog, you ideally don't want to have to redraw the area of the screen that was temporarily covered. But if the terminal has rectangular area operations (specifically DECCRA), you can temporarily copy a portion of your active page to a secondary background page, and then copy that back again when the dialog is closed.

And with something like drop-down menus, which are likely to be frequently used, and where the content is known in advance, it can be advantageous to prerender them all to a background page. That way, opening a menu just involves a single copy operation, and flipping through menus can be almost instantaneous, even on a slow connection, and even when drawing over unknown content.

Double buffering and compositing

I doubt this was one of the original goals for DEC terminals, considering the typical target market would likely have been business users, but if you want to develop a terminal game, there are some cool things you can do with pages.

In the simplest form, if you're needing to animate a bunch of sprites, and you have to erase them all before redrawing them in a new location (potentially in a different form), it's preferable to do this compositing on a background page, and then flip that page to the foreground when you're done. Otherwise you're liable to get flickering from the time between erasing and redrawing.

And on later terminals that have DECCRA support, there is even more you can do with pages. For example, in a side-scrolling game, you can dedicate one page to the background, so it can easily be scrolled by itself every frame. You then copy that to another background page before you draw all the sprites on top of it. And finally you flip or copy that page to the foreground when you're done.

I recently made a version of the Chrome dinosaur game using this technique, and although it's a bit sluggish, it was actually playable on a VT525.

[hackerb9]

Thanks. I think all of that makes a lot of sense although I still don't get why you can have pages that are longer than the physical screen... oh wait, as I wrote that I realized you could have a very long form and have it nicely scroll to the next field (and back) instead of the sudden transition of flipping pages.

Is it okay if I use what you wrote to make a page on Page Memory? I'd love to see the code for your Chrome dinosaur game, and link to it from that page, if you feel like sharing it.

Am I correct that there was no terminal that had both sixel graphics and DECCRA? That would have been superb. The VT340 has enough graphics memory to write sixels to two different pages, but without a fast rectangular copy, I'm having a hard time coming up with a good excuse to use it. If I recall correctly, the VT340 graphics processors actually are capable of rectangle copies, but the firmware doesn't expose that interface to programmers.

[j4james]

First off, you're always welcome to use anything I contribute in these coments, and feel free to edit it as much as you want. Although I've just realised I forgot to mention that the block editing use case is specific to the VT330/VT340 - as far as I'm aware that was the last DEC terminal with that feature.

Regarding pages that are longer than the physical screen, it's worth noting that later terminals (VT420+) let you choose to squish the font when you change the page size so the full page can fit on the screen (at least up to 48 lines per page). This is similar to the way the VT340 lets you choose between horizontally panning over 132 columns, or using a narrow font that fits everything within the screen width.

And I think one of the main use cases for that panning functionality was for multiple sessions in a split screen. So if you're working with a "standard" 80x24 application, but you've only got half the screen available, you can pan the frame to see all of it. The VT420+ terminals only supported a top-bottom split, so only had up-down panning operations, but the VT340 supports both left-right and top-bottom splits, and can pan in both orientations.

Am I correct that there was no terminal that had both sixel graphics and DECCRA?

As far as I'm aware, yes. There are modern terminal emulators that support both, but I don't think I've ever tested how well they handle mixing sixel with rectangular area operations.

The VT340 has enough graphics memory to write sixels to two different pages, but without a fast rectangular copy, I'm having a hard time coming up with a good excuse to use it.

I had some ideas for a simple two frame animation that I thought might be practical. And with pages larger than the display, I think you might even be able to support more frames offscreen, and use panning to flip them into view (that's assuming the VT340 can write sixels across the full page size).

I'd love to see the code for your Chrome dinosaur game, and link to it from that page, if you feel like sharing it.

Sorry, I actually meant to link that. The repo is here: https://github.com/j4james/vtrex

[j4james]

Btw, here's my attempt at a two-frame sixel animation using pages. In case you don't recognise it, it's from the old Badger Badger Badger meme.

https://gist.github.com/j4james/ebb78e60df3a4f919e44bab9b9578feb

I haven't tried doing more frames with offscreen scrolling, because I got the impression from your past tests that it wouldn't work. For example, you said here that the image got cut off after 80 columns.

vt340test/sixeltests/offscreen.sh

Lines 76 to 77 in 12c45e8

	# Red square spans column 76 to 85 --- vt340 cuts of at column 80
	square 12 76 2

But when it comes to vertical panning, it sounds like it doesn't get cut off?

vt340test/sixeltests/offscreen.sh

Lines 79 to 80 in 12c45e8

	# Green square spans rows 23 to 27 --- vt340 scrolls rows 1 to 24 up
	square 23 35 3

So now I'm wondering whether you could actually have made the horizontal panning case work if you'd panned the viewport first, i.e. pan right as far as possible and draw and image on the far right of the screen, then pan back left as far as possible and draw an image on the far left. Would both of those images render successfully? And if so, could you pan back and forth to flip between them?

And even if the horizontal case doesn't work, could you do something similar with vertical panning? So pan down as far as possible (after you've enabled 72 lines per page) and draw an image at the bottom of the screen, then pan up as far as possible and draw an image at the top. Would both of those images render, and can you pan between them?