Here is an example that demonstrates the keyboard buffer and the contents of 198:
for n=0 to 1000:print chr$(19);peek(198):next
Note: chr$(19) is the control character for "home"; it ensures the reported count is always printed at the upper left-hand corner of the screen.
This loop will go on for about eight seconds, whilst reporting the number of characters waiting in the keyboard buffer in the corner of the screen. As it runs, try typing something on the keyboard, and notice how the number of chars rises by one for each keystroke, and when the loop comes to an end, whatever you type is "spat out" right underneath the "ready." prompt.
If you type a lot, you'll see that this "counter" won't go beyond 10, which is the default maximum of chars (see address 649): Try the loop again, this time typing the alphabet to beyond the letter J (tenth in the row) – at the end of the loop, only the first ten entries (A thru J) are "released" from the keyboard buffer.
Here is another example, demonstrating a useful application of writing to address 198: Putting a zero byte in this address "fools" the system to think that no entries were made at all.
for n=0 to 1000:next:poke 198,0
This loop takes a tad over a second to complete: If you make a few keystrokes in that second, your entries will not appear underneath the "ready." prompt, because the POKE at the end of the command line "cancels" your entries.
This is useful in situations where the computer "thinks" long and hard (several seconds where, from the user's perspective, apparently "nothing" happens), and then asks the user an important question. If the surprised user tried to type something during the apparent "pause", these entries may inadvertantly be accepted as the answer to the question. To avoid this as a programmer, one should put a zero byte in address 198 inbetween displaying the question on screen, and awaiting answers in the form of keyboard entries acquired through the standard buffer system.