I just figured out how to PRINT a character to the bottom-right corner of the text screen without triggering a screen scroll. You can temporarily set locations 33($21 WNDWDTH) or 35($23 WNDBTM) to a value beyond the visible screen area, and then you can PRINT all the way to the end on the bottom line. Once the cursor is outside the visible screen area, don't PRINT anything else until you position the cursor back within the visible screen area again, and make sure you restore the original values back to those zero page locations. Here are some examples.

Using WNDWDTH - Must use ";" at end of PRINT statement.
POKE 33,41: VTAB 24: HTAB 40: ?"@";: POKE 33,40: VTAB 20

Using WNDBTM - If using semi-colon at the end of PRINT:
POKE 35,25: VTAB 24: HTAB 40: ?"0";: POKE 35,24: VTAB 20

Using WNDBTM - If not using semi-colon at the end of PRINT:
POKE 35,26: VTAB 24: HTAB 40: ?"1" : POKE 35,24: VTAB 20

CHR$(8) followed by a semi-colon ";" can be used to move the cursor back into visible screen area, as shown in the next examples. Note that I did not set the HTAB position at the end of my code because the system automatically issues a CR (which resets HTAB to 1) and then displays the command prompt "]".
Using WNDWDTH
POKE 33,41: VTAB 24: HTAB 40: ?"A";CHR$(8);"Z";: POKE 33,40: VTAB 20

Using WNDBTM
POKE 35,25: VTAB 24: HTAB 40: ?"0";CHR$(8);"9";: POKE 35,24: VTAB 20

So is this technique new to you guys or did I just solve an age-old screen PRINTing problem? :-)

On 2021-05-14 4:59 a.m., eri...@gmail.com wrote:
> So is this technique new to you guys or did I just solve an age-old
> screen PRINTing problem? :-)
If I've ever run into this issue in the past, I think I would have just
POKE'd the last character on the screen. A little less typing and a
little less code in my program. :)

On Friday, May 14, 2021 at 6:07:34 AM UTC-5, Jeff Blakeney wrote:
> On 2021-05-14 4:59 a.m., eri...@gmail.com wrote:
> > So is this technique new to you guys or did I just solve an age-old
> > screen PRINTing problem? :-)
> If I've ever run into this issue in the past, I think I would have just
> POKE'd the last character on the screen. A little less typing and a
> little less code in my program. :)
True. And that's probably what I would have resorted to as well. But it has been a slight annoyance not being able to just use the PRINT statement to output ALL my text to the screen. If you wanted to put different strings down there at different times, each time you'd have to PRINT your string minus the last character, then POKE in that last character. And if you wanted to PRINT a number variable down there, you have to jump through even more hoops. You could POKE the entire string's ASCII in, but then you're dealing with the added complexity of dealing with loops and POKEing the ASCII values of each character in the string. Although it does work, it's not very flexible, especially if you're using some of the same text in more areas of the screen than just the bottom-right.

Now that I think about it, adjusting the WNDBTM would be a better approach than adjusting the WNDWDTH. This way no screen holes are written into, plus nothing bleeds over to another part of the screen on the left side if any screen wrapping occurs, which includes the CLREOL (clear to end of line) monitor routine that's called every time the user presses Return from an INPUT statement or at the command prompt.

If you're putting stuff all over the screen for printing and clearing menus and stuff, you're already proactively positioning the cursor within the viewing screen. So I guess really, the only thing out of the ordinary you'd have to do is POKE once to WNDBTM beforehand. Once you're done and ready for the screen to be able to scroll again, return the original value back to that location or issue a TEXT statement (which resets all the window values without triggering a screen scroll). Of course if you're in mixed screen graphics and want to stay there, you'll want to go the POKE route to restore WNDBTM and not use TEXT.

So then, my cleaned up procedure would be:
1. POKE 35,26 (no semicolons needed with PRINT)
2. Position and PRINT to draw or clear all the text you need
3. TEXT or POKE 35,24 when you're all done and ready to scroll again

Example:
10 POKE 35,26
20 A$="TEST": B$="COMPLETE"
30 VTAB 24: HTAB 37: ?A$: GET PAUSE$
40 VTAB 24: HTAB 33: ?B$
50 TEXT: VTAB 8
HOME:LIST:RUN

If you could locate the variety of DOS 3.3 samples, program sources or
similar from back in the days, , you will find any number of screen
techniques. Some are quite useful.

On Wed, 18 Aug 2021 23:06:54 -0700, eri...@gmail.com wrote:

> On Sunday, August 15, 2021 at 9:23:18 PM UTC-5, mykel wrote:
>> If you could locate the variety of DOS 3.3 samples, program sources or
>> similar from back in the days, , you will find any number of screen
>> techniques. Some are quite useful.
>
> Do you remember anything more about some of them? Like software names,
> disk names, file names, article names, magazine names?

Not offhand. However, I can recommend Nibble disks and articles,
especially the earlier magazines.

If you have the Nibble CD then look in their early production years.

Sorry I can't offer more help. If I run across something, I will pass it
on.

When Apple released the first 2c there was an interesting set of
utilities for it. To make this early version of tools function in
different video modes, including hires video, they use the redeye.hook
and redeye.pro routines. I have never found them anywhere else. Quite
useful, but maybe uses too much memory.

Cheers