readkey() returns an int with two pieces of data in it. The lowest byte is the ASCII code of the keypress that was in the keyboard buffer. This is the char that you would put in a c-style string (ie a const char*)
The next byte is the actual scancode read off the keyboard. You access the second byte by shifting the integer over 1 byte, hence the readkey() >> 8
The scancode differs from the ASCII code in that the scancode represents a key on the keyboard whereas the ASCII char represents a (usually) printable character. IE KEY_B is the scancode but the char is either 'b' or 'B' depending on if shift or caps lock was active when KEY_B was entered into the buffer.
Now the whole keypressed() and readkey() system refers to the keyboard buffer. A keypress is entered into the buffer whenever someone presses and then releases a key. This is the behavior you can capture by hooking into the keyboard_callback function.
But if you press a key and hold it down, the operating system takes over and starts generating repeated keypresses for that character. For every repeat the OS decides on, it enters that key into the keyboard buffer as if the user had pressed and released the key.
There's two aspects to the key repeat - the delay and repeat rate. The delay is how long you have to hold down the key before the OS starts generating repeats. The rate is... the rate! How many keypresses the OS generates per second.
I think a common setup in the Windows control panel is a 250 ms delay and 30 repeats per second. But using set_keyboard_rate( delay, rate ) in your Allegro app you can customize it to a wide range of possibilities.
God, I type too much. Hopefully that answered your question.