hornc / ctbasic Goto Github PK

Cyclic Tag System BASIC (like) compiler toy project with Tektronix 401x graphical output.

Python 100.00%

bitwise-cyclic-tag cyclic-tag tektronix esolang

ctbasic's Introduction

CT-BASIC

CTBASIC is a compiled Sinclair BASIC inspired language targeting a "fantasy console" architecture using the cyclic tag system computational model.

It compiles a reduced dialect of BASIC into one of the following compilation targets:

CT (Cyclic Tag) — a three symbol language {0, 1, ;}, or set of bitstring productions.
BCT (Bitwise Cyclic Tag) — a two symbol language {0, 1} encoding the above.
ABCT (Arithmetic Bitwise Cyclic Tag) — BCT encoded into a single integer.
Rule 110 elementary cellular automaton, using the "blocks of bits" construction developed and described by Matthew Cook.

This is an experimental project / work in progress. Details and usability are being worked out as features are added.

The idea is to capture something of the early days of practical programming (i.e. the BASIC era) while using low level cyclic tag systems for 'useful' programs.

The Fantasy Console

CTBASIC compiles to standard versions of the above cyclic-tag families, so any compiled program will run on all of them. However, in order to provide some user feedback, the CTBASIC architecture assumes a particular set of output conventions which distinguish a CTBASIC 'machine' from a plain cyclic-tag interpreter.

These differences only apply to I/O. The output conventions are side-effects and do not affect the underlying computation. Input conventions only affect starting (and re-starting) states, so also don't affect the fundamental computational process.

The CTBASIC machine I/O conventions are as follows:

Byte strings can be encoded and recognised within the data-string:
- 8 bit bytes are encoded within a 10 bit data-frame with start-bit 1 and end-bit 0.
- A string is a series of 10-bit frames beginning with the ASCII C0 STX character (0x02), and terminated by the ETX character (0x03).
- When a valid string is completed, (i.e. the stop-bit 0 of the ETX is appended to the right of the data-string) the complete string is sent to output.
Output is a serial byte-stream, with flexible destinations.
- The CTBASIC language has drawing commands which when compiled produce serial byte output that can be recognised by Tektronix 4010/4 compatible terminals.
- Non-graphical serial terminals are also intended to be supported for character output.
- Other byte-based output targets are also a possibility (e.g. audio, serial input to other devices).
Interactive mode:
- An optional execution mode whereby when the data-string becomes empty (the standard halt condition) the user is prompted for more input to replenish the data-string. Previous program output could perhaps give the user some guidance on how to binary-encode an appropriate input response.
- If a new data-string input is provided, the program resumes with the next cyclic production.
- If no new input is provided, the program halts.

General cyclic-tag input considerations

A standard feature of Cyclic Tag family of languages is that they require a non-empty, non-zero, data string to begin (and continue) execution.

If the initial data string is empty, or does not contain any 1 symbols, a program cannot possibly modify the data string, so no computation will occur.

This means that for any CT family program to perform a computation, an appropriate input data string MUST be provided. At minimum, this input data string can be a single 1. From this, a program can bootstrap any required data structure to allow it to accomplish its computation.

Specific user supplied variable input will need to be encoded in some fashion into the initial data string, the instructions for which will depend on the specific program being run. In general, there will need to be at least one 1 symbol for the program to have a chance of recognising the full range of user supplied inputs, including 'blank' input. Providing an input data-string beginning with a 0 symbol will in general prevent a program from functioning correctly (unless the expected behaviour is "do nothing").

The CTBASIC language

CTBASIC effectively provides ZX Spectrum BASIC style output macros to simplify forming output using the provided conventions.

PRINT, CHR$, CLS, PLOT, DRAW, and INK for output.
BIN, DATA, FILL, ZFILL, ASM for internal data.

All control flow is provided by the underlying cyclic tag mechanism.

Every command (output or memory writing) is conditional on there being a 1 at the leftmost bit of the current data-string.

All CLEAR commands (removing 1 or more bits from the data-string) are unconditional.

The entire program runs in an implicit loop until the data-string is empty.

The END command does not immediately end the program, but is an alias for CLEAR 10, which clears the data-string frame by frame, which if all data is correctly aligned on 0 stop-bits, can allow the program to cycle as many times as needed to clear the entire data-string without triggering any further output or effects. This however requires careful planning, and is not guaranteed to occur cleanly otherwise. It is a fragile convention.

