Hi all, sorry for the long silence! Zach and I were busy in July and August working on a research project with a deadline.
With the functional memory expansion in place,
@ZachyCatGames and I are moving on to the next big item on our to-fix list, the tape drives.
tl;dr: Our machine seems to be able to read tapes, but can't mark them. Any ideas why running mark12 would result in spooling everything onto the takeup spool and nothing else? Are we just doing something wrong?
Longer version:
As I recall it, once upon a time, the top tape drive worked reliably. The bottom tape drive had an issue where a brake did not enable as it was supposed to, so it would sometimes keep spinning due to momentum and unspool the tape. Most of what follows is about our top tape drive, which was always the more reliable of the two.
As I understand it, Warren made dumps of all our tapes, and we have copies of them (does anyone else?). He seemed to have used a version of dumprest that supported LINC tapes... (
@djg ,
@vrs42 ,
@m_thompson or
@DougIngraham -- do you know anything about that? We seem to have sourcecode for it.)
Back then, marking tapes worked;
we recorded a video of mark12 in action (narrated by Warren).
When Warren was still here with Dawson there was a major short issue that fried a bunch of FCs, which -- to their knowledge -- they repaired. But, at some point before Dawson graduated, the top tape drive became unreliable. (I don't remember if the unreliability was in any way obviously related to the big short.) We could use the tape drive, but it seemed like it would randomly corrupt tapes, which would become unreadable.
Later, in 2019, Dawson, Julian, and I tried to figure out the issue with the tape drive. We ran the diagnostics, but got stuck on a failing Tape Data Test with some errors with the XOB. It turned out that
one of the bits of the XOB was only getting set probabilistically. We created a small program to set the bits of the XOB manually and we scoped the XOB pins while that program ran. Weirdly, we could "fix" the issue by lifting the backplane door slightly (more like putting a little upward stress on it).
You can see that in action on an oscilloscope in this video. We sort of ran out of time / steam once the school year started, and then of course the pandemic happened a few months later.
Picking things back up with my student Kyle (after the pandemic), we started the process of testing all the flip chips (thanks to
@vrs42 updated FCT) because we discovered we could no longer boot OS/8 or run diagnostics (longtime readers will recall this was an issue of minicom inserting LFs into tapes being sent to the '12). The teletype and diskserver seem to be pretty much rock solid these days (thanks to
@ZachyCatGames and you all), and what's more, we now have 32KW (thanks again
@vrs42 !)... so we are now looking at the tape drives again.
Here's where things are at. We recently were able to run Tape Control Test 1 & 2 successfully, but we haven't been able to run Tape Data Test or Tape Data Exerciser, because we don't have any marked tapes we are willing to potentially sacrifice, and -- importantly -- we are unable to mark new tapes. When we
try to mark tapes, Mark12 seems to start normally, but once we select a format and press "mark", it simply spools all the tape from the main spool to the takeup spool. (Incidentally, this happens on either drive.)
Thinking this might be our mysterious probabilistic issue with the XOB, Zach wrote an updated diagnostic punch-in program that makes sure that the XOB has the contents of the RSW, or it halts. That program is:
Code:
4020 0516 RSW
4021 1041 STA [1]
4022 0001 AXO
4023 0021 XOA
4024 1441 SAE [1]
4025 0000 HLT
4026 6020 JMP 20
That program ran without halting for over an hour with various settings of the XOB bits. So, perhaps our intermittent issue with the XOB was resolved in all the flip chip removal / replacement. (Or maybe it's somehow just in a stable state right now.) But if the XOB issue is gone, what's keeping us from being able to mark tapes?
We got curious and tried to read (with write lock on) some of our older tapes, and while some tapes seemed to be a little flaky,
we were able to read directory listings and files from a variety of sources. So, it seemed like read was working reliably on our top drive, and iirc,
@ZachyCatGames was able to read with the lower drive as well.
So, today, we tried running dumprest on some of our old tapes to see if we would get identical images to what were backed up by Warren. When we compiled and ran dumprest, it also seemed to just spool everything onto the takeup spool, (except for one tape that seemed to get stuck in a loop trying to read a particular region, which we stopped -- I presume this is the dreaded "shoeshining"?). Later,
@ZachyCatGames was able to boot one of our original OS/8 tapes (again with write lock on). So maybe we weren't running dumprest properly?
This brought up two more questions...
1) do people wipe and reuse old tapes? Or do you tend to leave them in pristine original state because they are artifacts? The tapes we have been trying to mark are four Scotch brand dectapes that Warren sourced for us back in the day. But it occurred to me that maybe we can't mark them because they're bad in some way, and we're failing simply because we are marking unmarkable tapes?
2) Where do people source dectapes? I would love to get to the point where we have enough dectapes for students to play with, but I'm not sure if there's a cost-effective way of doing that.
Any and all hot ideas welcome! Thanks!
-- that's incredible. I'm glad you were able to save it.