A bouncing ball
A ball that bounces off all four edges, drawn off screen and shown a whole frame at a time, paced by the delay task instead of by how fast your machine is.
A ball crosses the screen and turns round at every edge, and a bar along the top grows with the time the program has been running. It never stops on its own: press Run, watch it, and press Stop when you have had enough.
Drawing shapes on the screen drew one picture and ended. This one draws a new picture forty or fifty times a second, which brings two problems with it: the reader must never see a half drawn frame, and the ball must move at the same speed whatever the machine underneath is doing.
You need to know: the "Drawing shapes on the screen" Example and the "The screen, keyboard and mouse through traps" lecture. What is new here is double buffering, task 92 mode 17 sends every drawing to an off screen image and task 94 shows the whole of it at once.
The frame is four steps and they are always in this order: clear the image, draw everything on it,
show it with task 94, and let some program time pass. Task 11 with d1.w = $FF00 is the clear, and
it wipes text and graphics together. Without mode 17 the same four steps would draw straight onto
what you are looking at, and you would watch the screen go black and the ball appear, forty times a
second, which is what flicker is.
Task 8 answers with the hundredths of a second since the run started, and task 23 lets that many
hundredths pass before the next instruction runs. The two are the same clock, and it is program
time: the editor stays responsive while task 23 waits, so Stop still answers, and inside a testcase
the wait finishes at once so a test of an animation does not take a minute. The bar at the top is
that number turned into a width, wrapped at 640 with a divu whose remainder is what the program
keeps.
The ball's position and step are two words each in memory, and the four edges are four comparisons.
neg.w stepx flips the sign of the step where it lies in memory, which turns the ball round without
either branch knowing which way it was going. LIMITX equ 640-40 is the largest x the ball's left
edge may have, worked out by the assembler out of the screen width and the ball's size.
Try changing move.l #2, d1 under task 23 to move.l #10, d1. The ball crawls, because it moves
five pixels per frame and the frames are now a tenth of a second apart, while the bar at the top
races: it is drawn from program time, and program time is what you just made pass five times faster
per frame.