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