8 Nov
2016
8 Nov
'16
8:37 p.m.
Hi all --
I'm working on getting a TC11 + TU56 running at the LCM+L. We plan to use
it as a tool for various archival and restoration efforts.
After restoring the power supplies, I have it lashed up to a PDP-11/44 -- I
know this is anachronistic, but it's been a workhorse machine with ethernet
and SCSI, which makes it very flexible. So far, so good. I have RT-11
running and it can read and write tapes, although the left TU56 transport
seems to be a bit marginal.
I am running into a couple of issues, and I'm curious if anyone else out
there has experience here and might be able to shed some light before I
spend a lot of time on it:
1) In bringing the TC11 up, I've been attempting to run the TC11
diagnostics, with mixed success. ZTCB runs, but reports an error with the
ENDZ status bit not being set properly. So far as I can tell, ENDZ *is*
being set on normal operations, but I haven't exhaustively debugged the
controller yet. The other four diagnostics (ZTCA, ZTCC, ZTCD, and ZTCE) do
nothing when run -- nothing is printed and there is no response. If I run
them on SIMH configured as an 11/44, I see the same behavior. If I run
them on SIMH configured as an 11/20, then I get the printout described in
the documentation and listings. (See bitsavers --
http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp11/xxdp/diag_listin…).
I haven't yet dug in to see what accounts for the difference -- any ideas?
2) I'm looking for means to format DECtapes on the TC11. I have a few
marginal tapes and I'd like to see if reformatting them brings them back to
life. The maintenance manual only indicates "a special program supplied
with the TC11 system," and I haven't managed to find it. I *have* found
this:
http://mirrors.pdp-11.ru/inf.informatik.uni-stuttgart.de/pdp11/dtf.mac
which I've assembled and run on RT-11 and it goes through the motions of
writing out the timing and mark tracks, but when it goes through the second
pass to write out the block numbers it fails immediately, with either
status 001207 (indicating a "Data Missed" error) or 020033 (Mark Track
Error). I haven't yet hooked up a scope to see if the T&M tracks are
*actually* being written, but given my experience with the diagnostics in
(1) above, I'm not averse to thinking there may be more than meets the eye
with this issue.
So in a nutshell: Anyone used a TC11 on a later PDP-11 (like the 11/44)?
Anyone have any thoughts on the diagnostics and formatter issues?
Thanks as always,
Josh
8 Nov
8 Nov
8:42 p.m.
On 11/8/16 12:37 PM, Josh Dersch wrote:
I've assembled and run on RT-11 and it goes
through the motions of
writing out the timing and mark tracks, but when it goes through the second
pass to write out the block numbers it fails immediately
Did you set the switch on the controller front panel to enable the clock track writing?
8:54 p.m.
On Nov 8, 2016, at 3:37 PM, Josh Dersch <derschjo
at gmail.com> wrote:
Hi all --
...
2) I'm looking for means to format DECtapes on the TC11. I have a few
marginal tapes and I'd like to see if reformatting them brings them back to
life. The maintenance manual only indicates "a special program supplied
with the TC11 system," and I haven't managed to find it. I *have* found
this:
http://mirrors.pdp-11.ru/inf.informatik.uni-stuttgart.de/pdp11/dtf.mac
which I've assembled and run on RT-11 and it goes through the motions of
writing out the timing and mark tracks, but when it goes through the second
pass to write out the block numbers it fails immediately, with either
status 001207 (indicating a "Data Missed" error) or 020033 (Mark Track
Error). I haven't yet hooked up a scope to see if the T&M tracks are
*actually* being written, but given my experience with the diagnostics in
(1) above, I'm not averse to thinking there may be more than meets the eye
with this issue.
So in a nutshell: Anyone used a TC11 on a later PDP-11 (like the 11/44)?
Anyone have any thoughts on the diagnostics and formatter issues?
In college I used them on 11/20 and 11/45 processors with no troubles. And I think at DEC
we had them on an 11/70. In any case, there's no reason to expect trouble based on
the CPU type.
The standard DEC supplied formatting program was originally supplied as a paper tape
diagnostic. Way back in 1974 I rewrote it slightly so it would do the whole job in one
pass, without asking you to reset switches, and it would also write proper empty
directories (DOS style). But the standard program should work fine, and the one you
mentioned appears similar.
It's sufficient to have both the WRTM and WALL enable switches set for the whole
operation. The official approach is to set WRTM (only) during the first pass, WALL (only)
during the second, and no switches after that. But having unnecessary switches set to
enable is harmless.
If you had a switch set wrong you'd get an invalid operation error. You're seeing
some different code, which suggests either the mark or timing tracks weren't written
properly, or that there's some issue with the read circuitry. Yes, I would say
it's time to hook up the scope and start tracing some signals.
If you have a tape believed to be good that you're willing to erase, you might try
reformatting that one. That would help rule out issues caused by bad media. While it is
very rare for DECtape media to fail to the point that formatting doesn't work, it *is*
possible.
paul
9:24 p.m.
On Tue, Nov 8, 2016 at 12:54 PM, Paul Koning <paulkoning at comcast.net> wrote:
Beyond the XXDP diags not running properly ;). Some further
experimentation reveals that if I set the system memory to 64KW or less,
the ZTCA, etc. diagnostics run as expected. Forcing the XXDP disk to boot
the SM (vs. the XM) monitor makes things work even on a machine with >
64KW. So that looks to be solved, fingers crossed.
On Nov 8, 2016, at 3:37 PM, Josh Dersch
<derschjo at gmail.com> wrote:
Hi all --
...
2) I'm looking for means to format DECtapes on the TC11. I have a few
marginal tapes and I'd like to see if reformatting them brings them back
to
life. The maintenance manual only indicates
"a special program supplied
with the TC11 system," and I haven't managed to find it. I *have* found
this:
http://mirrors.pdp-11.ru/inf.informatik.uni-stuttgart.de/pdp11/dtf.mac
which I've assembled and run on RT-11 and it goes through the motions of
writing out the timing and mark tracks, but when it goes through the
second
pass to write out the block numbers it fails
immediately, with either
status 001207 (indicating a "Data Missed" error) or 020033 (Mark Track
Error). I haven't yet hooked up a scope to see if the T&M tracks are
*actually* being written, but given my experience with the diagnostics in
(1) above, I'm not averse to thinking there may be more than meets the
eye
with this issue.
So in a nutshell: Anyone used a TC11 on a later PDP-11 (like the 11/44)?
Anyone have any thoughts on the diagnostics and formatter issues?
In college I used them on 11/20 and 11/45 processors with no troubles.
And I think at DEC we had them on an 11/70. In any case, there's no reason
to expect trouble based on the CPU type.
The standard DEC supplied formatting program was originally supplied as a
paper tape diagnostic. Way back in 1974 I rewrote it slightly so it would
do the whole job in one pass, without asking you to reset switches, and it
would also write proper empty directories (DOS style). But the standard
program should work fine, and the one you mentioned appears similar.
It's sufficient to have both the WRTM and WALL enable switches set for the
whole operation. The official approach is to set WRTM (only) during the
first pass, WALL (only) during the second, and no switches after that. But
having unnecessary switches set to enable is harmless.
Good to know, thanks!
If you had a switch set wrong you'd get an invalid operation error.
You're seeing some different code, which suggests either the mark or timing
tracks weren't written properly, or that there's some issue with the read
circuitry. Yes, I would say it's time to hook up the scope and start
tracing some signals.
Yep. Hopefully with the newfound ability to run the real diagnostics, this
will be a bit easier. I'm guessing the read circuits are OK (since I am
able to use pre-formatted tapes without issue).
If you have a tape believed to be good that you're willing to erase, you
might try reformatting that one. That would help rule out issues caused by
bad media. While it is very rare for DECtape media to fail to the point
that formatting doesn't work, it *is* possible.
The tape I'm trying to format had a handful of bad blocks, none near either
end of the tape (where the error in formatting occurs). So I think the
media can be eliminated from the set of possible problems here.
Thanks again,
Josh
paul
9 Nov
9 Nov
8:59 a.m.
On Tue, 8 Nov 2016, Josh Dersch wrote:
with the TC11 system," and I haven't managed
to find it. I *have* found
this:
http://mirrors.pdp-11.ru/inf.informatik.uni-stuttgart.de/pdp11/dtf.mac
... which is simply a mirror of our FTP server at
ftp://ftp.informatik.uni-stuttgart.de/pub/cm/...
I enhanced DTF with some useful messages and error/status output. IIRC the
"original" version produced no messages at all.
(1) above, I'm not averse to thinking there may be
more than meets the eye
with this issue.
So in a nutshell: Anyone used a TC11 on a later PDP-11 (like the 11/44)?
Anyone have any thoughts on the diagnostics and formatter issues?
I have a TC11 with TU56 on our 11/34. Did you check the WRTM/WALL
switches?
Christian
2:52 p.m.
On Nov 9, 2016, at 3:59 AM, Christian Corti <cc at
informatik.uni-stuttgart.de> wrote:
On Tue, 8 Nov 2016, Josh Dersch wrote:
That sounds right. The convention of the paper tape era diagnostics is that errors are
reported by halts at specific (documented) addresses, sometimes with specific values in
R0.
paul
with the TC11 system," and I haven't
managed to find it. I *have* found
this:
http://mirrors.pdp-11.ru/inf.informatik.uni-stuttgart.de/pdp11/dtf.mac
... which is simply a mirror of our FTP server at
ftp://ftp.informatik.uni-stuttgart.de/pub/cm/...
I enhanced DTF with some useful messages and error/status output. IIRC the
"original" version produced no messages at all.
8:32 p.m.
On Wed, Nov 9, 2016 at 12:59 AM, Christian Corti <
cc at informatik.uni-stuttgart.de> wrote:
On Tue, 8 Nov 2016, Josh Dersch wrote:
Yep, even ran DTF with them flipped the other way around out of
superstition :).
Now that I've gotten the full suite of diagnostics to run, the problem
seems to be that the TC11 isn't reading properly in reverse -- Tests
15,16,21,22,26,27 and 34 of ZTCD fail, all others pass (modulo a marginal
block on the tape causing a failure here and there). This would probably
explain why DTF fails immediately after writing T&M, since it works in
reverse from that point...
Time to sit down with the schematics and figure out where the problem may
lie.
Thanks, all,
- Josh
with the TC11 system," and I haven't
managed to find it. I *have* found
this:
http://mirrors.pdp-11.ru/inf.informatik.uni-stuttgart.de/pdp11/dtf.mac
... which is simply a mirror of our FTP server at
ftp://ftp.informatik.uni-stuttgart.de/pub/cm/...
I enhanced DTF with some useful messages and error/status output. IIRC the
"original" version produced no messages at all.
(1) above, I'm not averse to thinking there may be more than meets the eye
with this issue.
So in a nutshell: Anyone used a TC11 on a later PDP-11 (like the 11/44)?
Anyone have any thoughts on the diagnostics and formatter issues?
I have a TC11 with TU56 on our 11/34. Did you check the WRTM/WALL switches?
Christian
9:05 p.m.
On Nov 9, 2016, at 3:32 PM, Josh Dersch <derschjo
at gmail.com> wrote:
...
Now that I've gotten the full suite of diagnostics to run, the problem
seems to be that the TC11 isn't reading properly in reverse -- Tests
15,16,21,22,26,27 and 34 of ZTCD fail, all others pass (modulo a marginal
block on the tape causing a failure here and there). This would probably
explain why DTF fails immediately after writing T&M, since it works in
reverse from that point...
Not necessarily. I thought that reading direction simply changes the bit patterns seen by
the electronics because the waveforms are reversed. This is the famous "obverse
complement".
In the Mark track, reversing the direction means that you see the bits in the opposite
order and complemented. As I recall, the encoding takes advantage of this: the start of
block code is the obverse complement of the end of block code (so that reversing means the
"end" code now reads like "start").
In the data, you have 3 bits parallel. So there, reversing means that you get the 3 bits
at a time reverse (think of octal digits reversed), complemented. For 16-bit data, look
at it as 18 bits with 2 bits unused.
In Read-All and Write-All, the controller doesn't do anything for direction, so if you
write in one direction data meant to be read in the opposite direction, the software has
to supply obverse-complement format data.
For regular Read and Write, the controller does handle direction change: the reverse
commands do an obverse-complement on the supplied data words, so your data ends up
word-wise reversed but the bits are in the expected spot and of the expected polarity.
The second pass (after the WRTM) in the formatting program is a reverse direction WALL, so
my comment that the hardware doesn't do anything special for direction applies there.
A possibility is that the motor has a problem causing an excessive speed difference
between forward and reverse. But in any case, yes, scope and schematics seem needed
here.
paul
9:43 p.m.
On Wed, Nov 9, 2016 at 1:05 PM, Paul Koning <paulkoning at comcast.net> wrote:
Those are good points. It's clear from running the diagnostics (ZTCC, not
ZTCD, sorry for the important typo) that a Read in a reverse direction
fails (but writes seem to be OK in either direction -- the tests that do
forward reads, regardless of the write direction of the data universally
pass). So there's definitely a fault there, but as you point out it may be
a separate issue from the formatter problem. Read-All and Write-All tests
(ZTCD) seem to be OK, but I'm going to re-run them just to be doubly-sure.
If those pass, I'm going to start with scoping out the OBVERSE ENB H
signals and the logic associated with them and see if there's anything
fishy there.
- Josh
On Nov 9, 2016, at 3:32 PM, Josh Dersch
<derschjo at gmail.com> wrote:
...
Now that I've gotten the full suite of diagnostics to run, the problem
seems to be that the TC11 isn't reading properly in reverse -- Tests
15,16,21,22,26,27 and 34 of ZTCD fail, all others pass (modulo a marginal
block on the tape causing a failure here and there). This would probably
explain why DTF fails immediately after writing T&M, since it works in
reverse from that point...
Not necessarily. I thought that reading direction simply changes the bit
patterns seen by the electronics because the waveforms are reversed. This
is the famous "obverse complement".
In the Mark track, reversing the direction means that you see the bits in
the opposite order and complemented. As I recall, the encoding takes
advantage of this: the start of block code is the obverse complement of the
end of block code (so that reversing means the "end" code now reads like
"start").
In the data, you have 3 bits parallel. So there, reversing means that you
get the 3 bits at a time reverse (think of octal digits reversed),
complemented. For 16-bit data, look at it as 18 bits with 2 bits unused.
In Read-All and Write-All, the controller doesn't do anything for
direction, so if you write in one direction data meant to be read in the
opposite direction, the software has to supply obverse-complement format
data.
For regular Read and Write, the controller does handle direction change:
the reverse commands do an obverse-complement on the supplied data words,
so your data ends up word-wise reversed but the bits are in the expected
spot and of the expected polarity.
The second pass (after the WRTM) in the formatting program is a reverse
direction WALL, so my comment that the hardware doesn't do anything special
for direction applies there.
A possibility is that the motor has a problem causing an excessive speed
difference between forward and reverse. But in any case, yes, scope and
schematics seem needed here.
paul
9:50 p.m.
On 11/9/2016 1:43 PM, Josh Dersch wrote:
t's clear from running the diagnostics (ZTCC, not
ZTCD, sorry for the important typo) that a Read in a reverse direction
fails (but writes seem to be OK in either direction -- the tests that do
forward reads, regardless of the write direction of the data universally
pass).
When you do writes, you have to physically have a read station
positioned after the write station on the head. Are there two such
stations on the drive for reading? Otherwise the writes may just be
blind writes, which would of course work as there isn't much to check
other than to backspace and do a re-read.
Just curious, as though I've got access to TU-56's have not looked for
that detail.
thanks
jim
10:57 p.m.
On Wed, Nov 9, 2016 at 1:43 PM, Josh Dersch <derschjo at gmail.com> wrote:
On Wed, Nov 9, 2016 at 1:05 PM, Paul Koning <paulkoning at comcast.net>
wrote:
Those are good points. It's clear from running the diagnostics (ZTCC, not
ZTCD, sorry for the important typo) that a Read in a reverse direction
fails (but writes seem to be OK in either direction -- the tests that do
forward reads, regardless of the write direction of the data universally
pass). So there's definitely a fault there, but as you point out it may be
a separate issue from the formatter problem. Read-All and Write-All tests
(ZTCD) seem to be OK, but I'm going to re-run them just to be doubly-sure.
If those pass, I'm going to start with scoping out the OBVERSE ENB H
signals and the logic associated with them and see if there's anything
fishy there.
- Josh
A quick update -- I ran the ZTCD diagnostics and they do fail, despite my
recollection (this is what I get for not taking notes at the end of
yesterday, and yesterday seems so far away now...). The first test (a
forward WALL, followed by an RALL of a single block) fails with the
following spew (for example):
BLKRQ 000310 DATA ERR WORD 00054. S/B 176376 WAS 104106
Based on a reading of the fiche listing (which is a slightly newer revision
of the binary I have) I believe S/B is the expected data and "WAS" is the
read-back data for a given word. Since one appears to be the obverse
complement of the other, it looks like the obverse complement logic is
running when it shouldn't be...
- Josh
On Nov 9, 2016, at 3:32 PM, Josh Dersch
<derschjo at gmail.com> wrote:
...
Now that I've gotten the full suite of diagnostics to run, the problem
seems to be that the TC11 isn't reading properly in reverse -- Tests
15,16,21,22,26,27 and 34 of ZTCD fail, all others pass (modulo a
marginal
block on the tape causing a failure here and
there). This would
probably
explain why DTF fails immediately after writing
T&M, since it works in
reverse from that point...
Not necessarily. I thought that reading direction simply changes the bit
patterns seen by the electronics because the waveforms are reversed. This
is the famous "obverse complement".
In the Mark track, reversing the direction means that you see the bits in
the opposite order and complemented. As I recall, the encoding takes
advantage of this: the start of block code is the obverse complement of the
end of block code (so that reversing means the "end" code now reads like
"start").
In the data, you have 3 bits parallel. So there, reversing means that
you get the 3 bits at a time reverse (think of octal digits reversed),
complemented. For 16-bit data, look at it as 18 bits with 2 bits unused.
In Read-All and Write-All, the controller doesn't do anything for
direction, so if you write in one direction data meant to be read in the
opposite direction, the software has to supply obverse-complement format
data.
For regular Read and Write, the controller does handle direction change:
the reverse commands do an obverse-complement on the supplied data words,
so your data ends up word-wise reversed but the bits are in the expected
spot and of the expected polarity.
The second pass (after the WRTM) in the formatting program is a reverse
direction WALL, so my comment that the hardware doesn't do anything special
for direction applies there.
A possibility is that the motor has a problem causing an excessive speed
difference between forward and reverse. But in any case, yes, scope and
schematics seem needed here.
paul
10 Nov
10 Nov
2:18 a.m.
On Nov 9, 2016, at 5:57 PM, Josh Dersch <derschjo
at gmail.com> wrote:
...
A quick update -- I ran the ZTCD diagnostics and they do fail, despite my
recollection (this is what I get for not taking notes at the end of
yesterday, and yesterday seems so far away now...). The first test (a
forward WALL, followed by an RALL of a single block) fails with the
following spew (for example):
BLKRQ 000310 DATA ERR WORD 00054. S/B 176376 WAS 104106
Based on a reading of the fiche listing (which is a slightly newer revision
of the binary I have) I believe S/B is the expected data and "WAS" is the
read-back data for a given word. Since one appears to be the obverse
complement of the other, it looks like the obverse complement logic is
running when it shouldn't be...
Yes, those two patterns are indeed obverse complement. Word 0054? That's odd, if
it's doing this wrong for a word in the middle of the buffer. Can you have it halt on
fail so you can examine the buffer?
paul
3:20 a.m.
On 11/9/16 6:18 PM, Paul Koning wrote:
It's actually word 4 (transcription error on my half) and it reports
errors for all words in the block (though the reported word number
doesn't actually correspond in any meaningful way to the word on tape,
per the documentation); i just singled that one out for an example.
They all show the read data being the obverse complement of the expected
data. I'll be doing some serious debugging tomorrow...
- Josh
On Nov 9,
2016, at 5:57 PM, Josh Dersch <derschjo at gmail.com> wrote:
...
A quick update -- I ran the ZTCD diagnostics and they do fail, despite my
recollection (this is what I get for not taking notes at the end of
yesterday, and yesterday seems so far away now...). The first test (a
forward WALL, followed by an RALL of a single block) fails with the
following spew (for example):
BLKRQ 000310 DATA ERR WORD 00054. S/B 176376 WAS 104106
Based on a reading of the fiche listing (which is a slightly newer revision
of the binary I have) I believe S/B is the expected data and "WAS" is the
read-back data for a given word. Since one appears to be the obverse
complement of the other, it looks like the obverse complement logic is
running when it shouldn't be...
Yes, those two patterns are indeed obverse
complement. Word 0054? That's odd, if it's doing this wrong for a word in the
middle of the buffer. Can you have it halt on fail so you can examine the buffer?
paul
15 Nov
15 Nov
10:40 p.m.
On Wed, Nov 9, 2016 at 7:20 PM, Josh Dersch <derschjo at gmail.com> wrote:
On 11/9/16 6:18 PM, Paul Koning wrote:
On Nov 9, 2016, at 5:57 PM, Josh Dersch <derschjo at gmail.com> wrote:
errors
for all words in the block (though the reported word number doesn't
actually correspond in any meaningful way to the word on tape, per the
documentation); i just singled that one out for an example. They all show
the read data being the obverse complement of the expected data. I'll be
doing some serious debugging tomorrow...
- Josh
So a small update:
I spent some time probing various signals and I couldn't find anything
obviously wrong; while the failing diagnostic was running, the obverse
complement logic in the hardware was behaving as I'd expect (i.e. it wasn't
being used, since an RALL was in effect). I went so far as to write my own
little test program that does basically what the ZTCD diagnostic Test 0
does -- a WDATA (forward) followed by a RALL (forward) and a comparison of
the data, and everything came back clean.
But I gained a better understanding of how the TC11 hardware works and how
it's programmed, so that's always a good thing.
And that knowledge helped me when I went back to the RT-11 formatter to see
if I could work out what was going wrong there. As you recall, the
formatter was failing after writing the T&M tracks with a Data Miss (DATM)
error. Data Miss in this case would indicate the software not responding
in time to the READY signal during a RALL command, which is interesting --
this would seem to indicate more of a software problem than a hardware one.
I noticed the following commented-out line at the beginning of the program:
START:
; RESET ;CLEAR THE WORLD
; MOV #P7,PS ;LOCKOUT P1 BY RAISING CPU PRIORITY <<----
Uncommenting the MOV #P7,PS line allows the formatter to run properly.
It appears that interrupts (I'd guess the LTC interrupt) were taking
enough time away from the program to cause it to miss data; I'm
guessing it's because I'm running the FB monitor rather than the SJ
monitor, but I'm not familiar enough with RT-11 yet to know exactly
where to place the blame.
At any rate, at this point I'm able to format a tape, initialize it in
RT-11, and copy/verify files onto it without any issues. The failing
diagnostics are still puzzling, but I'm almost ready to throw in the
towel on them :).
- Josh
...
A quick update -- I ran the ZTCD diagnostics and they do fail, despite my
recollection (this is what I get for not taking notes at the end of
yesterday, and yesterday seems so far away now...). The first test (a
forward WALL, followed by an RALL of a single block) fails with the
following spew (for example):
BLKRQ 000310 DATA ERR WORD 00054. S/B 176376 WAS 104106
Based on a reading of the fiche listing (which is a slightly newer
revision
of the binary I have) I believe S/B is the expected data and "WAS" is the
read-back data for a given word. Since one appears to be the obverse
complement of the other, it looks like the obverse complement logic is
running when it shouldn't be...
Yes, those two patterns are indeed obverse complement. Word 0054?
That's odd, if it's doing this wrong for a word in the middle of the
buffer. Can you have it halt on fail so you can examine the buffer?
paul
It's actually word 4 (transcription error on my half) and it reports
16 Nov
16 Nov
7:47 p.m.
On Nov 15, 2016, at 5:40 PM, Josh Dersch <derschjo
at gmail.com> wrote:
...
I noticed the following commented-out line at the beginning of the program:
START:
; RESET ;CLEAR THE WORLD
; MOV #P7,PS ;LOCKOUT P1 BY RAISING CPU PRIORITY <<----
Uncommenting the MOV #P7,PS line allows the formatter to run properly.
It appears that interrupts (I'd guess the LTC interrupt) were taking
enough time away from the program to cause it to miss data; I'm
guessing it's because I'm running the FB monitor rather than the SJ
monitor, but I'm not familiar enough with RT-11 yet to know exactly
where to place the blame.
Yes, commenting out that code is clearly a bug. The RALL/WALL/WRTM functions are used in
program I/O mode, so the CPU has to be ready with each new word as the tape finishes with
the previous one. Interrupts are most definitely supposed to be disabled. DECtape
formatting is a standalone activity, not something run under any OS.
RT-11 FB is likely to do a bit more stuff per clock interrupt, but either way, you're
entirely correct that interrupts -- clock or otherwise -- need to be disabled. The
consequence of spurious interrupts might be a corrupt mark track, or wrong data written by
the WALL pass, or verify errors during the RALL pass.
BTW, on RALL, it's actually possible to use DMA for the lower 16 bits of the 18 bit
data. The RT11 utility FILEX does that when reading PDP10 format tapes. (I suppose the
same might be true for WALL, I haven't heard of that being done.) But the
conventional way is to ignore the DMA and handle the data via the Data register plus the
two extended data bits in the status register.
paul
2973
days inactive
2981
days old
15 comments
5 participants
participants (5)
-
aek＠bitsavers.org -
cc＠informatik.uni-stuttgart.de -
derschjo＠gmail.com -
jwsmail＠jwsss.com -
paulkoning＠comcast.net