In and out of windows

[xlar54]

If a window is established on the 128, all normal printing occurs within it. To get out of the window, poke to location 235 as in:

110 WINDOW 0,19,39,20
120 PRINT"IN WINDOW" : GETKEYA$
130 POKE 235,1: PRINT
140 PRINT"OUT OF WINDOW": GETKEY A$
150 POKE 235,10: PRINT
160 PRINT"INSIDE AGAIN"

paraphrased from an old RUN magazine issue

[airship]

Except it doesn't simply 'print outside the window.'

Try it with a variety of window sizes and poke values and see what happens.

Zero page location 235 holds the cursor row location for the current window. But this value is relative to the screen, not the window. Setting it to one sets the row equal to the second row of the screen (since they number from zero, natch). The edge and bottom settings stay the same. So the poke in the program actually starts printing in the current window, but starting at whatever row number you poke, which may or may not be outside the designated window borders. In your example, the top row of the window is set at 19, so poking a 1 moves the current row outside the window. The window margins and bottom row settings stay the same, however, and if you print enough stuff the window will scroll inside its preset borders.

Back to xlar's program: the 'OUT OF WINDOW' message will be printed at whatever column is still indicated in location 236, so if the previous print statement had ended in a semicolon, it would not print at the window's left margin, but at wherever the previous print statement had stopped. The program uses a print statement after the poke to ensure the next print starts on a new line.

You can use 'poke 235' to start printing at any row, either inside or above the window. DO NOT poke a value that is less than the bottom row of the window!! Your screen will make a quick trip to hell. It will, however, come back if you poke a new legal value in there.

A similar poke to 236 will NOT let you reliably specify which column in which to start printing, because the print routine will apparently print one character there in the current row, then reset it all according to some other value elsewhere. (PLOT can, of course, be used to set both row and column reliably anywhere within the current window.)

There are three interacting values involved in printing in a window:

The WINDOW statement parameters that define the window in the first place, which are in this order:
left column, top row, right column, bottom row
These can, of course, also be set by the [esc]T and [esc]B editor commands, which set them according to the current cursor position.

The actual window margin values reside in these zero page locations:
228  bottom row
229  top row
230  left column
231  right column
Note that Commodore, in their infinite wisdom, defines these values in a different order in the WINDOW command than the order in which they are stored in memory.

Also relevant are the current and max locations in zero page:
235  cursor row
236  cursor column
237  max screen rows
238  max screen columns

The program above messes with the cursor row value. I've also indicated that the cursor column value can be manipulated, but it doesn't reliably do anything for you.

Leave locations 237 and 238 alone. They are set to '24' and '79' by the startup routines and you really don't want to tell the C128 it has a bigger or smaller screen than it actually does.

[Edwing]

Seconding airship, I also find the "practices" quoted by xlar54 questionable ... albeit for different reasons. (Actually, airship's are better ;ö)

Personally I prefer not to use POKEs unnecessarily. Thus, why not leaving a window by

Code Select Expand

?"<home><home>";
and re-establishing it via the appropiate WINDOW command?

I don't think a WINDOW is slower than a POKE (at least not significantly measured by BASIC time dimensions ;ö). If you don't like inserting a lot of the same WINDOWs into your program, you could have GOSUBs to one (if speed is not critical). For resuming print in the same position inside the window, the old co-ordinates could be PEEKed or LINed or something and later used by the WINDOW command.

I know, it's not as sexy as jumping in and out with a single POKE ... but as airship explained, that method isn't working cleanly.

BTW,

Leave locations 237 and 238 alone. They are set to '24' and '79' by the startup routines and you really don't want to tell the C128 it has a bigger or smaller screen than it actually does.

...well, at least not unintentionally. Changing these is justified if you set the VDC to a different screen size and want the editor to use all of that (or, not more than that e.g. for a 40x25 double width screen).
It also makes sense to use these for protecting a status line on bottom of the screen from user activity, e.g. for a utility in direct mode - how quickly does the user press <Home> twice when meaning to press it once ...
Actually, one could also think of using these for a "virtual screen" bigger than what's displayed ... under program control the user could scroll the screen "window" through that, pretty much as with C64 word processors or CP/M in 40 columns - or indeed GUIs like that of Windows.

Regards,
Edwing :ö)

[BigDumbDinosaur]

It also makes sense to use these for protecting a status line on bottom of the screen from user activity, e.g. for a utility in direct mode - how quickly does the user press <Home> twice when meaning to press it once ...

Or you could use the 80 Column Display Manager to protect your status line, plus buffer screens.