Classic Computer Magazine Archive COMPUTE! ISSUE 8 / JANUARY 1981 / PAGE 92

THE PET®GAZETTE

The Screen squeeze Fix For CBM 8000

Richard Mansfield

Screen Squeeze is a fix for the many programs written for the regular 40-column PETs. Since the new 80-column series has virtually no software yet, this routine will permit games and graphics to work normally on a simulated 40-column matrix within the 80 column display.

When there is a ROM upgrade, there is a good reason for it: added BASIC power, eliminated bugs, new system features. The negative side is that much established software no longer works right. The problems are mainly in the SYS, POKE, and PEEK statements within programs.

To update your software, you must know, for example, that a certain POKE put you into the graphics mode, that a certain PEEK told you where to find the cursor, and that a certain SYS gave you a warm start. Then, after you locate all these commands in the program, you must assign the new, upgrade addresses to them. If, in addition, there are machine language routines, they will probably need adjustments too. Space in zero page, the first 256 bytes in the computer, is frequently important in M.L. programs and it has been getting progressively more scarce with each upgrade.

These are the main problems in software updating. But with the introduction of the new 80-column screen, extra adaptations are required.

It is true that there are several additions to screen formating in BASIC 4.0 in the 8000 series (double-screen) computers. You can define any screen size you want by printing CHR$(14) and CHR$(143) for the top left and the bottom right extremities respectively. This means that a LIST could scroll with nothing lost within a one-inch window, if you wish.

Or you can POKE 213, 40 and the LISTS and PRINTS will be confined to the left half of the screen (exactly as if you has a 40-column display). But none of this solves our problem—any pokes out side of these boundaries will still be incorrect. And many graphs and games involve just such POKE statements.

The problem is best illustrated with an example. Let's assume that a ball rolls from left to right across the screen. It would be possible to PRINT such action, but it would be slower and less vivid, less animated. So, the ASCII number of the ball is POKED into column one, then extinguished with a POKE X, 32 (a blank), then POKE X + 1, ball. And so on, across the screen. The important thing, here, is that the POKE addresses are calculated in the program and, in a complex game, you could spend days unraveling simultaneous equations trying to get things right for the bigger screen.

Screen Squeeze simply allows the wrong POKEs to take place and then, seeing them, corrects them in a flash. It is fast enough to make itself little noticed (there is some flickering on the right half of the screen).

But it will not solve everything, only the display itself. It cannot detect programmed blanks since all blanks look the same. This means that additional fiddling with the code (involving POKE X, 32) is necessary. But this is less frequent and more obvious than other graphics POKEs. ScreenSqueeze will simplify software adaptation, but not solve it.

Since this machine language routine is applicable to many tasks involving alterations to the screen, I will explain it in detail. The best way to learn the valuable art of programming in M.L. is to get a good book on the subject and then study examples. M.L. is valuable for two reasons—it is very much faster in execution than BASIC and it can do things not possible with BASIC code. Many real-time games (games where there is a time limit) involve animation which must be written in M.L. code to be fast enough.

869-916 set up two addresses (32768 and 32808) as the first targets. In addition, we enter the number 80 which will be added to the above two addresses each time as we finish checking a line for illegal POKES.

918-920 Initialize our counters (the x and the y will keep track of how many columns we have checked and how many of the 25 possible lines).

922 get the potentially wrong POKE from address 32808.

924 go to the subroutine which checks legality and adjusts for it.

927-930 increase the columns counter and, if less than 40, return to 922 for the second column check.

932-957 if all 40 columns were checked in that line, then add 80 to the target addresses.

959-964 increase the lines counter and, if it is 25, return to basic. If not, go back to where the loop begins and start on the next line.

965-975 the actual task being performed--see if the screen address was blank. If it was, then go back (via return) to 927 where the columns counter is increased, and continue checking further addresses. If the address was not blank, then put the found character over 40 spaces to the left where it belongs. And, also, put a blank where this character was found. Then return to 927.

5 REM : SHOVE 80 COLUMNS INTO 40---RICHARD MANSFIELD
10 DATA 169, 80, 133, 188, 169, 128, 234, 234, 133, 191, 133, 193, 169, 0, 133, 189, 133, 190
20 DATA 169, 40, 133, 192, 162, 0, 160, 0, 177, 192, 32, 197, 3, 200, 192, 40, 208
30 DATA 246, 24, 216, 165, 188, 101, 190, 133, 190, 165, 189, 101, 191, 133, 191, 24
40 DATA 165, 188, 101, 192, 133, 192, 165, 189, 101, 193, 133, 193, 232, 224, 25, 208
50 DATA 212, 96, 201, 32, 240, 6, 145, 190, 169, 32, 145, 192, 96
60 FOR I = 896 TO 975 : READN : POKE I, N : NEXT I
70 REM ----DEMONSTRATION----
80 PRINT "&circH;"; : FOR T = 1 TO 200 : PRINT";R	";: NEXT
90 SYS896 : PRINT"H"
===ADDRESS=== 896
896 LDA # 80
898 STA 188
900 LDA # 128
902 NOP
903 NOP
904 STA 191
906 STA 193
908 LDA # 0
910 STA 189
912 STA 190
914 LDA # 40
916 STA 192
918 LDX # 0
920 LDY # 0
922 LDA ( 192), Y
924 JSR 965
927 INY
928 CPY # 40
930 BNE 922
932 CLC
933 CLD
934 LDA 188
936 ADC 190
938 STA 190
940 LDA 189
942 ADC 191
944 STA 191
946 CLC
947 LDA 188
949 ADC 192
951 STA 192
953 LDA 189
955 ADC 193
957 STA 193
959 INX
960 CPX # 25
962 BNE	      920			/\
964 RTS
965 CMP # 32
967 BEQ	      975		/\
969 STA ( 190), Y
971 LDA # 32
973 STA ( 192), Y
975 RTS