Computus Interruptus, Part 4

See all articles from SINCUS v3 n6

-Or, the Joy of Using the Interrupts on Your Computer

As mentioned last time, the interrupt driven print-screen program we’ve been playing with is just about “all used up”, as a learning tool. Its main advantage was that it was very short, and could be easily entered. Unfortunately, it required a TS2040 printer to operate.

Starting with this installment, we’ll learn some new things by working with an interrupt driven sprite program. It’s more work to enter, but it’s fun to watch, and anyone with a TS2068 can try it.

Let’s define some terms. A sprite is a graphic “object” that we place on the screen, with a given location, direction and speed, and then just ‘let it go’. It will then move on its own. True sprites require special display hardware. We can simulate this in software, and still retain most of the abilities normally associated with sprites.

The BASIC program given is all you need to send a happy little sprite bouncing merrily around your screen. Because he’s interrupt driven ( in programmer’s lingo, he’s operating “in the background”), you can type in, LIST, or RUN your own programs without disturbing him. He’ll just keep bouncing, because you normally run BASIC and machine code in the “foreground”. Note that the terms foreground and background have a somewhat wider range of meaning on certain certain computer systems;these are of no interest to us here.

Computer syetems may be said to have different programs running simultaneously in the foreground and background. If we want to get extremely picky, we can point out that most computers can only do one thing at a time. The running of the foreground is periodically put “on hold” ( suspended )in order to run the background program. This is just another way of saying that the system has processed an interrupt.

This description should not be confused with multitasking. In such a case, the program being multitasked might be in the foreground, while a background program allows portions of each to be run;either in rotation or according to some priority scheme.

COMPUTUS INTERRUPTUS -or, the joy of using the interrupts on your computer -By Wes Brzozowski (cartoon of a computer juggling "JOBS" and "ON HOLD" boxes)
COMPUTUS INTERRUPTUS -or, the joy of using the interrupts on your computer -By Wes Brzozowski (cartoon of a computer juggling "JOBS" and "ON HOLD" boxes)

This wouldn’t cause two BASIC programs to run faster together the constant switching around should actually make them run slower. The advantage comes from the fact that computers often use up a lot of time just waiting…for you to press a key,for a printer to print a character, etc. A multitasking system allows that wasted time to be used by someelse. The rather limited market for this facility in a home computer explains why it’s not usually implemented on smaller systemslike ours, although it could probably be done.

Although concepts like multitasking may be of limited use in our machines, concepts like foreground and background are not. For example, all Timex and Sinclair machines (though I’m not sure about the QL) scan the keyboard in the background. Because of this, even machine code programmers can skip the lengthy scanning process needed to read the keyboard. Certain memory locations will already conatin a running account of which key is being pressed, almost as if by magic.But it’s not magic; it’s being done invisibly for you in the background.

Defining those terms, and hopefully grasping those ideas, will help us to understand how are little sprites can stay so busy on the screen while there’s “obviously” no program running, or while we’re already running something completely different. It will also help us to understand why certain actions on our part can cause the sprite to “rest” for awhile. Understan[illegible]ng these things shows us that the little computer normally d[illegible] a lot more than we think!

I apologise for the length of the program; the DATA statements are no fun to type and check. Please be assured that the program is just about a short as it can be and still work This limits our ability to change it, though its highly modular and only certain portions need be rewritten to expand it. We’ll cover these in the future.

This program works on a “plain vanilla” TS2068, or with a Spectrum emulator, and doesn’t need the pullup resistors we’ve discussed in the past. After entering the program, use line 9999 to SAVE it to tape, and then RUN it. ( Also, look closely at line 9999, and note what happens when you LOAD the program back. This is not a overly useful, but, er…flashy little trick.)

After the program RUNs, the sprite program will have bee[illegible] entered into memory, but it wont start the sprite yet. If you get the message “Checksum Error”, then you made an error in entering the DATA statements. Recheck them and try again. If all goes well, you may NEW the program if you wish.

To start the sprite, type in RAND USR 64776. To stop it and make it vanish, type in POKE 64898,1 . While the sprite is moving around, you still have control over the computer to enter and RUN a program. The sprite doesn’t care, he’s running in the background.

Some BASIC commands like BEEP, COPY or SAVE will disable the interrupt and cause the sprite to stop for a short time. T[illegible] is because each of these commands require the computer to produce a precisely timed series of pulses. In order to cut costs, these pulses are timed by software delay loops. Any interrupt would change this timing, so the interrupt is diabled while they’re running. The presence of our happy sprite allows us to “see” a disabled interrupt.

I should point out that some BASIC commands can cause strange things to happen. In order to keep the program simple, the sprite routine assumes that all screen commands operate on [illegible]ingle characters ( commands like PRINT or LIST ). Other commands that work one pixel at a time, (like PLOT or CIRCLE) or full screen operations, (like CLS or screen scrolling) can cause stationary bits of sprite to be left around the screen. These problems may be avoided if you shut off the sprite before doing these commands, and turn it on again, after you’ve done them. The sprite will then continue where it left off.

Besides being interesting to play with, the program can give you a better “feel” for the basic principle of interrupts than mere reading can. Owners of a disassembler like HOT Z-2068 won’t have much difficulty figuring out the code. For those content to wait, we’ll talk all about it, next time.

Interrupt Driven Sprite Program

  10 REM Sprite Demonstrator
20 REM Enable Sprite With
RAND USR 64776
30 REM Disable Sprite With
POKE 64898,1
35 CLEAR 64767
40 FOR j=65024 TO 65280: POKE
j,253: NEXT j
50 POKE 65021,195: POKE 65022,
27: POKE 65023,253
90 LET checksum=0
100 RESTORE 1000
110 FOR j=64776 TO 64992
120 READ dat: LET checksum=chec
ksum+dat
130 POKE j,dat
140 NEXT j
150 IF checksum<>30092 THEN CLS
: PRINT "Checksum Error!!!!!!!"
: STOP
1000 DATA 243,237,94,62,254,237,
71,175,50,130
1010 DATA 253,205,211,253,205,64
,253,251,201,245
1020 DATA 197,213,229,205,139,25
3,58,130,253,167
1030 DATA 32,16,205,78,253,205,2
11,253,205,64
1040 DATA 253,225,209,193,241,19
5,56,0,237,86
1050 DATA 225,209,193,241,251,20
1,1,131,253,237
1060 DATA 91,126,253,205,165,253
,205,180,253,201
1070 DATA 237,91,126,253,237,75,
128,253,62,31
1080 DATA 187,32,2,14,255,175,18
7,32,2,14
1090 DATA 1,186,32,2,6,1,62,23,1
86,32
1100 DATA 2,6,255,237,67,128,253
,123,129,95
1110 DATA 122,128,87,237,83,126,
253,201,10,10
1120 DATA 1,255,0,60,66,165,129,
165,153,66
1130 DATA 60,237,91,126,253,205,
165,253,229,1
1140 DATA 131,253,205,200,253,32
,8,225,1,0
1150 DATA 253,205,180,253,201,22
5,201,122,230,7
1160 DATA 15,15,15,179,111,122,2
30,24,246,64
1170 DATA 103,201,22,8,10,119,36
,3,21,32
1180 DATA 249,201,22,8,126,36,2,
3,21,32
1190 DATA 249,201,22,8,10,3,190,
192,36,21
1200 DATA 32,248,201,237,91,126,
253,205,165,253
1210 DATA 1,0,253,205,190,253,20
1
9998 STOP
9999 SAVE CHR$ 18+CHR$ 1+"Sprite
"+CHR$ 18+CHR$ 0 LINE 10