Commands

See the Command list for implemented and aspirational commands and syntax.

See examples/ for how the commands can be used together.

Cyclic Tag Interpreter

CTBASIC comes with a simple Cyclic Tag interpreter to test CTBASIC programs behave as intended when compiled to the default Cyclic Tag dialect. It supports the input and output conventions, and will execute CTBASIC examples as intended (assuming correct mode flags and terminals are used).

Example usage

Compile Hello, World! example to cyclic tag:
```
./CTBASIC.py examples/HELLOWORLD.BAS
```
- output: 1000000100101001000010110010101011011000101101100010110111101001011000100100000010101011101011011110101110010010110110001011001000100100001010000101001000000110;;;;;;;;;;
Use the included cyclic tag interpreter ct.py to run the above and display output (input data = 1):
```
./ct.py <(./CTBASIC.py examples/HELLOWORLD.BAS) 1
```
- output: Hello, World!
Compile to arithmetic cyclic tag:
```
./CTBASIC.py -tABCT examples/HELLOWORLD.BAS
```
- output: 2188296472577726911166636231243756842502740360147865646454687653848030097758545005123757741056578902

Compile to rule 110 'blocks':

./CTBASIC.py -t110 examples/HELLOWORLD.BAS

Compile and run a simple loop demonstration:

./ct.py <(./CTBASIC.py examples/LOOP10.BAS)

Compile and run a standard terminal character 'animation' example:

./ct.py --hold 300 <(./CTBASIC.py examples/ANIM_FRAME_TEST.BAS)

Compile and run a (unary) input example:
```
./ct.py <(./CTBASIC.py examples/1_TO_10_OUTPUT.BAS) 11111111
```
- Vary the number of 1s as input between 1 and 1111111111 (10).

Using xterm, compile and run a static graphics example: 2D Utah teapot:

xterm -hold -t -e "./ct.py <(./CTBASIC.py examples/teapot.bas  ) 1"

Use xterm to display an animated rotating cube:

xterm -hold -t -e "./ct.py --hold 100  <(./CTBASIC.py examples/CUBE.BAS)"

Use interactive mode to play a simple (cheating) coin flip game:

./ct.py --interactive <(./CTBASIC.py examples/coin_flip.bas) 1

Compile the {YN, NYYN, 0, 0} example from Matthew Cook, 2009, A Concrete View of Rule 110 Computation 10.4204/eptcs.1.4, p.37:
```
./CTBASIC.py -t110 examples/Cook_1_4_example.bas
```
- output:

(
  'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAABAAAAAAAAAAABAAAAAAAAAAAAB',
  'CFG',
  'HIIJKHJIIIIIJLLLLK'
)

Run the above example as cyclic tag in debug mode to view the current production and data-strings at each step:
```
./ct.py <(./CTBASIC.py -tCT examples/Cook_1_4_example.bas) --debug
```
- output:

10;0110;;;;;	1
0;0110;;;;;1	11
;0110;;;;;10	110
0110;;;;;10;	10
110;;;;;10;0	100
10;;;;;10;01	1001
0;;;;;10;011	10011
;;;;;10;0110	100110
;;;;10;0110;	00110
;;;10;0110;;	0110
;;10;0110;;;	110
;10;0110;;;;	10
10;0110;;;;;	0
10;0110;;;;;	0
0;0110;;;;;1	0
;0110;;;;;10	0

ctbasic's People

Contributors

Stargazers

Watchers

ctbasic's Issues

Describe and document

Update readme with a description of what this thing is. The proof of concept basic idea seems to be working.

It mixes at least three obscure concepts that on the surface have very little to do with each other:

Cyclic tag systems (production rules of three symbols: { 0, 1, ;})
serial data transmission
Tektronix 4010/4014 vector graphics
Sinclair BASIC

Describe them, and explain why...

Frame in terms of a fantasy console architecture / virtual machine.

Underlying architecture and command set: cyclic tag (but with the flexibility to run on any cyclic tag equivalent implementation, hence the multiple compile targets)

Tag systems: https://en.wikipedia.org/wiki/Tag_system
and Cyclic tag: https://en.wikipedia.org/wiki/Tag_system#Cyclic_tag_systems

