Play reads a tune from a file
The loader, and the reason it is small: everything in a tune is an offset from wherever it was put, so taking one means adding the base to two tables and pointing four voices at their order lists. No sequence is walked. Nothing inside one is an address to be found and corrected, which is the difference between a malformed tune that plays wrongly and one that takes the loader with it. "SBTU", version, the tick in cycles, how many patches and sequences, offsets to the two tables, an order list each, and the patch each voice starts on. The magic is checked before anything else, because from there on the loader follows what the offsets name. break.sh shows what that guard is worth: without it, handing Play a PROGRAM runs the machine away until the cycle limit, rather than saying it is not a tune. PatchTable, SequenceTable and VoiceStart became pointers, so the engine does not care whether a tune came out of a file or was assembled in. Play's built-in tune now hands over the same three addresses a loaded one would, in eight lines - which is what keeps the two paths from drifting, and what made this rung change no scheduler code at all. Tests/maketune.py lays the fixture out byte by byte. IT IS NOT THE COMPILER: the sequences and the patches are literal bytes and the only thing computed is where each piece lands. That is the point - the loader is checked by something that does not share its idea of the format, which is the same reason SplitDisk and sbfs.asm share nothing but a specification. Both notes in the fixture are number 60, so the octave between them is a 0x80 command loading the second patch out of the file: the header, the tick, the relocation, an order list and a patch from a file, measured in one go. Play and the tune live on quiet.img rather than cosmos.img, so a fixture does not move ten recordings every time it changes size. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E2JrLzFvuFX9fgi1LDRjrW
This commit is contained in:
Anachronaut
co-authored by
Claude Opus 5
Claude Opus 5
parent
5d9b39514b
commit
bfc46d982e
@@ -104,7 +104,29 @@ start:
|
||||
; under the old device this piece would have played with the arpeggio's setting on all four
|
||||
; parts - which is exactly the fault that made Lunar Porter's low fuel warning stop
|
||||
; trilling after the first landing of a run.
|
||||
CALL loadStartPatches
|
||||
; ---- A tune named on the line, or the one in here ----
|
||||
;
|
||||
; Nothing after the name plays what this program was built with. A name reads a file and
|
||||
; plays that instead, which is what makes it a player rather than a program with one song.
|
||||
SETD.0 TuneName
|
||||
INIB 0d63
|
||||
SWI osArgument
|
||||
SETD.0 TuneName
|
||||
LDA.0
|
||||
BRA playBuiltIn ; Nothing was typed after the name.
|
||||
|
||||
SETD.1 TuneBuffer ; DP0 is still the name, which is what osFileRead wants.
|
||||
SWI osFileRead
|
||||
BNQ playNoFile
|
||||
|
||||
SETD.0 TuneBuffer
|
||||
CALL useTune
|
||||
BNQ playNotATune
|
||||
BRI playReady
|
||||
|
||||
playBuiltIn:
|
||||
CALL useBuiltIn
|
||||
playReady:
|
||||
|
||||
INIA 0x60 ; Room over the top for four voices at once.
|
||||
OUTA 0x46
|
||||
@@ -176,6 +198,52 @@ lastRing:
|
||||
OUTA 0x51
|
||||
SWI osExit
|
||||
|
||||
; ---- What it says when it cannot ----
|
||||
;
|
||||
; Before the timer has been started, both of them, so there is nothing to stop and no handler
|
||||
; to take away.
|
||||
playNoFile:
|
||||
SETD.0 NoFileSaid
|
||||
SWI osPrintString
|
||||
INIA 0x01
|
||||
SWI osExit
|
||||
|
||||
playNotATune:
|
||||
SETD.0 NotATuneSaid
|
||||
SWI osPrintString
|
||||
INIA 0x01
|
||||
SWI osExit
|
||||
|
||||
; ---- The tune that is in this program ----
|
||||
;
|
||||
; What useTune does for a file, said in eight lines for a tune that is already in memory: the
|
||||
; three tables the player asks for, and an order list for each voice. Nothing is relocated,
|
||||
; because the assembler already wrote the addresses.
|
||||
useBuiltIn:
|
||||
SETD.0 BuiltInPatches
|
||||
SETD.1 PatchTable
|
||||
STD.0.1
|
||||
SETD.0 BuiltInSequences
|
||||
SETD.1 SequenceTable
|
||||
STD.0.1
|
||||
SETD.0 BuiltInVoiceStart
|
||||
SETD.1 VoiceStartAt
|
||||
STD.0.1
|
||||
SETD.0 Order0
|
||||
SETD.1 Voice0
|
||||
STD.0.1
|
||||
SETD.0 Order1
|
||||
SETD.1 Voice1
|
||||
STD.0.1
|
||||
SETD.0 Order2
|
||||
SETD.1 Voice2
|
||||
STD.0.1
|
||||
SETD.0 Order3
|
||||
SETD.1 Voice3
|
||||
STD.0.1
|
||||
CALL startVoices
|
||||
RET
|
||||
|
||||
; The tick has nothing to do: the loop above is the player and WAIT only needs something to
|
||||
; have happened. A handler still has to exist, because an interrupt with nothing installed to
|
||||
; catch it is a fault. Taking it is what brings the line down - a program that POLLED the
|
||||
@@ -187,6 +255,19 @@ tick:
|
||||
|
||||
#Base 0x3000
|
||||
|
||||
; The name that followed "Play", and room for the tune it names. WHOLE BLOCKS: osFileRead
|
||||
; puts 256 bytes down whatever the file's length, so the room here is a multiple of that and
|
||||
; not a guess at how big a tune is.
|
||||
TuneName:
|
||||
#Reserve 0d64
|
||||
TuneBuffer:
|
||||
#Reserve 0d1024
|
||||
|
||||
NoFileSaid:
|
||||
"no such tune"
|
||||
NotATuneSaid:
|
||||
"that is not a tune"
|
||||
|
||||
; ---- The order lists ----
|
||||
;
|
||||
; A table of sequence addresses each, ending in a zero. Read the four of them across and they
|
||||
@@ -215,10 +296,13 @@ Order3:
|
||||
; Writing these out by hand is exactly the tedium a compiler exists to remove: every sequence
|
||||
; has to be counted into its place above, and moving one means renumbering. That it is
|
||||
; unpleasant is the point of noticing it here rather than after a tool has baked the shape in.
|
||||
PatchTable:
|
||||
; The tables this tune uses. The player holds POINTERS to them rather than the tables, because
|
||||
; a tune read from a file has its tables wherever the file was put - so a built-in one hands
|
||||
; over the same three addresses a loaded one would.
|
||||
BuiltInPatches:
|
||||
OboePatch StringsPatch SquarePatch KalimbaPatch
|
||||
|
||||
SequenceTable:
|
||||
BuiltInSequences:
|
||||
Mel1 Mel2 Mel3 Mel4 ; 0 to 3
|
||||
Har1 Har2 Har3 Har4 ; 4 to 7
|
||||
BassC BassF BassG ; 8 to 10
|
||||
@@ -226,7 +310,7 @@ SequenceTable:
|
||||
|
||||
; The patch each voice starts on. Not assumed, and not four calls in a row: a starting
|
||||
; instrument is state, and state belongs somewhere it can be read.
|
||||
VoiceStart:
|
||||
BuiltInVoiceStart:
|
||||
0d0 0d1 0d2 0d3
|
||||
|
||||
; ---- Four bars of C, F, G, C ----
|
||||
|
||||
@@ -720,7 +720,7 @@ from every assembly file in it. Several are old programs written for the bare ma
|
||||
| Life | Conway's Game of Life, which had to be taught to stop, since a program that never ends takes the shell with it. Polls the console between generations. |
|
||||
| Snake | A game. Draws a whole screen with cursor addressing and steers with single keys, asking the console once a frame and never waiting. |
|
||||
| Keys | The console interrupting rather than being asked. The only one that brings a vector of its own, which is what the version two format exists for. |
|
||||
| Play | Four voices on one clock, which is what music is and one channel cannot be. The timer keeps a tick and every voice keeps its own place in its own track and its own count of how much longer the note it is holding lasts, so the parts move at four different rates and share nothing but the beat. A track is pairs of bytes, what to play and how many ticks it lasts: 1 to 127 is a MIDI note, zero is a rest, and 255 ends it - MIDI stops at 127, so neither of those had to be invented. A note's duration is its whole life and the gate goes down when the count runs out, which means a gap between two notes is written as a rest rather than invented by the player out of some fraction it decided on. Each voice loads an instrument of its own before a note is played - an oboe for the melody, strings under it, a square wave for the bass and a kalimba for the arpeggio - out of the format SoundPatch writes, which the player reads as a count and that many parameter and value pairs and understands nothing else about. Four patches can be up at once because a patch belongs to its channel; Kalimba has an LFO switched off and the other three have one on, and under a device where the LFOs belonged to the whole machine the last patch loaded would have imposed its setting on every part. A voice does not play one long track: it walks an ORDER LIST of its own, a table of sequence addresses, and takes the next one when a sequence runs out. That is where repetition comes from and it costs no notation - the bass plays the same sequence in the first bar and the last, written once. The four columns are how it reads and how a tracker would show it; per voice is how it is stored, because a voice's order cursor is then a pointer it advances by itself. Sequence and patch names are INDICES through two tables, which are the only places an address lives - so a tune read from a file will need its base added to two arrays and nothing else, rather than a loader that walks every sequence looking for addresses to correct. A sequence can also carry commands, which take no time at all: 0x80 plays the rest of that voice on a different patch, which is how the melody's last bar becomes a swell rather than a reed. Nothing keeps the voices together except that their sequences add up to the same length, which is the first thing a compiler should check. The patch each voice starts on is declared rather than assumed, because a voice given no instrument would play on whatever the device woke up with. The tune is assembled in for now; reading one from a file is what makes it a player rather than a program with one song in it, and the engine that plays it is Libraries/player.asm rather than this program. It spends over ninety nine per cent of its time asleep, because a beat is something to be woken by rather than counted up to. |
|
||||
| Play | Four voices on one clock, which is what music is and one channel cannot be. The timer keeps a tick and every voice keeps its own place in its own track and its own count of how much longer the note it is holding lasts, so the parts move at four different rates and share nothing but the beat. A track is pairs of bytes, what to play and how many ticks it lasts: 1 to 127 is a MIDI note, zero is a rest, and 255 ends it - MIDI stops at 127, so neither of those had to be invented. A note's duration is its whole life and the gate goes down when the count runs out, which means a gap between two notes is written as a rest rather than invented by the player out of some fraction it decided on. Each voice loads an instrument of its own before a note is played - an oboe for the melody, strings under it, a square wave for the bass and a kalimba for the arpeggio - out of the format SoundPatch writes, which the player reads as a count and that many parameter and value pairs and understands nothing else about. Four patches can be up at once because a patch belongs to its channel; Kalimba has an LFO switched off and the other three have one on, and under a device where the LFOs belonged to the whole machine the last patch loaded would have imposed its setting on every part. A voice does not play one long track: it walks an ORDER LIST of its own, a table of sequence addresses, and takes the next one when a sequence runs out. That is where repetition comes from and it costs no notation - the bass plays the same sequence in the first bar and the last, written once. The four columns are how it reads and how a tracker would show it; per voice is how it is stored, because a voice's order cursor is then a pointer it advances by itself. Sequence and patch names are INDICES through two tables, which are the only places an address lives - so a tune read from a file will need its base added to two arrays and nothing else, rather than a loader that walks every sequence looking for addresses to correct. A sequence can also carry commands, which take no time at all: 0x80 plays the rest of that voice on a different patch, which is how the melody's last bar becomes a swell rather than a reed. Nothing keeps the voices together except that their sequences add up to the same length, which is the first thing a compiler should check. The patch each voice starts on is declared rather than assumed, because a voice given no instrument would play on whatever the device woke up with. `Play <file>` reads a tune and plays that; `Play` on its own plays the one built into it. A tune file is "SBTU", a version, the tick in cycles, and offsets to a patch table, a sequence table and four order lists - everything in it an OFFSET from wherever it was put, so loading one is adding the base to two tables and pointing four voices at their order lists. No sequence is walked and nothing inside one is an address, which is what makes a malformed tune something that plays wrongly rather than something that takes the loader with it; the magic is checked first, because the loader follows what the offsets name. The patch each voice starts on is in the header, because a starting instrument is state. The engine that plays it is Libraries/player.asm rather than this program. It spends over ninety nine per cent of its time asleep, because a beat is something to be woken by rather than counted up to. |
|
||||
| Say | Prints whatever it was told, which is the shortest thing that shows osArgument working. |
|
||||
| Reboot | Starts the machine again, in 45 bytes. Writes a port rather than asking the system, because a reset has to work when the system does not. |
|
||||
| Once | Asks the loader to start something else on the next start, and only that one, in 569 bytes. |
|
||||
|
||||
@@ -109,6 +109,7 @@ stepCommand:
|
||||
DPDN.1 0d2
|
||||
|
||||
SETD.2 PatchTable
|
||||
LDD.2.2 ; The table, wherever this tune put it.
|
||||
DPUA.2
|
||||
DPUA.2 ; Twice, because an entry is two bytes.
|
||||
LDD.2.2 ; And DP2 follows the address it is now holding.
|
||||
@@ -149,9 +150,10 @@ stepSequenceEnd:
|
||||
STD.0.1 ; The order cursor, moved past this entry.
|
||||
|
||||
SETD.2 SequenceTable
|
||||
LDD.2.2 ; The table, wherever this tune put it.
|
||||
DPUA.2
|
||||
DPUA.2
|
||||
LDD.2.2 ; DP2 is the sequence that index names.
|
||||
LDD.2.2 ; And the sequence that index names.
|
||||
|
||||
DPUP.1 0d2
|
||||
STD.2.1 ; And the sequence cursor set to the new one.
|
||||
@@ -184,10 +186,12 @@ loadStartOne:
|
||||
SETD.3 ThisChannel
|
||||
STA.3
|
||||
|
||||
SETD.2 VoiceStart
|
||||
SETD.2 VoiceStartAt
|
||||
LDD.2.2
|
||||
DPUA.2
|
||||
LDA.2 ; Which patch this voice starts on.
|
||||
SETD.2 PatchTable
|
||||
LDD.2.2
|
||||
DPUA.2
|
||||
DPUA.2
|
||||
LDD.2.2
|
||||
@@ -204,6 +208,186 @@ loadStartOne:
|
||||
BNQ loadStartOne
|
||||
RET
|
||||
|
||||
; ---- base + offset, into wherever the caller wants it ----
|
||||
;
|
||||
; DP0 names two bytes of offset and DP1 two bytes to put the address in. They may be the same
|
||||
; place, which is how a table is relocated in position: the low byte is written before the
|
||||
; high byte is read, so nothing is clobbered under itself.
|
||||
;
|
||||
; The low bytes carry into the high ones, which is the whole reason ADD takes the Carry Flag.
|
||||
tuneAddr:
|
||||
SETD.2 TuneBase
|
||||
CCF
|
||||
INCD.0
|
||||
LDA.0 ; The offset, low byte.
|
||||
INCD.2
|
||||
LDB.2 ; And the base, low byte.
|
||||
ADD
|
||||
INCD.1
|
||||
STQ.1
|
||||
DECD.0
|
||||
LDA.0 ; The offset, high byte.
|
||||
DECD.2
|
||||
LDB.2
|
||||
ADD ; With the carry the low bytes made.
|
||||
DECD.1
|
||||
STQ.1
|
||||
RET
|
||||
|
||||
; Every entry of the table at DP0 turned from an offset into an address. B is how many.
|
||||
tuneReloc:
|
||||
PSHD.0
|
||||
POPD.1
|
||||
CALL tuneAddr ; A CALL hands DP0 and DP1 back, so both are still the entry.
|
||||
INCD.0
|
||||
INCD.0
|
||||
DECB
|
||||
BNB tuneReloc
|
||||
RET
|
||||
|
||||
; ---- A tune, from wherever it was put ----
|
||||
;
|
||||
; DP0 names its first byte. EVERYTHING IN A TUNE IS AN OFFSET FROM THERE, so this adds the
|
||||
; base to the two tables and the four order lists and nothing else in the file is touched. No
|
||||
; sequence is walked, and nothing inside one is an address to be found and corrected - which
|
||||
; is what makes a malformed tune something that plays wrongly rather than something that takes
|
||||
; the loader with it.
|
||||
;
|
||||
; Q is nought if the tune was taken, and anything else if the file was not one.
|
||||
useTune:
|
||||
SETD.1 TuneBase
|
||||
STD.0.1
|
||||
|
||||
; "SBTU", and version one. A file that is not a tune has to be refused here, because
|
||||
; everything below reads offsets out of it and jumps to what they name.
|
||||
SETD.1 TuneMagic
|
||||
INIB 0d5
|
||||
useTuneMagic:
|
||||
LDA.0
|
||||
PSHB
|
||||
LDB.1
|
||||
XOR
|
||||
POPB
|
||||
BNQ useTuneNo
|
||||
INCD.0
|
||||
INCD.1
|
||||
DECB
|
||||
BNB useTuneMagic
|
||||
|
||||
; The tick, straight into the timer. Three bytes, most significant first, which is the
|
||||
; order the ports take them in.
|
||||
LDA.0
|
||||
OUTA 0x52
|
||||
INCD.0
|
||||
LDA.0
|
||||
OUTA 0x53
|
||||
INCD.0
|
||||
LDA.0
|
||||
OUTA 0x54
|
||||
|
||||
; How many of each, kept before the pointers move.
|
||||
INCD.0
|
||||
LDA.0
|
||||
SETD.1 TunePatches
|
||||
STA.1
|
||||
INCD.0
|
||||
LDA.0
|
||||
SETD.1 TuneSequences
|
||||
STA.1
|
||||
|
||||
; The two tables.
|
||||
INCD.0
|
||||
SETD.1 PatchTable
|
||||
CALL tuneAddr
|
||||
INCD.0
|
||||
INCD.0
|
||||
SETD.1 SequenceTable
|
||||
CALL tuneAddr
|
||||
|
||||
; And an order list each.
|
||||
INCD.0
|
||||
INCD.0
|
||||
SETD.1 Voice0
|
||||
CALL tuneAddr
|
||||
INCD.0
|
||||
INCD.0
|
||||
SETD.1 Voice1
|
||||
CALL tuneAddr
|
||||
INCD.0
|
||||
INCD.0
|
||||
SETD.1 Voice2
|
||||
CALL tuneAddr
|
||||
INCD.0
|
||||
INCD.0
|
||||
SETD.1 Voice3
|
||||
CALL tuneAddr
|
||||
|
||||
; The starting instruments are not an offset but a place IN the file, so they are found by
|
||||
; counting rather than by adding.
|
||||
SETD.0 TuneBase
|
||||
LDD.0.0
|
||||
DPUP.0 0d22
|
||||
SETD.1 VoiceStartAt
|
||||
STD.0.1
|
||||
|
||||
; Now the tables themselves, whose entries are offsets like everything else.
|
||||
SETD.0 PatchTable
|
||||
LDD.0.0
|
||||
SETD.1 TunePatches
|
||||
LDB.1
|
||||
CALL tuneReloc
|
||||
SETD.0 SequenceTable
|
||||
LDD.0.0
|
||||
SETD.1 TuneSequences
|
||||
LDB.1
|
||||
CALL tuneReloc
|
||||
|
||||
CALL startVoices
|
||||
|
||||
; Q is nought, which is how this says it worked. There is no instruction that sets Q: it is
|
||||
; the ALU's output and nothing else, so saying nought means doing a sum that comes to it.
|
||||
RSTA
|
||||
RSTB
|
||||
XOR
|
||||
RET
|
||||
|
||||
useTuneNo:
|
||||
; Q is already not nought, because that is what got here.
|
||||
RET
|
||||
|
||||
; ---- Four voices at the beginning of their order lists ----
|
||||
;
|
||||
; Whoever supplied the tune has set the order cursors; this sets everything else. A voice
|
||||
; starts on Empty with a count of one, so its first tick runs the count out, finds the end of
|
||||
; a sequence, and goes to the order list for the real first one. The beginning of a piece
|
||||
; needs no special case anywhere.
|
||||
startVoices:
|
||||
SETD.1 Voice0
|
||||
CALL startOneVoice
|
||||
SETD.1 Voice1
|
||||
CALL startOneVoice
|
||||
SETD.1 Voice2
|
||||
CALL startOneVoice
|
||||
SETD.1 Voice3
|
||||
CALL startOneVoice
|
||||
INIA 0d4
|
||||
SETD.1 Playing
|
||||
STA.1
|
||||
CALL loadStartPatches
|
||||
RET
|
||||
|
||||
startOneVoice:
|
||||
SETD.0 Empty
|
||||
DPUP.1 0d2
|
||||
STD.0.1
|
||||
INCD.1
|
||||
INCD.1
|
||||
INIA 0d1
|
||||
STA.1 ; A count of one, which runs out on the first tick.
|
||||
INCD.1
|
||||
STA.1 ; And live.
|
||||
RET
|
||||
|
||||
; ---- A patch, onto the channel named by A ----
|
||||
;
|
||||
; A count, then that many pairs of parameter and value: the format SoundPatch writes and the
|
||||
@@ -253,6 +437,24 @@ Playing:
|
||||
ThisChannel:
|
||||
0x00
|
||||
|
||||
; Where this tune's tables are. Pointers rather than the tables themselves, because a tune
|
||||
; read from a file puts them wherever it was put, and the engine must not care which.
|
||||
PatchTable:
|
||||
0x00 0x00
|
||||
SequenceTable:
|
||||
0x00 0x00
|
||||
VoiceStartAt:
|
||||
0x00 0x00
|
||||
|
||||
TuneBase:
|
||||
0x00 0x00
|
||||
TunePatches:
|
||||
0x00
|
||||
TuneSequences:
|
||||
0x00
|
||||
TuneMagic:
|
||||
0x53 0x42 0x54 0x55 0x01 ; "SBTU" and version one.
|
||||
|
||||
; The sequence a voice starts on, so that its first tick goes through the order list like
|
||||
; every other bar does.
|
||||
Empty:
|
||||
|
||||
@@ -32,7 +32,28 @@ start:
|
||||
; ONE parameter - the octave - and VoiceStart gives the low one to voice 0 and the high one
|
||||
; to voice 1. If a patch belonged to the device rather than to its channel the second would
|
||||
; overwrite the first and both voices would sound the same.
|
||||
CALL loadStartPatches
|
||||
SETD.0 MyPatches
|
||||
SETD.1 PatchTable
|
||||
STD.0.1
|
||||
SETD.0 MySequences
|
||||
SETD.1 SequenceTable
|
||||
STD.0.1
|
||||
SETD.0 MyVoiceStart
|
||||
SETD.1 VoiceStartAt
|
||||
STD.0.1
|
||||
SETD.0 Order0
|
||||
SETD.1 Voice0
|
||||
STD.0.1
|
||||
SETD.0 Order1
|
||||
SETD.1 Voice1
|
||||
STD.0.1
|
||||
SETD.0 Order2
|
||||
SETD.1 Voice2
|
||||
STD.0.1
|
||||
SETD.0 Order3
|
||||
SETD.1 Voice3
|
||||
STD.0.1
|
||||
CALL startVoices
|
||||
|
||||
INIA 0x60
|
||||
OUTA 0x46
|
||||
@@ -101,13 +122,13 @@ Order2:
|
||||
Order3:
|
||||
0d3 0xFF
|
||||
|
||||
PatchTable:
|
||||
MyPatches:
|
||||
PatchLow PatchHigh
|
||||
|
||||
SequenceTable:
|
||||
MySequences:
|
||||
Beat Quiet Switch Tail ; 0 to 3
|
||||
|
||||
VoiceStart:
|
||||
MyVoiceStart:
|
||||
0d0 0d1 0d0 0d0
|
||||
|
||||
Beat:
|
||||
|
||||
Reference in New Issue
Block a user