String literals in GCBASIC source now support escape sequences, allowing arbitrary
byte values to be embedded directly in strings without workarounds. This new capability removes the need to use CHR() which is expensive in terms of RAM.
From build 1603.
Supported Sequences
Sequence
Value
Example
\xNN
Hex byte, exactly 2 digits (0-9, A-F)
\xDC → Chr(220)
\0xNN
Hex byte, exactly 2 digits (0-9, A-F)
\0x1F → Chr(31)
\NNN
Decimal byte, exactly 3 digits (0-9)
\223 → Chr(223)
\r
Carriage return
Chr(13)
\n
Newline
Chr(10)
\t
Tab
Chr(9)
\\
Literal backslash
Chr(92)
\"
Literal double-quote
Chr(34)
Rules
Hex digits must be uppercase or lowercase A-F; exactly 2 are required.
Decimal values must be exactly 3 digits and in the range 000-255.
An unrecognised escape sequence produces a compile-time error with file and line number.
Example
tmpstring = "\223C\\"
Produces a 3-byte string: Chr(223), C, \ — stored in the string table as:
StringTable2:.DB3,223,67,92
Risk
Backslashes in existing string literals will be interpreted as escape sequences.
Code such as "C:\Users\temp" or any string containing \n, \t, or \\
will silently change meaning or produce a compile error.
It is recommended to audit existing source files for strings containing \ and change to \\
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
New: String Escape Sequences
Overview
String literals in GCBASIC source now support escape sequences, allowing arbitrary
byte values to be embedded directly in strings without workarounds. This new capability removes the need to use CHR() which is expensive in terms of RAM.
From build 1603.
Supported Sequences
\xNN\xDC→ Chr(220)\0xNN\0x1F→ Chr(31)\NNN\223→ Chr(223)\r\n\t\\\"Rules
Example
Produces a 3-byte string:
Chr(223),C,\— stored in the string table as:Risk
Backslashes in existing string literals will be interpreted as escape sequences.
Code such as
"C:\Users\temp"or any string containing\n,\t, or\\will silently change meaning or produce a compile error.
It is recommended to audit existing source files for strings containing
\and change to\\The impact of this change ... save 42 bytes of RAM! Plus a tweak to the DS18B20 library saves even more RAM.
I spotted this yesterday and thought why not implement escape characters and avoid using CHR()
Enjoy
/*
Compiling: I2C_1602.gcb
Program compiled successfully (Compile time: 1.75 seconds)
Summary:
Compiled:
Program lines: 183
Subroutines: User: 0 ; System: 34 of 495 ; Total: 34
Chip resource usage:
Program Memory: 1546/4096 words (37.74%)
RAM: 124/1024 bytes (12.11%)
OSC: 16Mhz
now
GCBASIC (2026.06.17 (Windows 64 bit) : Build 1602)
Compiling: I2C_1602.gcb
Program compiled successfully (Compile time: 1.75 seconds)
Summary:
Compiled:
Program lines: 183
Subroutines: User: 0 ; System: 32 of 495 ; Total: 32
Chip resource usage:
Program Memory: 1506/4096 words (36.77%)
RAM: 47/1024 bytes (4.59%)
OSC: 16Mhz