The virtual machine provides output via a memory data store convention which sends blocks of serial data to a hypothetical "display terminal" (VT100 or Tektronix (for lightweight serial graphical output) compatible).

A reduced BASIC-like command subset is used as a "high level" language which is compiled down to cyclic tag 'machine code'. The BASIC keywords really only provide shortcuts for encoding text and graphics into the required serial transmission format. (At least currently) flow control is performed directly as it would be in raw cyclic tag, with an implicit loop over the productions, and output only occurring if the leftmost bit of the current datastring is 1.

The purpose is to create a somewhat usable Turing complete 'computer' from a very simple foundation, and to produce a range of interesting code examples for cyclic tag systems, that will run in any cyclic tag context (down to rule 110 cellular automata), regardless of whether the output extension exists. Even if it is not implemented, the output will get encoded in the datastring memory, and the intended computations and intermediate data states will all be realized.

Add a command to change pen / line style

The Tektronix 401x has various vector style drawing modes:

Normal
Dotted
Dot-dash
Short-dash
Long-dash

To investigate:

Is there an erase vector drawing mode?
What does 'defocused' Z axis mean (Tektronix 4014 terminology), and does xterm support it to visually differentiate the lines?

Add a CT-BASIC command to select which mode / pen is to be used when drawing. (Default is Normal)

Suggested ZX-BASIC command to use:

INK <value>

https://zxbasic.readthedocs.io/en/docs/ink/

Allow, but ignore, BASIC line numbers

Accept line numbered code when parsing.

Line numbers don't really add anything (CT-BASIC code runs in an implicit loop), but allowing them in source would allow for ZX-BASIC / CT-BASIC polyglots.

Example: Utah teapot

Static image of the Utah teapot (2d)
Cleanly terminating

Using the patch data from here: http://www.sjbaker.org/wiki/index.php?title=The_History_of_The_Teapot

review context switching

relates to d901511

Now that all PRINT commands end with an ETX, the context transitions between GRAPHICS and TEXT output are not so important. Does the current context system still make sense?

Do PRINTs inside GFX behave as expected?

are CLEAR, BIN, and DATA treated correctly in all contexts?

What are the relevant cases?

Smooth CLS animation

Make animations smoother by changing the interpreter's handling of the -hold parameter.

Some kind of double buffering which minimises the amount of blank screen time that might arise if the screen is cleared while the next 'frame' is still being assembled.

Can't assume every program is an animation, nor even that every program with a CLS is an animation.

The -hold parameter could be replaced by an -fps, if that seems appropriate.

Strobing on CLEAR using Tek4010 emulator / How to do Tektronix animation properly?

Using https://github.com/rricharz/Tek4010 static graphics work perfectly:

tek4010 -noexit ./ct.py <(./CTBASIC.py examples/teapot.bas)

but the animations cause the screen to strobe white on CLEAR, which is very jarring.

tek4010 ./ct.py --hold 130 <(./CTBASIC.py examples/CUBE.BAS)

and

tek4010 ./ct.py --hold 130 <(./CTBASIC.py examples/ANIMTEST003.bas)

It's not because of the extra ANSI / RIS code I added (surprisingly), but it appears that the Tektronix ESC + FF causes the screen flash on reset, and that is the authentic behaviour -- which does not occur under xterm.

It looks like using ESC+FF between frames in not the standard way to run animations on a Tektronix display.

TODO:

Investigate https://github.com/rricharz/Tek4010/blob/master/animation.plt (an original clean running (no flicker / strobing) animation and see how that works.

Is is using "Write-Thru" mode, or specific erasing? I couldn't find clear descriptions of these features in the manual.

Some compiled ABCT behaves incorrectly when compared to CT output

./ct.py <(./CTBASIC.py examples/ANIMTEST001.bas) 1

vs.

../abct/abct-cli $(./CTBASIC.py examples/ANIMTEST001.bas -tABCT) 2 | cut -f5 | grep -v '^$'

Expect:
Both should produce identical output: endlessly repeating output
with 2 occurrences of

Tektronix 4010 animation in bitwise cyclic tag.

every iteration.

Actual:
Only A works as expected. B gives one-and-a-half iterations, then halts.

Either:

