hackerb9
commented
3 months ago 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
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:
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:
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
DECCRAsupport, 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.