PippaThe #sequencer for #musicn now works! The final bug turned out to be a typo in the example composition cards in the original paper, which I'd already noted but forgot to correct for when I made my version. There's still an issue with the final note being really long for some reason (I trimmed it in the attached rendering), but I'm so happy that it sounds exactly like how an experimental digital #synthesizer from the early 1960s should sound.
Yay - the #musicn sequencer is now running to the extent that it executes the composition deck fully and terminates normally having produced audio output. Unfortunately all of the notes have the same pitch because I hard coded it to work around what might be a quick tricky bug in some of the #FORTRAN code, and for some reason the final note is much longer than it should be, but you can hear that the rhythm is correct in the rendered audio.
It's been a while since I posted a #musicn update, but I have been slowly making progress. I've just reached the point where what should in theory be a complete implementation of the sequencer (at least if you don't need rests) is assembling without error and running to normal exit for a trivial (load a single function table and then exit) composition deck.
Next up I need to put together a composition deck which will actually produce some audio and see what that does. I fully expect this to fail in ways which are difficult to debug, but I might at least learn something new about debugging techniques for assembly language on an ancient platform.
I've finally gotten around to setting up a #git repo for the #musicn source code. It's at
https://philcowans.com/git/musicn.git
The repository is a read-only and served over the 'dumb' version of the git HTTP protocol, as I want to keep things as simple as possible and that one works with static hosting. Contributions are nevertheless very welcome. You can either send me a diff, or if you can fork the repo and host your own version somewhere, feel free to send me a ref to pull from.
I've just assembled the simplest possible #FAP program, and you basically get nothing other than your code - it doesn't even transfer control back to the operating system at the end unless you explicitly call the relevant routine. The two null words which #MAD puts at the end are missing, although you can insert arbitrary data so it wouldn't be hard to put them in.
Next up I'll put together a test program in FAP to call the OS formatted I/O routines and check they work as expected.
I've done some experiments, but I'm not sure I've learned much. If you write a simple MAD 'external subroutine', i.e. a library rather than an executable, there's still nothing in the 'symbol table' at the end of the code when loaded into memory, it's just two words of zeros. There are a few references to symbol tables in the documentation, but they don't seem super relevant to anything going on here. I think the next steps are going to be to write some test programs in FAP and see if I can get those working.
As an aside, I've taken a look at the BSS executable format. It's fairly well documented, but in terms of pysical card layouts, and I haven't yet quite got my head around how binary card images are represented on disk. From looking at a few examples, individual cards seem to be represented as 28 words, which is 1,008 bits, so more than can fit on a 12x80 punched card. The last four words of each card always seem to be the same though, so I guess not all of those 28 words represent the data on the card. In any case, I think I've figured out the header which corresponds to the card being data to be loaded into memory, and it all seems to be a bit chaotic - the segments are much shorter than could fit on a card, but they also don't correspond to lines of source code, and they appear in what looks like a random order in the deck.
Finally, it looks like .TAPRD, which reads from tape (or in practice a file on disk emulating a tape) is pretty much a drop-in replacement for .READ, so it should be pretty easy to try that one out. In the past I've had problems with it ignoring the file number argument though, and I do need to have multiple tapes if I'm going to use them for both input and output in #musicn
7/7
Note that the backwards direction for the format string makes sense, as the index registers on the #IBM7094 work that way - in indexed addressing mode the index register is subtracted from the base address.
5/n
Here's a slightly more involved version - this reads two values, so we can see how 'varargs' style lists work:
VECTOR VALUES FMT = $F9.4,F9.4*$
READ FORMAT FMT,N,M
The machine code output (as loaded by the program loader) is attached - the 'READ' call is indicated in red. This is linked to the OS routine '.READ', which the documentation (also attached) lists as a compatibility routine for MAD.
1/n
We're back on #musicn now, picking up with trying to reverse engineer how to read / write formatted input. The attachments show a simple MAD program which reads a number from the console and prints it back out, the output generated when the '(LIST)' flag is supplied to the MAD compiler, and a dump of the machine code as loaded into memory by the program loader.