The ABCT compilation is incorrect and differs from the CT version
or
There is a bug in the ABCT interpreter which only triggers when the datastring is relatively large.

Test 1 by confirming CT:

10000001001010101000101100101010110101101011101000101110010010110111101011011100101101001010111100001001000000100110100010011000001001100010100110000010010000001011000010101101110010110100101011011010101100001010111010001011010010101101111010110111001001000000101101001010110111001001000000101100010010110100101011101000101110111010110100101011100110101100101010010000001011000110101111001010110001101011011000101101001010110001101001000000101110100010110000101011001110100101110010000001101;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;1000000100100011101010010100101011000100100110000010100000001001011110101101010010011000001010000000100011111010000001101;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;10000001001000110110100001100010000001101;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;10000001001010101000101100101010110101101011101000101110010010110111101011011100101101001010111100001001000000100110100010011000001001100010100110000010010000001011000010101101110010110100101011011010101100001010111010001011010010101101111010110111001001000000101101001010110111001001000000101100010010110100101011101000101110111010110100101011100110101100101010010000001011000110101111001010110001101011011000101101001010110001101001000000101110100010110000101011001110100101110010000001101;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;1000000100100011101010010110001011001100100101100010101001001001011000101100110010011001101010011100100011111010000001101;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;10000001001000110110100001100010000001101;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

converts to ABCT:

2725982173686371546601146872886478949676848343266687991455439775039246418566991564641072288886220641561220670417516878231337933182184221424474093486845123125288670924515227783347655713180738218612886808832567033405941261870209198197499335522520203793089647883525078726559522656322780833408305628209269451473841003952210357194804200927150864610020756488192140187415701229030023952457438960925517992085597157234115289733115229439541089867784618086421793464268100833257701933775660453143156550120230674427663139648925188894161008175666402137753021069691834098297645921724202153242602931770834033441974631172949352571451809476181649397847949984029722320500590490703749618295737914214793876366690181800306882307438513493238780477058778118173082607282107530831688589902108332787303323549563264682736128778696218029374094176060567774168320432597567000188014389411028017637004562908145413670119998291596935662982757593568414959308475684205073026516105003125317845476108577246127248204080999031261611309305491371624651666947921800000150020852464221004167616123654694382655473799426045366673852202654542189718580937791357707916724009533567448290513254034560106021425092655860067769504879958

For conversion comparison the compiled BCT is

111010101010101110101110111011101110101011101111101011101110111011111011101111101110111111101110101011101111111010111010111011111011111111101110111110111111101011101111101110101110111011111111101010101110101110101010101011101011111011101010111010111110101010101110101111101010111011101011111010101010111010111010101010101110111110101010111011101111101111111010111011111011101011101110111110111110111011101111101010101110111011111110111010101110111110111010111011101111101111111110111011111011111110101110101110101010101011101111101110101110111011111011111110101110101110101010101011101111101010111010111011111011101011101110111111101110101011101111111011111110111011111011101011101110111111101011111011101111101011101110111010111010101010101110111110101011111011101111111110101110111011111010101111101110111110111110101011101111101110101110111011111010101111101110101110101010101011101111111011101010111011111010101011101110111110101111111011101011101111111010111010101010101111101100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000111010101010101110101110101011111110111011101011101110101110111011111010101110101110101111101010101011101110101010101010111010111011111111101110111110111011101011101011111010101010111011101010101010101110101011111111111011101010101010111110110000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000111010101010101110101110101011111011111011101010101111101010111010101010101111101100000000000000000000000000000000000000000111010101010101110101110111011101110101011101111101011101110111011111011101111101110111111101110101011101111111010111010111011111011111111101110111110111111101011101111101110101110111011111111101010101110101110101010101011101011111011101010111010111110101010101110101111101010111011101011111010101010111010111010101010101110111110101010111011101111101111111010111011111011101011101110111110111110111011101111101010101110111011111110111010101110111110111010111011101111101111111110111011111011111110101110101110101010101011101111101110101110111011111011111110101110101110101010101011101111101010111010111011111011101011101110111111101110101011101111111011111110111011111011101011101110111111101011111011101111101011101110111010111010101010101110111110101011111011101111111110101110111011111010101111101110111110111110101011101111101110101110111011111010101111101110101110101010101011101111111011101010111011111010101011101110111110101111111011101011101111111010111010101010101111101100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000111010101010101110101110101011111110111011101011101111101010111011111010111110101110101110111110101011101110111010111010111010111011111010101110111110101111101011101011111010111110111011101011111110101110101011111111111011101010101010111110110000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000111010101010101110101110101011111011111011101010101111101010111010101010101111101100000000000000000000000000000000000000000

