Currently, the Å-machine character set looks like this (all numbers in hex):
- 00 - 19: control characters (00 and 01 are guaranteed not to be characters, some others represent special keypresses)
- 20 - 7E: the ASCII printable characters
- 7F: reserved (used as an escape code in the string-encoding mechanism)
- 80 - FF: defined by the game
This means that each game can have at most 128 non-ASCII characters. This is enough for most games using the Latin alphabet, but not enough for Japanese. So it would be nice to raise this limit, even if it can't feasibly be removed entirely.
The space character will always need to be in the character set (because of the Å-machine's built-in spacing mechanisms), but allowing 21-7E to be redefined would add 94 extra codepoints—a big help for Japanese, if not enough for Chinese. This can also be done in a backwards-compatible way: there's a byte in the LANG chunk specifying how many custom characters the game wants, and if it's more than 128, the ASCII characters can be booted out to make room.
(To consider: the PRINT_VAL instruction may need to print [, ], $, and #, though not @ on Å-machine. How special char codes are printed is up to the interpreter; I should check if the existing terps use \ for it. Should the compiler be responsible for keeping these in the charset? Should that be part of the spec? Losing four more codepoints isn't the end of the world.)
Currently, the Å-machine character set looks like this (all numbers in hex):
This means that each game can have at most 128 non-ASCII characters. This is enough for most games using the Latin alphabet, but not enough for Japanese. So it would be nice to raise this limit, even if it can't feasibly be removed entirely.
The space character will always need to be in the character set (because of the Å-machine's built-in spacing mechanisms), but allowing 21-7E to be redefined would add 94 extra codepoints—a big help for Japanese, if not enough for Chinese. This can also be done in a backwards-compatible way: there's a byte in the LANG chunk specifying how many custom characters the game wants, and if it's more than 128, the ASCII characters can be booted out to make room.
(To consider: the PRINT_VAL instruction may need to print
[,],$, and#, though not@on Å-machine. How special char codes are printed is up to the interpreter; I should check if the existing terps use\for it. Should the compiler be responsible for keeping these in the charset? Should that be part of the spec? Losing four more codepoints isn't the end of the world.)