FYI - POR is to push some new tools I have been creating into OpenSIMH shortly.
In fairness to Will, this is in the class of a "2-minute minor," not a "4-minute major." I back into this issue as I was working on Oscar's new PiDP-10 and moving a very old (v6 syntax) UNIXC program that manipulates PDP-10 backup and TOPS-20 Dumper images. PDP-10s do things in 36 bits, which does not map cleanly to the 8 data bits of a 9-track tape (you don't want to know what the 10 does unless you have to deal with it). So, I wrote some tools to better examine and flexibly manipulate TAP files [the debug code for tapes in SIMH is a bit of a mess]. Anyway, as I was testing something, I thought I had made an error in my new tap_decode(1) tool when I was looking at the v7.tap.gz file that Warren has in the TUHS archives (that Will supplied/created with his mktape scripts). When I looked more carefully, it was missing a record. It turns out SIMH will silently "attach" a TAP image without a proper 9-track logical end-of-tape (it should give a warning). It also turns out Will's directions never looked for the actual 9-track EOT records - so nobody ever saw this. I mentioned it to him quietly - cudo's for coming clean.
FWIW: I always recommend Will's documents for V6 and V7 (in fact, we point to them in the OpenSIMH archives at my suggestion). The truth is, I wish we had had access to a few more that are as good as Will's for some of the other OSses.
Clem