Currently Technical Services Manager, David Ornstein has been with Sinclair since the opening of its U.S. office. He has been involved with Sinclair’s technical hotline, technical writing, and machine servicing. His primary interests are in the areas of software and hardware R & D, and system integration.
His secondary interests are reading (Frank Herbert), listening (Pink Floyd) and sharing perceptions.
SYNCSUMs
One day, I was typing a system-check program into our computer. I took four and a half hours to enter the program. As I was about to run it, an awful thought occurred to me: What if I had made an error in my typing? Since the program had access to all parts of the system, a typo could be fatal. I decided to check it against the listing . . . once. Then I ran it. The end result—that I overwrote the system disk—is irrelevant. But what is important is this: If the program listing had included the program’s SYNCSUM, I would have known better.
What is a SYNCSUM? A SYNCSUM is what is known as a checksum, or, rather, a modified version of a checksum. The checksum is a method of checking to see whether a program has been entered correctly by letting the computer add up all the bytes in a program. To use this error-checking method, you simply compare the checksum of the original program with the checksum of the program you have entered. If the numbers are not the same, you have made an error in entering the program. If the numbers are the same, the chances are about 90% that you have entered the program correctly.
In the ZX80, a certain area of memory is used to hold the current program. This area begins where the area for system variables ends. For the 4K ROM, this address is 16424 decimal (4028 hex); for the 8K ROM, 16509 decimal (407D hex). A system variable points to the first byte after the program area. The 4K and 8K ROMs format memory differently. In a 4K system, therefore, this variable is VARS (which points to the first byte of the VARiable Storage area), but in an 8K system, it is D-FILE (which points to the first byte in the Display FILE). These variables are stored at locations 16392 (4K) and 16396 (8K), respectively.
The assembly language program, shown in listing 1, is used to generate the current program’s SYNCSUM on a 4K system. The corresponding program for an 8K system is shown in listing 2. You will notice that it is not adding all the bytes, but XORing them together. This is the modification of the standard checksum method referred to earlier. You will end up with a number which is less than 256.
To use the SYNCSUM program on a Basic program requires that the SYNCSUM program be resident (i.e., in memory) all the time. This can be accomplished first, by reserving some memory (RAM) such that Basic will not tamper with it, and, second, by loading the SYNCSUM routine into this area. Listings 3 and 5 are programs to reserve the required amount of memory, 27 bytes. They should be used on 8K and 4K systems respectively. Listings 4 and 6 are programs to load the machine language SYNCSUM generation program into this previously reserved memory space. These programs should be run at the beginning of any session of computer use when you may want to know a programs’s SYNCSUM. From the time they are run until the computer is turned off, obtaining the SYNCSUM is simple: type PRINT USR(x), where x = your memory size (for example, 1024, 2048, 16384) – 27 + 16384, followed by NEWLINE as always. Thus x will equal 17381 for 1K, 18405 for 2K, and 32741 for 16K.
Enter (or LOAD) the RSV program (listing 3 or 5) and then RUN and NEWLINE. The 4K program will prompt you for “MEMORY SIZE?” Enter your memory size (1024, 2048, 16384) and NEWLINE. Next enter (or on 8K systems only, LOAD) the LDR program (listing 4 or 6). On a 4K system LOADing the LDR program after using RSV will cancel the effects of running the RSV program.
Press RUN and NEWLINE. Again the 4K program will prompt you for “MEMORY SIZE?” Again enter it and NEWLINE. The 4K “MEMORY SIZE?” prompt will return to the screen, but hit NEWLINE and you will return to program mode. The SYNCSUM routine is now resident.
On an 8K system, type NEW and NEWLINE. On 4K systems, as noted earlier, using the NEW command will delete the SYNCSUM routine from memory. Therefore, to clear out the 4K LDR program, you must delete each line individually. To delete, e.g., line 10, type 10 and NEWLINE. Repeat until the whole program is gone.
You can now begin entering your program. Once again, if you have an 8K system, you can LOAD your program. With 4K you must type in each line individually, as LOADing will destroy the SYNCSUM routine. You can now obtain the SYNCSUM at any point along the way via the PRINT USR (x) command (see above for the size of x). When you have finished and you are sure your program is correct, call for the SYNCSUM for the entire program. Write it down at end of your program for future reference. Be sure to include it after the end of any programs submitted to SYNC.
This method will also work just as well with the ZX81 since it uses the 8K ROM.
I hope this idea is as helpful to ZX80 owners as it is to the rest of the computer world.
Until next issue, same relativistic time period, same non-euclidian universe.
Listing 1.
Label Hex Assembly Code Comments
4KSSUM: 212840 LD HL,16424 ;HL=Start
ED5B0840 LD DE,(VARS) ;DE=Stop
0600 LD B,00 ;B=00 (Result Accumulator)
LOOP: 7C LD A,H ;If HL=DE then XORNXT
BA CP D
2008 JR NZ,XORNXT
7D LD A,L
BB CP E
2004 JR NZ,XORNXT
DONE; ;else done
68 LD L,B ;low byte returned is SYNCSUM
2600 LD H,00 ;high byte is 00
C9 RET
XORNXT: ;XOR the next byte into the
;Result Accumulator.
78 LD A,B ;Get current RA
AE XOR (HL) ;XOR it in
47 LD B,A ;put back result into RA
23 INC HL ;bump pointer
18EE JR LOOP ;go back for next byteListing 2.
Label Hex Assembly Code Comments
8KSSUM: 217040 LD HL,16509 ;HL=Start
ED5B1240 LD DE,(D-FILE) ;DE=Stop
0600 LD B,00 ;B=00 (Result Accumulator)
LOOP: 7C LD A,H ;If HL≠DE then XORNXT
BA CP D
2008 JR NZ,XORNXT
7D LD A,L
BB CP E
2004 JR NZ,XORNXT
DONE: ;else done
68 LD C,B ;low byte returned is SYNCSUM
0600 LD B,00 ;high byte is 00
C9 RET
XORNXT: ;XOR the next byte into the
;Result Accumulator.
78 LD A,B ;Get current RA
AE XOR (HL) ;XOR it in
47 LD B,A ;put back result into RA
23 INC HL ;bump pointer
18EE JR LOOP ;go back for next byteListing 3: 8K ROM RSV.
10 LET R=27 [the number of bytes to reserve]
20 LET RAMTOP=PEEK(16388)+PEEK(16389)*256-R
30 POKE 16388,RAMTOP-256*INT(RAMTOP/256)
40 POKE 16389,INT(RAMTOP/256)
50 NEWListing 4: 8K ROM LDR
10 REM 217040ED5B124006007CBA20087DBB
2004680600C978AE472318EE
20 LET RT=PEEK(16388)+PEEK(16389)*256
30 FOR B=0 TO 26
40 LET X=((PEEK(16509+5+B*2)-28)*16+(PEEK
(16509+5+B*2+1)-28))
50 POKE RT+B,X
60 NEXT BListing 5: 4K ROM RSV
5 LET R=27
10 PRINT "MEMORY SIZE ?"
20 INPUT M
30 LET M=M-R+16384
35 POKE 16999,33
40 POKE 17000,M
50 POKE 17001,M/256
60 POKE 17002,195
70 POKE 17003,107
80 POKE 17004,2
90 LET K=USR(16999)Listing 6: 4K ROM LDR
10 REM 212840ED5B084006007CBA20087DBB
2004682600C978AE472318EE
15 LET R=27
20 PRINT "MEMORY SIZE ?"
30 INPUT M
40 LET RT=M-R+16384
50 FOR B=0 TO 26
60 LET X=((PEEK(16424+3+B*2)-28)*16+(PEEK
(16424+3+B*2+1)-28))
70 POKE RT+B,X
80 NEXT BNote: Type-in program listings on this website use ZMAKEBAS notation for graphics characters.