The update routine (UPDATES) of the in-between views a quarter turn passes through. HANDLE_LEFT_RIGHT starts a turn by giving the legs one of them (TURN_RIGHT_VIEWS, TURN_LEFT_VIEWS) and a count of one in bits 1-2 of +$0D, with bit 0 set for a right turn. While the count runs this routine only lets the robot fall; once it has run out it gives the legs the standing graphic of the new facing (TURN_RIGHT_ENDS, TURN_LEFT_ENDS), with a sound. So the in-between view is on the screen for two turns, and a walking robot stands still for three: the turn a turn starts (MOVE_PLAYER takes no step with an in-between graphic), and these two (measured in the simulator: a left turn from facing 1 showed graphic 26 for two turns and then 17 mirrored, facing 2; with walk held through a right turn U did not change until the turn after the new facing).

Like the legs' own routine (PLAYER_LEGS) it reads the controls, gives the legs the whole robot's height, 23, and the top none while he moves, keeps the top out of the collision scans meanwhile, and ends in that routine's tail: heights 12 and 11, and a redraw. Unlike it, it does not look at the killed bit of +$0D, nor count down the walk into a room.

The finishing branch means to take a step if walk is held: it comes into MOVE_PLAYER at MOVE_IF_WALKING, which tests bit 2 of C. But the sound it makes first (FOOTSTEP, at the entry that skips the frame test) counts C down to zero, so the step is never taken and gravity takes its full two units whatever is held. HANDLE_FORWARD keeps BC around the same sound.