titus-larsen-titus-1981-apple-interfacing

sensor. Of course, you will have to determine the corresponding key
·
codes.
We used approximately 10-second periods, for test purposes, with
2-second yellow periods. The program that we used is listed for you:
10 A = 0: P = 49318
20 POKE P, 222
30 FOR R = 0 TO 10
40 FOR T = 0 TO 770: NEXT T
50 NEXT R
55 Z = PEEK(49168)
60 IF PEEK(49152) = 197 GOTO 80
70 GOTO 60
80 Z = PEEK(49168): POKE P, 238
90 FOR R = 1 TO 2
100 FOR T = 0 TO 770: NEXT T
110 NEXT R
120 POKE P, 243
130 FOR R = 0 TO 1000
150 IF PEEK(49152) = 205 THEN 190
170 NEXT R
180 GOTO 210
190 Z = PEEK(49168): A A+l
200 IF A < 5 THEN 170
210 POKE P, 245
220 FOR R = l TO 2
230 FOR T = 0 TO 770: NEXT T
240 NEXT R
250 GOTO 10
You should note that the keyboard Hag is reset before it is tested at
line 60. This clears any keyboard entries that are made during the
first IO-second period. You can remove this step, if you want the
Elm Street sensor to "remember" any cars that trip it during this
period.
The flag-detecting step at line 150 has been embedded in the overall
timing loop. This means that the flag is always being checked,
and that these flag-detecting steps must be figured into the overall
delay period. You can do this by testing various values of the delay
constant at line 130.
There are many other things that this program could do. For example,
many intersections have pedestrian control signals, left-hand
tum signals, :flashing lights, and other special features. You could
make the program as complex as you wish. In this situation, the
timing is not particularly critical. It wouldn't really matter if the
cars had to wait an extra second or two while a flag is tested. However,
periods of 10 or 20 seconds could be annoying to d1ivers. Keep
this in mind as you program. In some cases, the time requirements
will be so strict, and the time periods so short, that assembly-language
programming is dictated.