PEEK and POKE
This article needs additional citations for verification. (October 2015) (Learn how and when to remove this template message)
In computing, PEEK and POKE are commands used in some high-level programming languages for accessing the contents of a specific memory cell referenced by its memory address. These commands are particularly associated with the BASIC programming language, though some other languages such as Pascal and COMAL, have these commands as well. These commands are comparable in their roles to pointers in the C language and some other programming languages.
The PEEK and POKE commands were conceived in early personal computing systems to serve a variety of purposes, especially for modifying special memory-mapped hardware registers to control particular functions of the computer such as the input/output peripherals. Alternatively programmers might use these commands to copy software or even to circumvent the intent of a particular piece of software (e.g. manipulate a game program to allow the user to cheat). Today it is unusual to control computer memory at such a low level using a high-level language like BASIC. As such the notions of PEEK and POKE commands are generally seen as antiquated.
The terms peek and poke are sometimes used colloquially in computer programming to refer to memory access in general.
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 registersEdit
The address locations that are POKEd or PEEKed at 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 (which makes software implementations of powerful machine code monitors and debugging/simulation tools possible). As an example of a POKE-driven support chip control scheme, 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
POKE 755, 4
The difference between machines, and the importance and utility of the hard-wired memory locations, meant that "memory maps" of various machines were important documents. A canonical example is Mapping the Atari, which started at location zero and mapped out the entire 64 kB memory of the Atari systems location by location.
Pre and non-PC computers usually differ in 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 cheatsEdit
In the context of games for many 8-bit computers, users could 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.
POKE 47196, 201
Magazines such as Your Sinclair 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 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).
16-bit PEEKs and POKEsEdit
As most early home computers running BASIC used eight-bit processors, single PEEK or POKE values were between 0 and 255. Setting or reading a 16-bit value on such machines therefore required two
PEEK or two
POKE as well as some algebra–typically, something like
PEEK A+256*PEEK(A+1) in order to read a 16-bit integer value at address A, while something like
POKE A,(V AND 255) followed by
POKE (A+1),TRUNC(V/256) would be used to write the 16-bit integer V at address A.
However, BASIC on 16- or 32-bit machines, such as IBM PCs or Commodore Amigas often had additional commands, such as
DPOKE to read and set a 16-bit value in a single operation. Other 16-/32-bit machines, such as the Sinclair QL, had
POKE_W/POKE_L for reading and setting 16- and 32-bit values respectively, while the Atari ST series used the traditional names but had the possibility to define 8-/16-/32-bit memory segments and addresses that determined the size. Also, some 8-bit machines had BASIC dialects with 16-bit PEEK and POKE, such as the East-German "Kleincomputer" KC85/1 (aka Z9001) and KC87, manufactured by VEB robotron - Meßelektronik "Otto Schön", which implemented
Peek and Poke in other BASICsEdit
North Star Computers, a vendor from the early 1980s, offered their own dialect of BASIC with their NSDOS operating system. Concerned about possible legal issues, they renamed the commands
FILL. There were also BASIC dialects that used the reserved words MEMW and MEMR instead.
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"Edit
"POKE" is sometimes used 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 1970s and early 1980s. 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 the opcode values into memory. Doing much low-level coding like this usually came from lack of access to an assembler.
Cheats for eight-bit video games were sometimes referred to as pokes (see "POKEs as cheats" above).
- "PEEK". Microsoft QuickBasic 4.5 Advisor. Microsoft. 1990. Retrieved 2007-12-28.
- "POKE". Microsoft QuickBasic 4.5 Advisor. Microsoft. 1990. Retrieved 2007-12-28.
- Dave and Laura Yearke, "Turbo BASIC Command Set", Western New York Atari Users Group
- Kühnel, Claus (1987) . "4. Kleincomputer - Eigenschaften und Möglichkeiten" [4. Microcomputer - Properties and possibilities]. In Erlekampf, Rainer; Mönk, Hans-Joachim (eds.). Mikroelektronik in der Amateurpraxis [Micro-electronics for the practical amateur] (in German). 3 (1 ed.). Berlin: Militärverlag der Deutschen Demokratischen Republik, Leipzig. pp. 218, 232, 236. ISBN 3-327-00357-2. 7469332.