| Function | Meaning | |---|---| | [**BANK** n] **PEEK** o | Returns the byte at address o or if used with the optional BANK, the byte at offset o of bank n | | [**BANK** n] **PEEK$** (o,len\|t) | Reads memory region of length len stored in the addresses beginning with o and stores it in a string –or– Reads the string terminated with a user specified terminator t beginning with address o. With the optional BANK reads offset o of bank n. | | **PI** | Returns and approximation of π (3.14159265...) | | **POINT** (x,y) | Retruns 1 if the pixel at (x,y) is ink colour. 0 if it is paper colour. | | **REG** n | Reads state of Next Register n | | **RND** [n\|i] | Returns the next pseudorandom number n in the range from 0 to 1 –or– the next pseudorandom integer number in the range of 0 to i-1 | | **SCREEN$** (x, y) | Returns the character that appears, either normally or inverted, on the display at line x, column y. | | **SGN** x | Signum; the sign (-1 for negative, 0 for zero or +1 for positive) of x. | | **SGN** {i} | Returns a signed 16-bit integer from integer expression i | | **SIN** x | Returns the sine of x in radians. | | **SQR** x | Returns the square root of x. | | **STR$** x | Returns the string of characters that would be displayed if x were printed. | | **TAN** x | Returns the tangent of x in radians. | | [**BANK** n] **USR** o | Calls the machine code subroutine whose starting address is o. With optional BANK does the same for offset o in bank n. On return, the result is the contents of the bc register pair. | | **USR** l | The address of the bit pattern for the user-defined graphic corresponding to character l. | | **VAL** f | Evaluates string f (without its bounding quotes) as a numerical expression. | | **VAL$** f | Evaluates string f (without its bounding quotes) as a string expression. | ### The Decimal System Most European languages count using a more or less regular pattern of tens – in English, for example, although it starts off a bit erratically, it soon settles down into regular groups: twenty, twenty one, twenty two, . . . twenty nine\ thirty, thirty one, thirty two, . . . thirty nine\ forty, forty one, forty two, . . . forty nine This follows from using Arabic numerals, which have ten symbols **0** – **9**, in a placeholder system where the position of each digit is multiplied by a power of ten. The reason for using ten as the basis of numbers is that we happen to have ten fingers. ### The Binary System Instead of using the *decimal* system, with *ten* as its *base*, computers use a system called *binary*, based on two values **0** and **1**. Like humans have ten fingers, computer circuits have two states; low-voltage or off (**0**) and high-voltage (**1**). The two binary digits are called *bits*, and a bit is either **0** or **1**. Computers therefore write **10** to represent **2**, **100** to represent **4**, **1000** to represent **8**, and so on for the powers of **2**. It is customary to "pad out" binary numbers with leading zeroes so that they always contain at least four bits, called a *nibble* – for example, **0000**, **0001**, **0010**, **0011** (representing **0** to **3** *decimal*). The reason for doing this is that it makes it easy to represent long binary numbers more compactly using hexadecimal as we will see further below. Throughout this manual we've written binary numbers either with the suffix of a lower case **b** or with the prefixes of **@** and **BIN** as supported by the *NextBASIC* Integer expression evaluator. Regardless of how useful it is to write numbers in the way computers understand them, we have the obvious problem of representing them on paper: it's much easier for us to write and understand **65535** + **65534** than **1111111111111111b** + **1111111111111110b**. ### The Hexadecimal System Binary numbers quickly become unwieldly because even modest quantities require long strings of **0**s and **1**s to represent them. This is a natural result of only using two symbols to