#ibm7094

Unifortunately, the actual archive files I have (which are modern ASCII files) use neither of these conventions, and instead have 4 blank lines (CR LF termination) followed by something like: AARCHV BCD 10/04/70 1545.9 42312 00000 The fields are identifiable, apart from the 00000, which doesn't appear in the source code, however, assuming the 42312 is a word count, I'm really struggling to relate that in any meaningful way to the actual length of the following file (as identified by scanning for the next super line mark). There's a good chance that the files I have have been processed in unknown ways since they were written by the original machine, but I would like to have a complete understanding. As an aside there are also page and section headers in the file, and I'm not sure whether these are part of the ARCHIV format or from the original files. I'm going to have to park this for now, but will investigate when I next have some time. 7/7 #CTSS #retrocomputing #IBM7094

The later version is from 1970, and the comment has changed to: THE FORMAT OF 'SUPER LINE MARK' IN ASCII ARCHIV FILES IS DEFINED AS FOLLOWS: FF NL NL NL DEL DEL DEL DEL NAME1 SP SP NAME2 SP SP MM/DD/YY SP SP HHMM.M SP SP ZZZZZZ DEL DEL DEL DEL NL NL NL NL TOTALLING 14 WORDS. ZZZZZZ IS THE WORD COUNT. So by now we've switched to #ASCII. From the code, NL is what is now called LF. The code also implies that ASCII is internally represented with 9 bits (i.e. 3 octal digits), so 4 characters per 36 bit word. 6/n #CTSS #retrocomputing #IBM7094

The earlier version is from 1968. The key thing is the format of the 'super line mark', which is the separator between the various files in the archive. The 1968 version has the following comment describing how it works: THE FORMAT OF THE 'SUPER LINE MARK' IN ARCHIV FILES IS: 777777000000K,..,..,..,777777000011K,FLN1,FLN2, $ MM/DD/YY HHMM.M $, $ZZZZZZ$,$$,$ 000$,$00 $ TOTALLING 14 WORDS, WHERE ZZZZZZ IS FILE WORD COUNT. THIS INFORMATION SHLD NOT BE KNOWN ANYWHERE IN THE PROGRAM EXCEPT IN THE FLLWING INTERNAL FUNCTIONS AND V'S STATEMENTS. This describes a #BCD format (6x 6 bit characters per 36 bit word). 5/n #CTSS #retrocomputing #IBM7094

The second thing I've been doing is trying to figure out how ARCHIV (roughly equivalent to 'tar') works and therefore how to interpret the file format. This is the file format for most of the preserved source code (which is fortunately pretty readable without understanding the details), but the preserved files also include two versions of the utility itself. 4/n #CTSS #retrocomputing #IBM7094

One thing I haven't got my head around yet is memory management. I previously assumed that there was no support for virtual memory at all, but I'm not sure that's the case - I've now seen a paper which discusses what might be support for it as one of the hardware modifications which were made to the #MIT machines to support #CTSS, but also suggests it wasn't actually used. In any case, presumably memory fragmentation needs to be dealt with somehow. I think I need to either look at how the emulator is implemented or do some experiments. 3/n #retrocomputing #IBM7094

There are three modules which are very densely connected - two are general utility functions, and one is the interface from userland into various bits of the kernel. I'm going to make a version of the graph which omits these, and hopefully the remainder will be more readable. 2/n #CTSS #retrocomputing #IBM7094