TARGET - Game Writer's Pack 1

[orion1052003]

I was wondering if anyone could write a breakdown of the program or the confusing bits. This is the first program from (TI home computer) GAME WRITER'S PACK 1, by Collins Microsoftware. The .pdf is at ernie's site, The TI-99/4A computer book archive. Great Site! The program is on page 83 of the book, page 84 of the document. This is a beginning game learning program, so I thought I would post it and perhaps start a discussion about the program and perhaps the book. Mainly to learn how to program.

 

What is happening in lines 520, 720, 560-570, and how can the main game loop from 350 - 670 still work when things are bouncing from one line to another? Like the print bullet, shooting, and plane drawing routines... Most of the lines I know how it works by the routine or line itself, but not how it comes together as a whole. That seems confusing.

20 REM  MACBRIDE 1983
30 CALL SCREEN(
40 CALL CLEAR
50 PRINT TAB(10);"TARGET": :
60 PRINT "  THIS SHOWS HOW A BULLET ": :
70 PRINT "  FIRING ROUTINE WORKS.": :
80 PRINT "  MOVE THE "GUN" USING ": :
90 PRINT "  >>S<< TO GO LEFT": :
100 PRINT "  >>D<< TO GO RIGHT.": :
110 PRINT "  PRESS >>F<< TO FIRE.": : :
120 PRINT "  THERE IS A PROGRAM INDEX ": :
130 PRINT "  AT THE END.": : :
140 PRINT "  PRESS ANY KEY TO BEGIN "
150 CALL SOUND(500,250,1)
160 CALL KEY(3,K,S)
170 IF S=0 THEN 160
180 CALL CLEAR
190 REM  graphics
200 CALL CHAR(128,"00003098FEFF1830")
210 REM  128 = flying plane
220 CALL CHAR(129,"1038383838002844")
230 REM  129 = bullet
240 CALL CHAR(130,"20646C38F80C0600")
250 REM  130 = falling plane
260 CALL CHAR(131,"10101010387C7C7C")
270 REM  131 = gun
280 GC=15
290 REM  Gun Column at start
300 F=0
310 REM   gun not firing f=0	 
320 BR=20
330 REM  Bullet Row at start
340 PRINT "    PRESS >>Q<< TO QUIT"
350 FOR TC=1 TO 32
360 CALL HCHAR(5,TC,128)
370 IF F=1 THEN 540
380 REM  key check			   
390 CALL KEY(3,K,S)
400 REM   quit ? asc(q)=81	   
410 IF K=81 THEN 800
420 REM   move gun ?			  asc(d)=68  asc(s)+83	   
430 IF(K=68)+(K=83)=0 THEN 480
440 CALL HCHAR(20,GC,32)
450 REM    "value of truth"		 for gun movement			   
460 GC=GC-(K=68)+(K=83)
470 REM    fire button				  asc(f)=70				   
480 IF K<>70 THEN 650
490 REM    fire !!			   
500 F=1
510 CALL SOUND(50,200,1,-8,1)
520 BC=GC
530 REM   check for hit		  
540 CALL GCHAR(BR,BC,Z)
550 REM   print bullet		   
560 CALL HCHAR(BR,BC,129)
570 CALL HCHAR(BR,BC,32)
580 IF Z=128 THEN 710
590 REM   change Bullet Row	  
600 BR=BR-3
610 IF BR>3 THEN 650
620 REM    reset bullet			    after miss			
630 BR=20
640 F=0
650 CALL HCHAR(5,TC,32)
660 CALL HCHAR(20,GC,131)
670 NEXT TC
680 GOTO 350
690 REM   crash routine		  
700 CALL HCHAR(5,TC,32)
710 FOR N=5 TO 20
720 X=(N-4)/2+(X>30)
730 CALL HCHAR(N,TC+X,130)
740 CALL SOUND(50,-6,1)
750 CALL HCHAR(N,TC+X,32)
760 NEXT N
770 INPUT " ANOTHER GO CRACKSHOT ?(Y/N)":A$
780 IF A$="Y" THEN 140
790 IF A$<>"N" THEN 770
800 CALL SCREEN(16)
810 CALL CLEAR
820 PRINT "	   PROGRAM INDEX": :
830 PRINT "  INSTRUCTIONS...........40": :
840 PRINT "  GRAPHICS DEFINITION...190": :
850 PRINT "  VARIABLES SET ........280": :
860 PRINT "  MAIN LOOP.........350-680": :
870 PRINT "  KEY CHECKS............380": :
880 PRINT "  GUN MOVEMENT..........440": :
890 PRINT "  BULLET ROUTINES.......490": :
900 PRINT "  CRASH!!...............690": : :

[TEXAS_JOE]

It's down to the IF statements. Basically, they are like a toggle switch, if Z=128 then goto certain line.

When I coded my Biplane game, inbetween a CALL KEY and IF STATUS =0 routine , there was a variable that checked

for if there was already a bomb dropping. If it found there was one, it increased the variable for the bomb position by 1 each time.

 

rough example;

 

100 CALL KEY(0,K,STATUS)

110 IF BD=1 then 2000

120 IF STATUS=0 then 100

130 IF K=32 then 200

140 GOTO 100

200 BD=1

2000 drop=drop+1::CALL CHAR(x,DROP,40)

2010 goto 100

 

Maybe someone can explain it a little better than I can.

[+Lee Stewart]

...

What is happening in lines 520, 720, 560-570, ... ?

 

520 BC=GC

This sets the bullet column to the current gun column before firing it so the bullet actually appears to be firing from the gun.

 

720 X=(N-4)/2+(X>30)

The way this program is written, the relational expression "X>30" is superfluous. It is always 0, i.e., false; and, hence, adds nothing to the equation---literally. X always takes values from 0.5 to 8 in increments of 0.5. It was probably intended to check for hitting the right side of the screen to avoid throwing an error with "CALL HCHAR". A clunky way to do this would be to eliminate X and increment TC by 0.5 for each pass, while testing the previous value of TC for last-column status with the relational expression. When it exceeds the next to last column, cancel the increment, which will cause the plane to fall straight down in the last column:

 

710 FOR N=5 TO 20
720 TC = TC + 0.5 +(TC>31)/2
730 CALL HCHAR(N,TC,130)
740 CALL SOUND(50,-6,1)
750 CALL HCHAR(N,TC,32)
760 NEXT N

When (TC>31) is true (-1), the value of TC calculated in the new line 720 will be 31.5 + 0.5 -0.5 = 31.5.

 

560 CALL HCHAR(BR,BC,129)

This line displays the bullet at its current spot on the screen.

 

570 CALL HCHAR(BR,BC,32)

This line erases the bullet just displayed by writing over it with a space.

 

A couple of other problems with the program:

1. The program crashes if you try to move the gun beyond either side of the screen. It should either ignore your efforts to move farther or wrap around to the other side of the screen.
   
2. Line 700 never gets executed.
   

...lee

[+Lee Stewart]

...

and how can the main game loop from 350 - 670 still work when things are bouncing from one line to another? Like the print bullet, shooting, and plane drawing routines... Most of the lines I know how it works by the routine or line itself, but not how it comes together as a whole. That seems confusing.

...

 

There are 3 statements that get executed for every pass through the main loop:

1. Draw plane at beginning of loop.
   
2. Erase plane at end of loop.
   
3. Draw gun at end of loop.
   

The gun gets erased only if it is moved (430). It gets redrawn in its new position at the bottom of the loop.

 

If the fire button is pressed:

1. The fire indicator F is set to 1 and the bullet column BC is set equal to the gun column GC (500 -- 520).
   
2. Before drawing the bullet, "CALL GCHAR" at 540 gets the character at the current bullet position.
   
3. The bullet is drawn and then erased (560 -- 570).
   
4. If the character found in (2) at the current bullet position is the plane (128), the main loop is exited and the "hit" routine is executed. The plane was already overdrawn by (3).
   
5. If there was no hit:
   
   • The bullet row BR is decremented by 3,
     
   • If the plane row was passed, BR and F are reset to initial conditions.
     

Once the fire button has been pressed, subsequent passes through the loop bypass the keyscan routine until the plane is either hit or missed. If the plane is missed, normal operation of the main loop resumes.

 

...lee

[TEXAS_JOE]

i KNEW someone on here could explain it better than me!

[+Lee Stewart]

i KNEW someone on here could explain it better than me!

 

Don't sell yourself short! You have an active mind that goes with the flow. I rather enjoy reading your posts.

 

...lee

[TEXAS_JOE]

Thankyou Lee

[orion1052003]

All those posts were good for me. How about line 460? I think it is the S and D keys input for left and right motion, but how does the relational expression actually break down? GC=GC-(K=68)+(K=83) Say the Gun Column is 5, and you press D for right. 5-(-1) + (0) = 6 OR does it equal 4? Does it mean 5 +1 when there are 2 negatives or one of them disappears to make 5-4?

[+Lee Stewart]

All those posts were good for me. How about line 460? I think it is the S and D keys input for left and right motion, but how does the relational expression actually break down? GC=GC-(K=68)+(K=83) Say the Gun Column is 5, and you press D for right. 5-(-1) + (0) = 6 OR does it equal 4? Does it mean 5 +1 when there are 2 negatives or one of them disappears to make 5-4?

 

It's normal mathematics once the relational expressions are evaluated. Your first equation is correct. You are subtracting -1 from 5, thus adding 1, which, of course, is 6. That will result in the gun moving right one column. Pressing "S" will result in adding -1 to 5, which results in 4, to move left. You can prove this by inserting print statements before and after the calculation to print the value of GC before and after the calculation.

 

...lee

[orion1052003]

Hello. I tried to make a program based on TARGET to learn to use the concepts and understand them. I was thinking to try and do this exercise with different inputs, since that always seems confusing. To have the same example program, but to switch out the different types of input like switching a subroutine. To try one with keyboard input and HCHAR, then switch that out with Joystick input and HCHAR, and then Joystick input and Sprites.

 

The program has the most original name ever, GAME.

 

Some problems are :

Lines 410-411 I got out of the book for a screen border check to keep the player in the boundaries of the screen, but it doesn't work.

 

Lines 340-460 is the Main Loop and I don't get why the player leaves a trail behind. I think it has something to do with erasing where the player was previously at with another variable.

 

Another question is how do you show the background you want? You might notice in the attachment

picture game, the player character(batarang lookin' thing in the center) shows the default TI color behind it. Also, the enemy plane in the top left corner. I used CALL COLOR(set,black,transparent) or CALL COLOR(9,2,1) Transparent seems to destroy whatever is drawn under it and show the default screen or whatever color is CALL SCREEned. I was hoping to see the grid under the player graphic.

I tried to get around this by setting the player and enemy graphic to a black background and the screen black as well. It works a lot better, but you see the grid is partially cut off in picture attachment GAME2. Is this a limitation of the TI or is there a way to fix this?

 

Another thing to work on would be to make a player shooting routine, and better movement for the enemy. Probably an enemy shooting routine, a player and enemy crashing routine, and collision detection. I'm clueless about that. Somewhere around 420 would be a GETCHAR statement and 420 would branch to a collision sequence. Not so sure how to use get char even after reading about it in the XB manual.

 

When you input a key at say line 370, ..370 CALL KEY(0,K,S) are you supposed to do IF K=0 THEN 370 or IF S=0 THEN 370 (IF KEY=0 THEN 370, IF STATUS=0 THEN 370) in order to block typing the wrong keys? Does it matter which you use?

 

I did not know how to get the left,right,up, down views for the player going. Chars 96-99. So it moves with the UP redefinition. Usually you can branch to a routine for each direction, life IF X=-4 THEN...go left routine, but I didn't know how to stick that together with the relational expression.

10 !GAME
50 ! TITLE
60 ! 4-11-12 JAMES PEYTON
70 ! TEXAS INSTRUMENTS HOME COMPUTER
80 ! TI-99/4A EXTENDED BASIC
90 ! --INITIALIZATION--
100 CALL CLEAR :: R=12 :: C=16
110 ! --GRAPHICS --
120 BL$=RPT$("F",16)!104 BLACK SQUARE
130 TL$="1F1F181818181818"! 112 TOP LEFT
140 TR$="FFFF030303030303"! 113 TOPRIGHT
150 BL$="C0C0C0C0C0C0FFFF"!  114 BOTTOM LEFT
160 BR$="030303030303FFFF"!  115 BOTTOM RIGHT
170 B$="181818181818FFFF"! 116 BOTTOMROW
180 T$="FFFF181818181818"! 117 TOPROW
190 L$="C0C0C0FFFFC0C0C0"! 118 LEFTROW
200 R$="030303FFFF030303"!  119 RIGHT ROW
210 M$="181818FFFF181818"!  120 MAIN SQUARE
220 E$="005048FFFF481020"!  128 ENEMY
230 VU$="183C7EC3C3000000"!  UP
240 VD$="C3C37E3C18000000"!  DOWN
250 VL$="1183860E0E060381"!   LEFT
260 VR$="C0E030383830E0C0"!  RIGHT
270 CALL CHAR(96,VU$,97,VD$,98,VL$,99,VR$,104,BL$,112,TL$,113,TR$,114,BL$,115,BR$,116,B$,117,T$,118,L$,119,R$,120,M$,128,E$)
280 !SET-UP SCREEN
283 CALL SCREEN(2)
290 CALL HCHAR(1,1,120,768) :: CALL HCHAR(24,1,104,64) :: CALL VCHAR(24,31,104,48)!BORDER
300 CALL HCHAR(2,3,117,28) :: CALL HCHAR(23,3,116,28) :: CALL VCHAR(3,2,118,20) :: CALL VCHAR(3,31,119,20)!GRID BORDER
310 CALL HCHAR(2,2,112) :: CALL HCHAR(2,31,113) :: CALL HCHAR(23,2,114) :: CALL HCHAR(23,31,115)!GRID CORNERS
320 CALL COLOR(9,11,1,10,2,2,11,7,2,12,7,2,13,13,1)
330 CALL HCHAR(R,C,96)!START POINT
340 !MAIN LOOP
350 FOR EC=2 TO 31
360 CALL HCHAR(2,EC,128)
370 CALL KEY(0,K,S)
380 IF K=81 THEN 470!Q KEY
390 IF K=0 THEN 370
395 !ALL HCHAR(R,C,32)
400 R=R-(K=88)+(K=69) :: C=C-(K=68)+(K=83)
405 !F K=88 THEN R=R+1
406 !F K=69 THEN R=R-1
407 !F K=68 THEN C=C+1
408 !F K=83 THEN C=C-1
409 CALL HCHAR(R,C,32) :: CALL HCHAR(R,C,96)
410 R=R-(24*(R=0))+(24*(R=25))
411 C=C-(32*(C=0))+(32*(C=33))
420 !F Z=128 THEN (CRASHROUTINELINENUMBER)
450 NEXT EC
460 GOTO 350
470 CALL CLEAR
480 CALL SCREEN(15)
490 PRINT "PROGRAM INDEX"
500 PRINT "GRAPHICS..110-270"
505 PRINT "CHARACTER 104";CHR$(104)
510 PRINT "CHARACTER 112";CHR$(112)
520 PRINT "CHARACTER 113";CHR$(113)
530 PRINT "CHARACTER 114";CHR$(114)
540 PRINT "CHARACTER 115";CHR$(115)
550 PRINT "CHARACTER 116";CHR$(116)
560 PRINT "CHARACTER 117";CHR$(117)
570 PRINT "CHARACTER 118";CHR$(118)
580 PRINT "CHARACTER 119";CHR$(119)
590 PRINT "CHARACTER 120";CHR$(120)
600 PRINT "CHARACTER 128";CHR$(128)
610 PRINT "CHARACTER 96 ";CHR$(96)
620 PRINT "CHARACTER 97 ";CHR$(97)
630 PRINT "CHARACTER 98 ";CHR$(98)
640 PRINT "CHARACTER 99 ";CHR$(99)
650 PRINT "TITLE..50-80"
660 PRINT "INITIALIZATION..90-100"
670 PRINT "MAIN LOOP 340-460"
680 PRINT "INDEX..470-700"
700 GOTO 700

[orion1052003]

Anyone have any thoughts on the sample "GAME" program meant to illustrate TARGET? I can LIST the other programs from the Game Writer's Pack if anyone can also use them as a learning tool. They are Bat, Dragon, Maze, Duel, Target, and Racetrack.

[sometimes99er]

Reminds me a bit of Gridrunner for Commodore 64 and POD for the Commodore Amiga.

 

http://www.youtube.com/watch?v=zfJ_mSOxPJ0

 

http://www.youtube.com/watch?v=dQ0sJUJUyXs

[orion1052003]

That looks like a good game. Wonder if the amiga or the c-64 version is better. Any thoughts on post #10? I am trying to use use the program GAME to learn the examples in the book, but if I could make a program out of it, I would purposely make it different than grid runner now that I've seen some of what goes on in the gameplay,

[sometimes99er]

That looks like a good game. Wonder if the amiga or the c-64 version is better.

 

Actually two different games there (but they sure look alike). Don't know if Gridrunner is/was available for the Amiga. Also, they look a bit like Centipede, 1980 arcade game from Atari.

 

Any thoughts on post #10?

 

Looks nice.

 

Line 410 has a more straight forward solution (maybe not the fastest) ...

 

410 IF R<1 THEN R=1 ELSE IF R>24 THEN R=24

 

You can use the same approach for line 411. That would be

 

411 IF C<1 THEN C=1 ELSE IF C>32 THEN C=32

 

An alternative to this (only line 411) is

 

411 C=(C AND 31)+1

 

I think it might be slightly faster, but instead of a border effect, you'll get a wraparound effect.

 

This can be done for line 410 too, but will be a bit more complicated (harder to understand), and will look like the original 410 solution. Firstly either get a good feel/understanding of "C AND 31" or use the IF solution.

Edited April 30, 2012 by sometimes99er

[sometimes99er]

Lines 340-460 is the Main Loop and I don't get why the player leaves a trail behind. I think it has something to do with erasing where the player was previously at with another variable.

 

Try ...

 

395 CALL HCHAR(R,C,120)

409 CALL HCHAR(R,C,96)

 

Line 395 removes the player and sets the correct background before updating the R and C variables.

Line 409 sets the player at the new location.

[sometimes99er]

Another question is how do you show the background you want?

 

You might notice in the attachment picture game, the player character(batarang lookin' thing in the center) shows the default TI color behind it. Also, the enemy plane in the top left corner. I used CALL COLOR(set,black,transparent) or CALL COLOR(9,2,1) Transparent seems to destroy whatever is drawn under it and show the default screen or whatever color is CALL SCREEned. I was hoping to see the grid under the player graphic.

 

I tried to get around this by setting the player and enemy graphic to a black background and the screen black as well. It works a lot better, but you see the grid is partially cut off in picture attachment GAME2. Is this a limitation of the TI or is there a way to fix this?

 

In TIB and XB the maximum numbers of colors within each character is two. Foreground color and background color. You change the character pattern using CALL CHAR and the colors are controlled by CALL COLOR (for groups of 8 characters). If you use the transparent color, it simply uses/shows the border color, and, as you say, it's controlled by CALL SCREEN.

 

If you want the player to hover above the background graphics (all the characters in different screen locations), you have to use sprites.

[sometimes99er]

When you input a key at say line 370, ..370 CALL KEY(0,K,S) are you supposed to do IF K=0 THEN 370 or IF S=0 THEN 370 (IF KEY=0 THEN 370, IF STATUS=0 THEN 370) in order to block typing the wrong keys? Does it matter which you use?

 

That would be

 

370 CALL KEY(0,K,S)::IF S=0 then 370

380 ! HANDLE PLAYER MOVEMENT

 

But then all it does is wait for you to press a key. No enemy movement. No nothing. You would probably want this

 

370 CALL KEY(0,K,S)

380 ! DO STUFF (LIKE MOVE ENEMY, MOVE SHOTS, COLLISION DETECTION ...)

390 IF S=0 then 370

400 ! HANDLE PLAYER MOVEMENT

 

Format

CALL KEY( key-unit, return-variable, status-variable )

 

Description

 

The KEY subprogram assigns the code of the key pressed to return-variable. The value assigned depends on the key-unit specified. If key-unit is 0, input is taken from the entire keyboard, and the value placed in return-variable is the ASCII code of the key pressed. If no key is pressed, return-variable is set equal to - 1. See Appendix C for a list of the ASCII codes.

 

If key-unit is 1, input is taken from the left side of the keyboard. If key-unit is 2, input is taken from the right side of the keyboard. The possible values placed in return-variable are given in Appendix J. Values of 3, 4, and 5 are reserved for possible future uses.

 

Status-variable indicates whether a key has been pressed. A value of 1 means a new key was pressed since the last CALL KEY was executed. A value of - 1 means the same key was pressed as in the previous CALL KEY. A value of 0 means no key was pressed.

 

Example

 

100 CALL KEY(0,K,S)

 

CALL KEY(0,K,S) returns in K the ASCII code of any key pressed on the keyboard, and in S a value indicating whether any key was pressed.

[sometimes99er]

I did not know how to get the left,right,up, down views for the player going. Chars 96-99. So it moves with the UP redefinition. Usually you can branch to a routine for each direction, life IF X=-4 THEN...go left routine, but I didn't know how to stick that together with the relational expression.

 

Here an example. I prefer using the joystick (which for me is the arrow keys in emulation). No scoring, shooting or border control ...

 

100 CALL CLEAR ! Clear screen
110 CALL CHAR(33,"10307FFF7F301000081C3E7F1C1C1C1C00080CFEFFFE0C081C1C1C1C7F3E1C08") ! Graphics for left, up, right and down
120 D=33 ! Character code for direction
130 R=12 ! Row
140 C=16 ! Column

200 CALL HCHAR(R,C,D) ! Display arrow

300 CALL JOYST(1,X,Y) ! Read joystick
310 IF X<>0 then 400 ! Horizontal move ?
320 IF Y<>0 then 500 ! Vertical move ?
330 GOTO 300 ! No movement

400 IF X=-4 THEN D=33 ! Moving left ?
410 IF X= 4 THEN D=35 ! Moving right ?
420 CALL HCHAR(R,C,32) ! Clear "trail" (present position)
430 C=C+X/4 ! Calculate new horizontal position
440 GOTO 200 ! Go display and wait for next move

500 IF Y= 4 THEN D=34 ! Moving up ?
510 IF Y=-4 THEN D=36 ! Moving down ?
520 CALL HCHAR(R,C,32) ! Clear "trail" (present position)
530 R=R-Y/4 ! Calculate new vertical position
540 GOTO 200 ! Go display and wait for next move

[sometimes99er]

Somewhere around 420 would be a GETCHAR statement and 420 would branch to a collision sequence. Not so sure how to use get char even after reading about it in the XB manual.

 

Same example extended just a bit.

 

100 CALL CLEAR ! Clear screen
110 CALL CHAR(33,"10307FFF7F301000081C3E7F1C1C1C1C00080CFEFFFE0C081C1C1C1C7F3E1C08") ! Graphics for left, up, right and down
120 D=33 ! Character code for direction
130 R=12 ! Row
140 C=16 ! Column

150 CALL CHAR(37,"10387CFE7C381") ! Graphics for diamond
160 FOR A=0 TO 19::CALL HCHAR(RND*24+1,RND*32+1,37)::NEXT A ! Put 20 diamonds on screen

200 CALL GCHAR(R,C,G) ! Read position
210 if g=37 then call sound(-99,1000,0) ! If diamond do sound
220 CALL HCHAR(R,C,D) ! Display arrow

300 CALL JOYST(1,X,Y) ! Read joystick
310 IF X<>0 then 400 ! Horizontal move ?
320 IF Y<>0 then 500 ! Vertical move ?
330 GOTO 300 ! No movement

400 IF X=-4 THEN D=33 ! Moving left ?
410 IF X= 4 THEN D=35 ! Moving right ?
420 CALL HCHAR(R,C,32) ! Clear "trail" (present position)
430 C=C+X/4 ! Calculate new horizontal position
440 GOTO 200 ! Go display and wait for next move

500 IF Y= 4 THEN D=34 ! Moving up ?
510 IF Y=-4 THEN D=36 ! Moving down ?
520 CALL HCHAR(R,C,32) ! Clear "trail" (present position)
530 R=R-Y/4 ! Calculate new vertical position
540 GOTO 200 ! Go display and wait for next move

[+Lee Stewart]

Some problems are :

Lines 410-411 I got out of the book for a screen border check to keep the player in the boundaries of the screen, but it doesn't work.

 

There is nothing wrong with lines 410-411, presuming R and C only change by ±1 elsewhere in the program. This is a case of closing the barn door after the horse has already bolted. The problem is that you are moving the character before line 410 when you need to move it after line 411, which is after you have compensated for going off screen.

 

Lines 340-460 is the Main Loop and I don't get why the player leaves a trail behind. I think it has something to do with erasing where the player was previously at with another variable.

 

Your conclusion is correct. As Sometimes99er said, you need to replace the previous location of your character with the background character (char 120---may need different char at screen edges) in line 395. You have a commented-out placement of the space character in that location, which, you undoubtedly discovered, left a trail of spaces.

 

...lee