A manual for writing tunes
The fifth document, and the one somebody would want first if they had a piece of music and this machine. What a tune is, how to write one, what the compiler refuses and why, how to build and play one, and the bytes it holds for anything that would rather write one itself. The last of those matters more than it looks: Tests/maketune.py writes tunes without going through TuneC, and the suite checks the two agree byte for byte. A format with two implementations needs a specification they are both held to rather than one of them being the specification. The refusals get a table of their own with the reason beside each, because every one of them is something the PLAYER cannot notice - it has no names, no lengths, and no way to tell "no starting instrument" from "instrument nought" once a tune is loaded. Documented as reasons rather than as rules, so that somebody meeting one knows what it saved them from. docs.sh now settles the manual against the compiler both ways: every directive TuneC takes has a row, and the limits the manual quotes are the compiler's own #defines. Verified with break.sh - a directive removed from the manual and a limit raised in the compiler are both caught. One that was not caught first time and should not have been: removing the #Use row from one table left it documented in the other, which is the check being right and my break being wrong. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E2JrLzFvuFX9fgi1LDRjrW
This commit is contained in:
co-authored by
Claude Opus 5
parent
2808688fa1
commit
fb672d7761
@@ -710,7 +710,7 @@ in the [SplitBit Test Manual](SplitBit%20Test%20Manual.md).
|
||||
|
||||
## Documentation:
|
||||
|
||||
Four documents, divided by what they are about rather than by who reads them.
|
||||
Five documents, divided by what they are about rather than by who reads them.
|
||||
|
||||
**[SplitBit Programming Manual](SplitBit%20Programming%20Manual.md)** describes **the machine**: the instruction set, the registers, the vector table, interrupts, devices, the memory controller, the console, storage, and faults. Everything here is true of any SplitBit, whatever is running on it.
|
||||
|
||||
@@ -718,6 +718,8 @@ Four documents, divided by what they are about rather than by who reads them.
|
||||
|
||||
[Programs/CosmOS/README.md](Programs/CosmOS/README.md) describes **the operating system**: its shell, its applications, what a program may ask it for, and the libraries it owns. A different system on the same machine would answer all of that differently, which is why it is documented with the system rather than with the CPU.
|
||||
|
||||
**[SplitBit Tune Manual](SplitBit%20Tune%20Manual.md)** describes **music**: what a tune is, how to write one, what TuneC refuses and why, and the bytes a tune file holds for anything that would rather write one itself.
|
||||
|
||||
**[SplitBit Test Manual](SplitBit%20Test%20Manual.md)** describes **the test suite**: what each of its scripts claims, which of those claims are worth the most, how to add to it, and what it is blind to. It is about this repository rather than about the machine, which is why it comes last.
|
||||
|
||||
## License:
|
||||
|
||||
Reference in New Issue
Block a user