Timeline for Was 1991's Hellcats the first instance of incremental screen updates?
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 25, 2018 at 20:18 | comment | added | Raffzahn | So, bottom line, much like the mentioned screen updata, except it was about text and terminals and worked both ways, for input as well as for output. Thinking of it, it might be more useful to move this into a question about how block mode terminals worked, as there are way more details than even a dozend comment entries can handle. | |
| Oct 25, 2018 at 20:17 | comment | added | Raffzahn | On the host side the application ofc needs the whole record send back, so here a virtual image of what has been send out is used and filled with whatever fields have been changed before being handed to the application. Similar, for the next output toward the terminal the screen handler checks if the same form is used again. If not, the whole screen is send out. If it's the same screen layout, then the message to be outputed is compared with the saved image, and only differences are send out - again using field addresses to only output what's different. | |
| Oct 25, 2018 at 20:12 | comment | added | Raffzahn | Well, @MauryMarkowitz, I'd like to say 'all of the above' :)) A screen is defined as a background with the attributes non non-changeable, non-field. It can contain text, which is only send out the first time. 'Atop' are fields, defined. They again can be user changable or not. When a screen gets sendback to the host, only the field get returned. That's default field mode. Some terminals now offer a changed field mode, where only fieds that got changed by the userwill be send back. To identify them, they area packed in a variable length format where each field is prefixed with an ID. | |
| Oct 25, 2018 at 19:04 | comment | added | Maury Markowitz | Ok but more generally, in your example, were the changes noticed because it kept two complete screen buffers and compared them to see the changes? Or did it record the changes as they were made by writing down the location and then sending the commands needed to produce that? I realize this may be splitting hairs, and the terminology confusion adds to this. However, @dave example does seem to be precisely the same concept as Hellcarts | |
| Oct 25, 2018 at 19:00 | comment | added | Raffzahn | Outch, @MauryMarkowitz, that would be a lengthy issue. Even more so as there are many different variations depending on manufacturer and model, beside the basic block mode ways. Block mode in it's most basic functionality means the host sends out a whole screen with field definitions for what parts are can be changed or not. Editing no happenes locally with the terminal controlling all cursor movement and so on. When done, the result gets send back. At that point it depends on what mode (and terminal) is used. ... and that is not only of interest to you, but requires way more than a comment. | |
| Oct 25, 2018 at 18:47 | comment | added | Maury Markowitz | But are these form-filling systems really diffing anything, or simply recording the changes? There's a difference between "user typed in field 10" and "look at entire display to see it was in 10". I guess I'm asking about the precise implementation, how did the block-mode terminals actually work? | |
| S Oct 25, 2018 at 11:02 | history | edited | Raffzahn | CC BY-SA 4.0 |
typos, clarification
|
| S Oct 25, 2018 at 11:02 | history | suggested | kubanczyk | CC BY-SA 4.0 |
typos, clarification
|
| Oct 25, 2018 at 10:57 | review | Suggested edits | |||
| S Oct 25, 2018 at 11:02 | |||||
| Oct 24, 2018 at 22:43 | comment | added | dave | I concur. I wrote a few "full screen text" programs in the mid 1970s that only sent the differences to the asynch terminal (my critical test case was 300 bps dialup), determined by keeping 24x80 buffers and comparing them. I did not feel like I was inventing anything new. | |
| Oct 24, 2018 at 17:10 | history | answered | Raffzahn | CC BY-SA 4.0 |