Integer BASIC escape codes

Every escape that can be typed in Apple I or Apple II source, and the byte it stores. The two machines share a BASIC and not a character generator, so each row here is badged with the machine it belongs to, and only the {0xNN} raw-byte escape is common to both. Escapes are recognised in string literals and in REM, and because { and } are not characters either machine has, an escape is the only way either reaches a program. Filters can be prefilled with ?q= and ?cat= query parameters.

On the Apple I

The character generator holds 64 shapes — ASCII 0x20–0x5F, which this machine carries with bit 7 set, so 0xA0–0xDF are the printable codes — and every one of the other 192 bytes is written as a {0xNN} raw-byte escape. There are no named escapes at all: no colour, no cursor controls and no graphics characters. The three codes the machine itself acts on are listed so a program can be written against them, but they keep the {0xNN} spelling every other non-printing byte has, because the machine never gave them names either.

On the Apple II

The same 64 shapes, and the top two bits of a screen byte pick the video mode that shape is drawn in rather than picking another shape. So there are two named escapes, {INV<c>} and {FLASH<c>}, for the inverse and flashing forms of any character, and a {0xNN} raw-byte escape for the second normal-video run. Inside a program line only the codes with bit 7 set can be written: below 0x80 a byte is a token there, so the inverse and flashing forms are POKEd to the text page or carried in a data block instead.

See also the Integer BASIC reference and file formats.

		Description
{INV<c>}Apple II only	0x00-0x3F	The character <c> drawn in inverse video - black on white - where <c> is any of the 64 characters the machine has: {INVA} is an inverse A, {INV } an inverse space. These are screen bytes and nothing else: POKE one into the text page, since a byte below 0x80 inside a program line is a token rather than a character - or set the monitor output mask with POKE 50,63, which draws everything printed afterwards in inverse until POKE 50,255.
{FLASH<c>}Apple II only	0x40-0x7F	The character <c> drawn flashing, alternating between normal and inverse about four times a second. The video counter drives the flash, so it costs the program nothing to leave one on screen. POKE these into the text page as well, or print them by setting the output mask with POKE 50,127.
{0xNN}	any	Any byte with no text form, as two hex digits. On the Apple I that is everything outside 0xA0-0xDF - the whole of 0x00-0x9F and 0xE0-0xFF - and the display discards a code it has no glyph for rather than guessing at one, though a string can still hold it. On the Apple II it is 0x80-0x9F and 0xE0-0xFF, the second of the two normal-video runs: they draw exactly the shapes 0xA0-0xDF draw and the machine itself never produces one, so they keep an escape rather than a duplicate spelling that would not round-trip. Recognised in string literals and in REM; { and } are not characters either machine has, so an escape is the only way either reaches a program at all.
{0x83}Apple I only	0x83	CTRL-C. Sent by the keyboard as the letter with bits 5 and 6 cleared, and the code that breaks a running program - although so does every other key, because BASIC takes whatever is waiting and reports STOPPED AT.
{0x8D}Apple I only	0x8D	Carriage return: the start of the next line. The only code the display decodes at all - there is no line feed, no backspace, no clear-screen and no cursor addressing, so this is the whole of the line discipline.
{0x9B}Apple I only	0x9B	Escape. The monitor reads it as "abandon the line being typed"; the display prints nothing for it.

Showing 6 of 6 escape codes