Undocumented 8.1 commands

At the time of this revision for Color 64 v8.1a, there are notably several ML related commands and variables that are not documented as well as some basic shortcuts and appear to have been introduced from the 8.1 upgrade. I find that comparing 8.0 code with 8.1 helps you along in figuring out what these undocumented items perform. Below are some of my notes and observations of what the code was in 8.0 and the observed shortcuts implemented in 8.1 Please note it is a work-in-progress and I don’t have all the answers (yet), so some of this is just “observation” without any conclusion!

Getting to understand some of the modified BASIC can be easy. If you have the ML loaded into your system, you can write your own program to test out the modified BASIC by having your first line call the ML routine: SYS49923

10 SYS49923
20 #"Test of program"
30 etc....

Below are some of my observations.

Topic	Found in
Simple Addition	All overlays Color 64 allows simple addition without using < var >=< same var >+< value > So "a=a+12" can alternately just be: "a+12". This only works with numbers (not strings) and other times, this just fails completely. Buyer beware.

Topic

Found in

Branch Shortcuts

√bbs.init Example 8.0 8.1 1 2 3 4 Conclusion: “[“ and “@” are used for loops with “[“ being the starting position and “@” being the condition that will cause the function to return to the starting point of the loop. Also note in line 8220 how the “RETURN” statement moved from line 8230 up into the 8220 loop in version 8.1 (example 2), indicating that it will execute the return if a$ <> “” and a$ <> home key. [ starts loop @ loop condition – goes back to bracket when used after “@”, consider an “ELSE” statement in this loop (example 2) ] breaks loop condition (Example 3) A break “]” can occur as part of an IF statement to exit prior to “@” for loop (example 4)

Topic	Found in
Use of "THEN" in IF	all Example 8.0 8.1 1 Conclusion: “then” statements are not required for “if/then” – if <condition> <action> is legal in most cases.

Topic

Found in

.36

√bbs.init Example 8.0 8.1 1 Conclusion: Undetermined, although notice line in 8.0 version that line 13645 has been dropped for the 8.1 variant. This command only occurs on this line in the overlays as part of the command prompt. When I dropped everything in line 13640 and just had “.36:return”, there was no box printed (of course), but the command entry functioned normally. This was also true if I just omitted everything except “return” – so I’m not sure what “.36” brings to the table.

Topic

Found in

.31 and !55

√bbs.msgs Example 8.0 8.1 1 Conclusion: .31 – Message-Aware Disk Input (Version 8.1) Earlier documentation listed the ML command .31 as "not used." Analysis of Version 8.1 confirms this is incorrect. In Color 64 v8.1, the .31 command is actively used within message-handling overlays (notably BBS.MSGS) and functions as a specialized form of disk input. It replaces the earlier .01 disk input command used in Version 8.0 when scanning and reading private messages. Comparison: Version 8.0 vs Version 8.1 8.0 8.1 Message scanning used: .01 After each read, BASIC code manually checked for a message delimiter: IF @0 = CHR$(14) THEN .... The byte {0E} (CHR$(14)) acted as the message record separator. When this character was encountered, the system incremented or decremented message counters, control flow moved to the next message record, and the loop continued scanning until completion. The delimiter (end of message) detection was handled explicitly in BASIC. In Version 8.1, .01 is replaced in message routines by: .31. The .31 command performs the disk input operation and internally detects the message delimiter. Instead of BASIC checking @0 = CHR$(14), Version 8.1 uses the ML variable IF !55 THEN .... When !55 becomes non-zero, the system has reached the end of the current message record, message counters are updated, and control moves to the next message or exits the loop. Delimiter detection is now handled inside the ML routine rather than in BASIC. !55 – Message Record Delimiter Flag !55 is an ML variable introduced in Version 8.1 that serves as a message record boundary flag. It is set automatically by .31 when the message delimiter byte (previously tested as CHR$(14) in Version 8.0) is encountered. !55 = 0 → No delimiter encountered !55 ≠ 0 → End of message record reached When !55 is detected: The current message scan loop updates counters The system transitions to the next message record Display or processing routines advance accordingly

Topic

Found in

.38 / .39 / .40 / .41 and “;” variables

√bbs.msgs Example 8.0 8.1 1 (current message vs high message): (current message vs high message): 2 (reading message): (reading message): 3 (storing message): (storing message): Message Relink Commands in v8.1 Command Purpose .38 Initialize / bind relink iterator operands .39 Perform iterator scan step .40 Advance iterator (skip / continue) .41 Finalize relink process .38 – Relink Iterator Initialization (v8.1) The .38 command was introduced in Color64 v8.1 as part of the internal message relinking system and is the entry point of the entire process. It does not perform file I/O directly and does not read or write messages itself. Instead, it initializes and binds internal machine-language structures used by the message relinking iterator. It is designed to be used as the first step in a command sequence: .38 → .39 → .40 / .41 This sequence replaces the more BASIC-driven record scanning logic found in v8.0. What .38 Does Binds specific BASIC variables/arrays to ML-side descriptors Registers operands for the relink iterator Initializes scratch registers used by subsequent .39 operations Prepares the ML environment for scanning and linking old message records In BBS.MSGS, this binding typically associates: Slot 0 → MN (message number) Slot 1 → MR% (message read flags array) The ML iterator then uses internal scratch registers such as: ;0K ;1K ;0F These are later examined by BASIC to determine loop control and branching. In v8.0, message scanning and linking logic was performed directly in BASIC, including character comparisons and explicit loop control. In v8.1, this logic was moved into machine language for speed and structural cleanliness. BASIC now acts primarily as a decision layer while ML handles the iteration mechanics. Important Notes .38 must precede .39 in relink routines .38 does not itself advance or scan records It prepares the ML environment used by the iterator It is not a general-purpose file command It is specific to the message relinking system Summary The .38 command initializes the v8.1 message relink iterator by binding BASIC variables to ML-side structures. It marks the transition from the BASIC-driven record scanning model of v8.0 to the ML-driven iterator model of v8.1. It should be understood as a setup command rather than an action command.

Topic	Found in
if...£	√bbs.msgs Example 8.0 8.1 1 Observation: Observe the 8.1 authors reversed the checks in variable comparisons as the conditions, with end-result being the same. Conclusion: Serves as an “not” function “(lv is not less than cm%(2,2) and lv not less than cm%(29,2) and fr does not equal 1, then print (P)rivate)” Another example:

Topic	Found in
@	√bbs.msgs Example 8.0 8.1 1 Conclusion: Seems to serve as an “if” keyword - but testing this theory in a traditional sense resulted in a syntax error.

Topic	Found in
[var$]	√bbs.msgs Example 8.0 8.1 1 Conclusion: Can serve as an empty variable check (null)

Topic

Found in

.32

√bbs.msgs The .32 command appears in v8.1 message handling code immediately before operations that read or process an individual message record. Unlike .31 (which performs record scanning) and .38 (which initializes the relink iterator), .32 establishes the active message context for the current record. It functions as a message-record “attach” or “open” operation. Observed Behavior in BBS.MSGS (v8.1) In the message display and processing routines, .32 appears: After a message number has been determined Before message text is accessed Before read-status flags are modified Before counters such as remaining private messages are updated The command does not itself loop or branch. It prepares the ML side so that subsequent operations operate on the correct message record. Functional Interpretation Based on comparison with v8.0 behavior: 8.0 8.1 BASIC manually calculated offsets BASIC performed sequential file positioning BASIC handled record boundaries .31 scans .32 selects/attaches the current record ML maintains internal pointers to that record BASIC then performs logic based on ML flags Therefore: .32 most likely performs one or more of the following internally: Positions the file pointer to the current message record Loads message header metadata into ML buffers Prepares message body reading context Updates internal state registers used by !55 and related flags Relationship to Other Commands Command Role in Message Processing .31 Scan for next message record boundary .32 Attach/open current message record .38 Initialize relink iterator .39 Execute relink scan step .40 Advance relink iterator .41 Finalize relink Important Notes .32 does not itself advance to the next message. It operates on the message selected by the iterator or scan routine. It prepares the environment for message content access. It is specific to message-handling routines and does not appear to be a general-purpose file command. Summary The .32 command establishes the active message record context in Color64 v8.1. It represents the shift from BASIC-managed record positioning (v8.0) to ML-managed record attachment (v8.1). It should be understood as a message “open/attach” primitive used internally by BBS.MSGS.