Applesoft BASIC escape codes
Every escape that can be typed in Applesoft source, and the byte it stores. 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 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 everything else. Escapes are recognised in string literals and in REM, and because { and } are not characters this machine has, an escape is the only way either reaches a program. 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 — or printed with INVERSE and FLASH, which is what this BASIC has and the Apple II's has not. Filters can be prefilled with ?q= and ?cat= query parameters.
See also the Applesoft BASIC reference and file formats.
| Description | ||
|---|---|---|
{INV<c>} | 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>} | 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. |
Showing 3 of 3 escape codes