Move a square with the keyboard
The key state port polled once a frame for the four arrows, a direction kept in memory, and a square that keeps going until you steer it somewhere else.
A square you steer. The arrow keys set which way it is going and it keeps going that way on its own, coming back in at the opposite edge when it leaves the play area. Click the Screen panel first: the Screen only gets the keyboard when it has the focus, and a ring around it says so while it does.
A bouncing ball drew a picture that changed on its own. This one asks the keyboard, once per frame, what is being held down right now, and the answer changes what the next frame will look like.
You need to know: the "A bouncing ball" Example and the "The screen, keyboard and mouse through
ports" lecture. What is new here is port 0x21, which answers 1 while the key whose code is in b
is held down, and consumes nothing, so a key held for a second answers 1 every frame.
The four polls all use the same c, since the port never changes, and only b is reloaded between
them. in a, (c) is the form that has to be used here, because the key code travels on the high
half of the address bus, which is b, and the short in a, (n) form puts a there instead. The
codes are EASy68K's, the same table every language in this editor uses: left 0x25, up 0x26,
right 0x27 and down 0x28.
The keys do not move the square, they write dx and dy in memory, and the code under them moves
it. That separation is what makes the square keep going after you let go, and it is how anything
that moves in a game is written: the input decides the velocity, the frame applies it. The two lines
that clear the other step, xor a and the ld under it, are what keep the movement to four
directions; take those four pairs out and holding right and then up leaves both steps set, and the
square goes diagonally.
jp p, off_right is the one place a signed byte is read. dx is 6 or -6, and -6 is FA, whose
top bit is 1, so or a followed by jp p asks which way the square was going when it left the play
area, and that is what says which edge to bring it back in at. There is no jr form of p, so it
is a jp whatever the distance.
The y test needs two comparisons where the x test needs one, because the play area starts at 16
and not at the top of the Screen. The two text rows above it hold the title, which is printed once
before double buffering is turned on and then never touched again. Command 11 makes the off-screen
image start as a copy of what is on screen, and every frame clears only the rectangle below the
title, so those two rows survive for as long as the program runs.
Polling every frame is enough for keys held down. What port 0x21 does not tell you is that a key
was pressed again, which is why a game that wants one action per press keeps the last answer and
compares, or reads port 0x22, the code of the last key pressed.
Try changing the xor a under off_right to ld a, RIGHT. The square stops against the right edge
instead of coming back in at the left, which is the same one instruction doing clamping instead of
wrapping.