PEEK and POKE
This article includes a list of general references, but it lacks sufficient corresponding inline citations. (May 2010) |
This article relies largely or entirely on a single source. (May 2010) |
This article possibly contains original research. (May 2010) |
In computing, PEEK is a BASIC programming language extension used for reading the contents of a memory cell at a specified address.[1] The corresponding command to set the contents of a memory cell is POKE.[2]
Statement syntax
The PEEK function and POKE command are usually invoked as follows, either in direct mode (entered and executed at the BASIC prompt) or in indirect mode (as part of a program):
integer_variable = PEEK(address)
POKE address, value
The address and value parameters may contain complex expressions, as long as the evaluated expressions correspond to valid memory addresses or values, respectively. A valid address in this context is an address within the computer's address space, while a valid value is (typically) an unsigned value between zero and the maximum unsigned number that the minimum addressable unit (memory cell) may hold.
Memory cells and hardware registers
The address locations POKEd to or PEEKed from may refer either to ordinary memory cells or to memory-mapped hardware registers of I/O units or support chips such as sound chips and video graphics chips, or even to memory-mapped registers of the CPU itself (making possible the software implementation of powerful machine code monitors and debugging/simulation tools). As an example of POKE-driven support chip control, the following POKE command is directed at a specific register of the Commodore 64's built-in VIC-II graphics chip, which will make the screen border turn black:
POKE 53280, 0
Pre and non-PC computers usually differ as to the memory address areas designated for user programs, user data, operating system code and data, and memory-mapped hardware units. For these reasons, PEEK functions and POKE commands are inherently non-portable, meaning that a given sequence of those statements will almost certainly not work on any system other than the one for which the program was written.
POKEs as cheats
In the context of games for many 8-bit computers, it was a common practice to load games into memory and, before launching them, modify specific memory addresses in order to cheat, getting an unlimited number of lives, immunity, invisibility, etc. Such modifications were performed using POKE statements. The Commodore 64, ZX Spectrum and Amstrad CPC also allowed players with the relevant cartridges or Multiface add-on to freeze the running program, enter POKEs, and resume.
For example, in Knight Lore for the ZX Spectrum, immunity can be achieved with the following command:
POKE 47196, 201
In this case, the value 201 corresponds to a RET instruction, so that the game returns from a subroutine early before triggering collision detection.
Magazines such as Microhobby published lists of such POKEs for games. Such codes were generally identified by reverse-engineering the machine code to locate the memory address containing the desired value that related to, for example, the number of lives, detection of collisions, etc.
Using a 'POKE' cheat is more difficult in modern games, as many include anti-cheat or copy-protection measures that inhibit modification of the game's memory space. Modern operating systems may also enforce virtual memory protection schemes to deny external program access to non-shared memory (for example, separate page tables for each application, hence inaccessible memory spaces).
Peek and Poke in BBC BASIC
BBC BASIC, used on the BBC Micro and other Acorn Computers machines, did not feature the keywords PEEK and POKE but used the question mark symbol (?), known as query in BBC BASIC, for both operations, as a function and command. For example:
> DIM W% 4 : REM reserve 4 bytes of memory, pointed to by integer variable W%
> ?W% = 42 : REM store constant 42; equivalent of 'POKE W%, 42'
> PRINT ?W% : REM print the byte pointed to by W%; equivalent of 'PRINT PEEK(W%)'
42
32-bit values could be POKEd and PEEKed using the exclamation mark symbol (!), known as pling, with the least significant byte first (little-endian). In addition, the address could be offset by specifying either query or pling after the address and following it with the offset:
> !W% = &12345678 : REM ampersand (&) specifies hexadecimal
> PRINT ~?W%, ~W%?3 : REM tilde (~) prints in hexadecimal
78 12
Strings of text could be PEEKed and POKEd in a similar way using the Dollar sign ($). The end of the string is marked with the Carriage return character (&0D in ASCII); when read back, this terminating character is not returned. Offsets cannot be used with the dollar sign.
> DIM S% 20 : REM reserve 20 bytes of memory pointed to by S%
> $S% = "MINCE PIES" : REM store string 'MINCE PIES', terminated by &0D
> PRINT $(S% + 6) : REM retrieve string, termined by &0D started at S% + 6 bytes
PIES
Generic usage of "POKE"
"POKE" is sometimes used as a generic term to refer to any direct manipulation of the contents of memory, rather than just via BASIC, particularly among people who learned computing on the 8-bit microcomputers of the late 70s and early 80s. BASIC was often the only language available on those machines (on home computers, usually present in ROM), and therefore the obvious, and simplest, way to program in machine language was to use BASIC to POKE opcode values contained in DATA statements into memory. Doing much low-level coding like this usually came from lack of access to an assembler.
An example of the generic usage of POKE and PEEK is in traditional Visual Basic for Windows, where DDE can be achieved with the LinkPoke keyword.
Cheats for 8-bit video games were sometimes referred to as pokes, as they often worked by poking a value, such as number of lives, directly into memory.