1. Forum
  2. Usenet
  3. COMP.SYS.APPLE2.PROGRAMME

  • A solution to PRINTing to bottom-right corner of text screen problem

    From [email protected]@21:1/5 to All on Fri May 14 01:59:31 2021
    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? :-)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeff Blakeney@21:1/5 to [email protected] on Fri May 14 07:07:31 2021
    On 2021-05-14 4:59 a.m., [email protected] 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. :)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [email protected]@21:1/5 to Jeff Blakeney on Fri May 14 21:33:56 2021
    On Friday, May 14, 2021 at 6:07:34 AM UTC-5, Jeff Blakeney wrote:
    On 2021-05-14 4:59 a.m., [email protected] 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From mykel@21:1/5 to All on Mon Aug 16 02:23:17 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [email protected]@21:1/5 to mykel on Wed Aug 18 23:06:54 2021
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From mykel@21:1/5 to [email protected] on Fri Aug 20 06:12:47 2021
    On Wed, 18 Aug 2021 23:06:54 -0700, [email protected] 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)