Example: rotating cube

Requirements:

(At least) 20 frames
pre-calculated rotating cube loop.
clean looping (data string never exceeds some finite length)

ANIMTEST001.bas broken on master

xterm -hold -t -e "./ct.py --hold 130 <(./CTBASIC.py examples/ANIMTEST001.bas)"

displays only the first frame at commit bded805

The examples work on the graphics branch and the recent (now deleted) ink branch.

Only output the rightmost (most recent) STX/ETX bounded group to prevent past output repetitions

This is possibly also an issue in https://github.com/hornc/abctag / inherited from there.

Some existing examples add offset bits to break frame alignment to work around this issue
e.g. https://github.com/hornc/CTBASIC/blob/master/examples/ANIMTEST001.bas
and
https://github.com/hornc/CTBASIC/blob/master/examples/1_TO_10_OUTPUT.BAS which has a comment explaining the workaround...

CHR$(n) -> CHR$ n

For consistency with the rest of the BASIC commands.

relates to #19

LOOP10.BAS example should cleanly terminate

After the 10th iteration the data string should be completely cleared.

Every other iteration will need to add n dummy bits since the clearing is unconditional.

Optimise interpreter to process whole productions at a time based on datastring, instead of bit-by-bit.

Instead of processing the program string symbol-by-symbol (current method), we can speed things up by dividing the program string into different length productions (by splitting on ;) and examining the datastring for runs of 0s followed by a 1 to find the next production to append to the right of the datastring and delete n bits from the left.

This means than we won't be doing processing for every command in an inactive production.

Interactive mode

In interactive mode: when the datastring is fully consumed (normally the HALT condition) the interpreter will prompt for input, and if any (non-empty) is received, it will continue to evaluate productions using the current program string.

PRINT separators `,;'`

-- allow these characters to appear inside quotes.
Finish PRINT improvements started in #21

Add some fuller PRINT examples, and tests.

ref: https://worldofspectrum.org/ZXBasicManual/zxmanchap15.html

PRINT separators: ,; '

newline by default
; suppress newline
, tab separator
' newline separator

update rotating cube example anim

Produce a better screen capture of the rotating cube example now that CLS doesn't trigger an INK change.

https://github.com/hornc/CTBASIC/blob/master/img/cube.gif

List bit/(frame?) length of each command in COMMANDS.md

In order to calculate CLEAR lengths correctly, the number of bits or frames each command adds to the data-string should be listed in the COMMANDS reference.

for example:

PRINT "<string>"

len(<string>) + 2 frames

(len(<string>) + 2) * 10 bits

PLOT and DRAW ~~have the same fixed length~~.

CLS's length depends on the exact clear commands used (which may change).

DATA will depend on the different formats... ASM also depends.

Figure out a useful notation.
Document

Related idea:

Some kind of block markup which tags a code block with an id,
code blocks intended to be the same length can be tagged with the same id
compiler can issue a warning if block-lengths don't match
CLEAR can take an id which will be substituted for the actual block length
basic arithmetic so the compiler can add id lengths

This will save the developer having to keep track of various code lengths and having to adjust corresponding CLEARs to get clean behaviour.

This feature isn't very BASIC-like. Investigate prior art.

Sinclair BASIC multiple commands on one line, separated by a colon

https://zxbasic.readthedocs.io/en/docs/syntax/#lines-and-sentences

Implement splitting lines by :

Consider adding the _ underscore to enable split lines to implement the full line / sentence BASIC model.

END = CLEAR 10 ?

Output frames all have 0 bits in position 10, if all other data structures could ensure every 10th bit was also 0, CLEAR 10 at the end of a program would cleanly exit without having to use large runs of ; clear symbols, like the CLEAR 600 code used in some early code examples.

END could be an alias for CLEAR 10 if this convention was followed, and END would have the effect of eventually terminating a program by reducing the datastring over multiple iterations, without triggering any new additions.