MDMRNWoke up this morning with Monsters by All Time Low featuring Demi Lovato and blackbear in my head. https://album.link/s/1EGlv1JGCUPolWU4qv7bsK
I'm wondering why...
PhilMaking a start on reading through the source code to figure out how #ctss is implemented (and therefore how to properly operate it). I suspect this might take a long time, but I've found the loader, the entry point into the kernel and the handler for the clock interrupt.
CTSS is the Compatible Timesharing System, one of the first interactive multi-user operating systems, written at MIT in the 1960s for the #IBM7094 mainframe. It was only ever installed on two systems, but was hugely influential. It's what I use to run my #musicn project, but while user manuals survive, there's not a lot of documentation about its internals or system administration, so I'm hoping I can change that.
The #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.
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
I only really know about #CTSS, which was only ever run on two machines, both at the same site, but that one did require operators to get involved for any kind of bulk I/O (cards, magnetic tape, high speed printing). I don't think the terminals had built in tape punches / readers (as was e.g. an option on a Teletype Model 33).
I'm not sure exactly what a typical workflow would have been though, and whether a regular user would have had much need for bulk I/O. I think that the DAC originally used with #musicn at #BellLabs read magnetic tape produced by the computer, but that was a slightly earlier generation of the technology.
@rillian - that's an interesting question. I've never spoken to anyone who has first hand experience of either medium, but I personally like the idea of the tangibility of cards - e.g. in #musicn being able to configure the program by inserting configuration cards, or job control cards book-ending the code itself. Some of the card formats I've seen have columns reserved for sequence numbers, so at least sometimes it would have been possible to automatically re-sort the cards if you dropped them. I've also heard about people using a marker to put a diagonal line across a deck for the same reason.
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.
