A voice starts pointed at its track, without code to point it

There is no assembler bug. I reported one and was wrong.

A label written in the Data Segment does come out as its address, two
bytes, most significant first - implemented in populateOutputBuffers,
documented in the Assembler Manual, and correct. What misled me was the
test I checked it with: the label was the first thing in an unbased
Data Segment, so its address really was 0x0000, and I read the right
answer as an unfilled placeholder.

So Play was doing at run time what the assembler had already offered to
do at assembly time. The voice records now carry their track labels
directly, which is exactly the shape LDD reads, and nothing relocates on
this machine so the address written is the address it will have. That
takes out startVoice, its four call sites, and the eight SETDs that fed
them: 450 bytes to 379, and the initial state of a voice is now
something you can read rather than something you have to follow the code
to work out.

The comment claiming otherwise is gone from Play.asm, and the same
change is made in fourVoiceTest.

The music is unchanged - bar by bar the render matches to within one per
cent, which is the program loading a shade sooner because it is smaller.
Ten recordings moved for the same reason: 446 to 379, and nothing else.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E2JrLzFvuFX9fgi1LDRjrW

Programs/CosmOS/Apps/Play.asm

@@ -37,10 +37,6 @@
 ; first because that is what LDD and STD move - a pointer through a pointer, which is the
 ; whole reason this can be a loop over four voices instead of the same code written out four
 ; times.
-;
-; The counts start at one rather than zero, so the first pass through the loop runs every
-; voice's count out and fetches its first event. Nothing has to be special-cased for the
-; beginning, and the piece starts on the tick rather than one after it.
 
 #Include services.asm
 
@@ -81,27 +77,6 @@ start:
   OUTA 0x51                 ; Run, repeat, interrupt.
   SIF
 
-  ; ---- The voices, pointed at their tracks ----
-  ;
-  ; The cursors are written here rather than assembled into the table, because a label used
-  ; as data does not come out as its address.
-  SETD.1 Voice0
-  SETD.0 Track0
-  CALL startVoice
-  SETD.1 Voice1
-  SETD.0 Track1
-  CALL startVoice
-  SETD.1 Voice2
-  SETD.0 Track2
-  CALL startVoice
-  SETD.1 Voice3
-  SETD.0 Track3
-  CALL startVoice
-
-  INIA 0d4
-  SETD.1 Playing
-  STA.1                     ; Four tracks still running.
-
   ; ---- The loop ----
   ;
   ; Step every voice, see whether any of them is still going, and then sleep. Stepping before
@@ -200,17 +175,6 @@ stepEnded:
   STA.3
   RET
 
-; DP1 is a voice and DP0 its track. Sets the cursor, and a count of one so that the first
-; pass through the loop fetches the first event.
-startVoice:
-  STD.0.1
-  DPUP.1 0d2
-  INIA 0d1
-  STA.1                     ; Count: one tick, which runs out immediately.
-  INCD.1
-  STA.1                     ; Live.
-  RET
-
 ; A plucked sound, on the channel named by A.
 setUpChannel:
   OUTA 0x41
@@ -258,17 +222,26 @@ tick:
   #Base 0x3000
 
 ; Four bytes a voice: cursor high, cursor low, count, live.
+;
+; A LABEL WRITTEN HERE COMES OUT AS ITS ADDRESS, two bytes, most significant first - which is
+; exactly the shape LDD reads. So a voice starts pointed at its track without a line of code:
+; nothing relocates on this machine, so the address the assembler wrote is the address it
+; will have.
+;
+; The count starts at one rather than zero so that the first pass through the loop runs it out
+; and fetches the first event. Nothing has to be special-cased for the beginning, and the
+; piece starts on the tick rather than one after it.
 Voice0:
-  0x00 0x00 0x00 0x00
+  Track0 0d1 0d1
 Voice1:
-  0x00 0x00 0x00 0x00
+  Track1 0d1 0d1
 Voice2:
-  0x00 0x00 0x00 0x00
+  Track2 0d1 0d1
 Voice3:
-  0x00 0x00 0x00 0x00
+  Track3 0d1 0d1
 
 Playing:
-  0x00
+  0d4
 ThisChannel:
   0x00