I see, the original ~300ft DC300 tapes did have a capacity (of a single file) of around 200-220 KB. From the General Information Manual:
So, experimenting with the Imation DC6150 tape on the 5110, which that tape states it is 620ft of material. (it says "150 Mbytes" but I think any byte-capacity of tape is meaningless, since it is relative to whatever the nature of the system it is being used on? in any case, we're not storing anywhere near 150 million bytes here)
Code:
MARK 500,1,1 FAILED, could not make a single 500KB file
MARK 400,1,1 OK, was able to make this file (I think the actual single largest file is about 450KB) [it takes about 3 minutes to mark this size]
MARK 220,2,1 OK
MARK 16,30,1 FAILED (on file 0027)
MARK 16,26,1 OK (this takes a little over 3 minutes; this is 26 x 16KB files)
MARK 8,2,27 OK (did this after the above MARK)
NOTE: MARK 17,1,27 failed ERR 567, there is not 1 more full K to give on the tape.
NOTE: 1x16KB or 2x8KB works, but 16x1KB probably will not.
This implies a 432KB tape capacity on 620ft - the tape material does move essentially entirely from one reel to the other. Halving the material and keeping some prudent buffer from the very end, then 204-207KB for the 300ft tape is fair (it might get up to 210-220KB if you risk working at closer to the very end, or if the tape is actually 330ft?).
But in terms of number of files and sizes, it's not quite that simple since each file itself has a large header overhead -- in other words, I don't think I could have 432 x 1KB files, but rather somewhere between 200-300 of those 1KB sized files.
I think the IBM manuals and PR might be a little better served with that kind of chart:
if you have 620ft of tape,
432KB 1-file
....
16KB 27-files
8KB 50-files (my estimate)
...
1KB 230-files (my estimate)
And similar for the 300ft tape. The stock system is 1KB increments (2KB, 3KB, 4KB, 5KB, etc).
There is nothing really sacred in this file arrangement. It is just code in the Executive ROS, which does have some convenient "entry points" (functions or branch points) for things like seeking/finding to a file, reading/wrting a portion of the file. Those are sort of like "BIOS" calls, for applications to have a standard format to work with. So, if I didn't want to invent my own file format, but wanted to save some bytes, I could jump to those locations. But if I wanted a more efficient file system (e.g. smaller headers and larger data capacity), one could technically code that up in PALM machine code.
EXAMPLE: Below, the last two files (27 and 28) are 8KB instead of 16KB (showing the "variable file sizes"). I couldn't make 32x16KB files, so I tried 26x16KB, and then incrementally added files until I reached the EOT (err 567). I could add 1x16KB more, or 2x8KB more. But I could
not add 1x17KB or larger (err 567).
Another note: the REWIND seems to have a 150 second time out. If it keeps rewinding for 2min 30seconds, then ERR 004 gets reported. You can issue another REWIND and keep on rewinding. The timeout seems to correspond to the 207KB file size (and the err 004 at timeout will happen whether you have one large file or many small ones). Anyhow, it appears that yes you can have a file or files for as large of a capacity as the physical tape media allows -- err 567 is reported when you've reached the end (EOT).
I understand each data record (file) has format records of 290 bytes that is in-between each 512 byte (+header/footer) portion of a file. I'm not sure why the Format Record seems so excessive - I assume it's just "good backup" in case portions of the file get corrupted. It also implies that technically a file could have a "variable format" as piece parts could have a different Format Record.
The header record implies 4-bytes for file number and "number of bytes" per file - so I was surprised to be able to make files larger than 64KB. So maybe the document is more notional than literal. (these same notes are in the 1979 IBM 5110 MIM, as they appear in the 5100 MIM):
NOTE: This 432KB... Even if you double or triple it because of header and format record overhead, that's ~1.2MB (in terms of actual total number of bytes used). Not the 150 "Mbytes" listed on the DC6150 packaging. Some other system must be far more efficient formatting of the bits to get up closer to 150MB capacity, or operates more slowly. Recall the IBM 5100 system has the tape at constant speed - so aside from the format record overhead, when any bit is written I imagine it's several feet that goes by quickly.
