Classic Computer Magazine Archive COMPUTE! ISSUE 76 / SEPTEMBER 1986 / PAGE 10

Reader's Feedback

The Editors and Readers of COMPUTE!

If you have any questions, comments, or suggestions you would like to see addressed in this column, write to "Readers' Feedback," COMPUTE!, P.O. Box 5406, Greensboro, NC 27403. Due to the volume of mail we receive, we regret that we cannot provide personal answers to technical questions.


Apple HTAB In 80 Columns

I have an Apple IIe with an extended 80-column card. I found out recently that the Applesoft BASIC HTAB command does not work properly. When I type the following line in 80-column mode, I get an incorrect result:

HTAB 20:PRINT "THIS IS A TEST";:HTAB 1:PRINT "A"

The computer prints this line preceded by 19 spaces:

THIS IS A TESTA

Memory location 36 is supposed to contain the horizontal cursor position, but in 80-column mode, it always contains 0. The BASIC function POS(0) doesn't work either. How can I determine the current cursor position?

William Liao

Many older Apple II programs, especially those written in machine language, print to the screen by adding the horizontal cursor position (CH, location 36) to the address of the first character in the current row (BASL and BASH, locations 40 and 41), then storing a character at the address that results. When 80-column hardware is in use, this technique could scramble the Apple's memory, since the organization of 80-column screen memory is different.

As a precaution, whenever the Apple's I/O software accesses the 80-column screen to move the cursor or print, it resets CH to 0. This is why PEEK(36) and POS(0) no longer work. In IIe and IIc computers, the 80-column cursor position is kept in location 1403, called OURCH. (If you're familiar with the Apple II's memory arrangement, you'll remember that addresses between 1024 and 2047 are reserved for screen display memory. Since the 40-column screen is 40 X 24, that's a total of 960 bytes that are actually used. The 64 unused bytes are called screen holes and are used to store I/O variables. OURCH is one of these.)

The HTAB command changes the cursor's position by storing a new value in location 36. To keep this command operational, the enhanced I/O routines keep a copy of CH in another screen hole, location 1147 (OLDCH). Before each screen access, CH and OLDCH are compared. If they are different, CH must have been changed, so its value is made the current position by storing it in OURCH. The only time this doesn't work is when 80-column mode is active. Since CH and OLDCH are both set to zero at each screen access, an HTAB 1 command stores zero in CH, and there's no way to tell that anything happened. Since CH and OLDCH still contain the same value, OURCH is not altered.

One simple way to move the current screen position to the first column is to use a lone PRINT statement. All it does is move the cursor to the first column of the next line without disturbing the display at all. Another way to be certain of the cursor's position in any display mode is to POKE the new column value (0-79) into both CH and OURCH. In standard display mode (40 columns, checkerboard cursor), OURCH is not used; POKEing a value there doesn't seem to have any undesirable side effects.

When the enhanced I/O firmware is active (block cursor in 40 or 80 columns), you can find the current cursor column with PEEK(1403). To find the current column regardless of display mode, PEEK the value in CH. Then, if it has a value of zero, PEEK at 1403. This should always give the correct position.