Back to dectape (TC08) debugging
Tim Radde
system does not
read a tape quite right.
Dave Gesswein provided me with a few sample tapes of known data and
also known
to be good.
The first data block contains:
0000000 001236 006766 006771 005202 003231 003232 001237 005224
0000020 000000 000137 001355 001211 007650 005220 007000 005212
0000040 001235 006774 006771 005222 006764 006774 001234 003355
0000060 003354 006213 005242 005212 007577 000010 000600 000620
0000100 000000 000000 003344 006771 005243 006203 005205 007607
0000120 007607 000000 000000 000000 000000 000000 000000 000000
0000140 000000 000000 000000 000000 000000 000000 000000 006202
0000160 004207 001000 000000 000007 007746 006203 005677 000400
0000200 000000 003340 006214 001275 003336 006201 001674 007010
0000220 006211 007630 005321 006202 004207 005010 000000 000027
0000240 007402 006202 004207 000610 000000 000013 007602 005020
0000260 006202 004207 001010 000000 000027 007402 000000 005700
0000300 000000 000000 000000 000000 000000 000000 000000 000000
While I only checked words 0 to 25, I find most read correctly, but 5
did not. Word 1 read as 6166 instead of 6766, word 14 read as 7250
instead of 7650, word 21 read as 6134 instead of 6774, word 24 read as
0764 instead of 6764 and word 25 read as 6734 instead of 6774.
This just seem so bizarre to have different bits dropped, in some case
3 bit being off. Vince Slyngstad has been trying to assist me with
this but so far I have not been able to determine a cause. I believe
the
TU56 is not the problem as when I got it it was known to be tested and
worked fine with the TD8e I had at that time. I am not sure about the
TC08 as the previous owner never bothered to dig into where the
problem
was. He just knew there was one. I was thinking it's in the external
bus of the 8i, since I also appear to not be able to run the RK8 disk
subsystem I have. The maindec for that runs for quite some time, but
it appears to fail when it does the first write/read/compare which if
the
external bus is truely dropping bits would explain why that didn't
work
either. Any suggestions on what things to try to do to isolate this
problem? I am at a loss as to how to proceed to find the problem and
fix it. Thanks in advance.
Tim Radde
David Powell
<388203be-e478-454f...@41g2000hsc.googlegroups.com>,
>After quite a break I am back to trying to figure out why my dectape
>system does not
>read a tape quite right.
>
>Dave Gesswein provided me with a few sample tapes of known data and
>also known
>to be good.
>
Known to be good on his kit, not necessarily on yours.
How does it perform on a tape formatted on that drive?
>The first data block contains:
>0000000 001236 006766 006771 005202 003231 003232 001237 005224
>0000020 000000 000137 001355 001211 007650 005220 007000 005212
>0000040 001235 006774 006771 005222 006764 006774 001234 003355
>0000060 003354 006213 005242 005212 007577 000010 000600 000620
>0000100 000000 000000 003344 006771 005243 006203 005205 007607
>0000120 007607 000000 000000 000000 000000 000000 000000 000000
>0000140 000000 000000 000000 000000 000000 000000 000000 006202
>0000160 004207 001000 000000 000007 007746 006203 005677 000400
>0000200 000000 003340 006214 001275 003336 006201 001674 007010
>0000220 006211 007630 005321 006202 004207 005010 000000 000027
>0000240 007402 006202 004207 000610 000000 000013 007602 005020
>0000260 006202 004207 001010 000000 000027 007402 000000 005700
>0000300 000000 000000 000000 000000 000000 000000 000000 000000
>
>While I only checked words 0 to 25, I find most read correctly, but 5
>did not. Word 1 read as 6166 instead of 6766, word 14 read as 7250
>instead of 7650, word 21 read as 6134 instead of 6774, word 24 read as
>0764 instead of 6764 and word 25 read as 6734 instead of 6774.
>This just seem so bizarre to have different bits dropped, in some case
>3 bit being off.
The same bad data every time you read that block ?
Regards,
David P.
Tim Radde
> In article
> <388203be-e478-454f-bef4-e5c924f9d...@41g2000hsc.googlegroups.com>,
Tape formatted on which drive? Mine or his? I am not sure I would
trust trying to format on mine, and I don't know if he formatted this
tape or just grabbed one and used it.
Pretty much seems to be the same faulty data ever time. I have seen
one bit change in a couple of areas when I tried swapping two of
the external bus boards, but not every time then either. Originally
I thought is was just a bit being dropped and was pretty sure I
could localize it to a problem in the external 8i bus interface. But
now that does not seem to be the case or at least it's not a single
bit. I could send this tape back to Dave and ask him to read it to
verify it has the data he says it should. I don't know of anyone
really close that would be able to read this tape for me (the
first block).
David Gesswein
Tim Radde <tra...@excite.com> wrote:
>Dave Gesswein provided me with a few sample tapes of known data and
>also known
>to be good.
>
Like the other person said drive differences can cause read errors on
tapes that work fine on my system. I know I can't read all old tapes
without errors and if I try the other transport sometimes I can read it.
>I am at a loss as to how to proceed to find the problem and
>fix it. Thanks in advance.
>
Have you run the TC08 diagnostics? If all it shows is you have data
problems then its test equipment time.
How to fix it depends on what test equipment you have. If you have a
logic analyizer or digital scope with sufficiently deep memory I would
trigger it off the found block signal in the TC08 and follow the signal
from the drive through the system.
If you only have an analog scope you will need a tape which has
a consistent pattern. Can you write to a tape on your system?
If you can make one then do the same trigger off the block match or
other signal in the TC08 and do the same tracing. The drive speed variations
cause a lot of jitter which will make it hard to see very far into a block.
Tim Radde
> In article <388203be-e478-454f-bef4-e5c924f9d...@41g2000hsc.googlegroups.com>,
I have no logic analyzer or digital scope. I know I have considered
getting
a logic analyzer in the past. May be time to break down and get one.
Only have an analog scope with 4 inputs. I believe I can write a
tape,
but can't say what actually gets to it. I originally tried running
your
DumpRest to create a bootable OS/8 tape. That's when I noticed
there were certain bits missing on reading back. I'll see what I can
do. I have not run the TC08 diagnostics recently. I'll try those
again
too. Thanks.
Tim
David Powell
<01e4c560-f628-4591...@p43g2000hsc.googlegroups.com>,
It works like this. The mechanical alignment drifts over time,
eventually the tape becomes unreadable. Then if the tape is
reformatted on that drive, magic, it's usable again. Unfortunatelly
that tape has inherited the drift and may be readable in another
drive. The fix is to buy a few certified DECtapes from time to time
and use them to check that the drive is in limits. For this reason
DECUS would only accept library sumissions on certified DECtape.
My first diagnostic step after a misread was to format a tape on that
drive and put it on the exerciser diagnostic for a few hours. Just an
error free reformat proves that much of the hardware is OK.
Sadly, you won't find mention of this in DEC's manuals. Often a luser
found out the hard way. Call in field circus to do a PM, the DECtape
drive is re-aligned and some of the user's tapes become unreadable.
>Pretty much seems to be the same faulty data ever time. I have seen
>one bit change in a couple of areas when I tried swapping two of
>the external bus boards, but not every time then either. Originally
>I thought is was just a bit being dropped and was pretty sure I
>could localize it to a problem in the external 8i bus interface. But
>now that does not seem to be the case or at least it's not a single
>bit. I could send this tape back to Dave and ask him to read it to
>verify it has the data he says it should. I don't know of anyone
>really close that would be able to read this tape for me (the
>first block).
OK, if a flakey bit swaps with a card you've got hardware problems.
As they're not solid failures I think that I'd be looking for noise.
Is it reporting parity errors? I'd rather assumed that you were
investigating the result of a parity error.
Regards,
David P.
.
David Gesswein
Tim Radde <tra...@excite.com> wrote:
>On Mar 1, 1:24 pm, d...@pdp8.net (David Gesswein) wrote:
>> In article <388203be-e478-454f-bef4-e5c924f9d...@41g2000hsc.googlegroups.com>,
>your
>DumpRest to create a bootable OS/8 tape. That's when I noticed
>there were certain bits missing on reading back. I'll see what I can
>do.
>
write an all 0's and/or all 1's tape. That will be the easiest to see
whats going on with a scope. You will need to trigger off a TC08
signal indicating your in the data portion since the block, checksum etc
words will be different. You can check the write data to the drive
to see if it is writing properly and then check the data read back.
Tim Radde
I never saw any indication this was a parity error. I can't say that
swapping
cards caused any solid bit errors or movement. Just occasionally I
would
see an extra bit or a dropped bit. Mostly it was the same invalid
data
time after time.
How does one fix the alignment, or do I just not worry about it
and format tapes for use here. What's odd is I know I booted OS/8
on using a TD8e when first got this drive. I no longer have the
TD8e. So I thought I'd get it to work with the TC08. I will run
the diags as soon as I can. I may try the format a tape on the
drive and then run the diags. I know there were no problems finding
all the blocks on the tape. That part of the diags worked fine.
Thanks.
Tim Radde
So is formatting the same as writing timing/mark tracks? Where I have
to
flip the switch on the TC08 to be able to write those? I have never
formatted
a dectape ever, so want to be sure. Or is formatting something else?
Thanks. I am thinking of trying to format one here and see what
happens.
Just not sure how.
David Gesswein
Tim Radde <tra...@excite.com> wrote:
>So is formatting the same as writing timing/mark tracks? Where I have to
>flip the switch on the TC08 to be able to write those? I have never
>formatted
>a dectape ever, so want to be sure. Or is formatting something else?
>
find it aborts with an error. The TD8E formatter verifies what it wrote to
the tape as part of the format so your drive problems may prevent a sucessful
format.
Tim Radde
> In article <ad78f2d7-8a19-4e5b-8beb-bdc120dfa...@p43g2000hsc.googlegroups.com>,
Only one way to find out. Can someone point me to a paper tape image
of the
TC08 formatter? I can only find the TD8e one. Thanks.
David Gesswein
Tim Radde <tra...@excite.com> wrote:
>Only one way to find out. Can someone point me to a paper tape image
>of the
>TC08 formatter? I can only find the TD8e one. Thanks.
>
Any save file on my software archive can be converted back to paper
tape image by clicking on more (or the file name for .SV) and
select convert to bin loader format.
This image has a copy (dtfrmt.sv)
http://www.pdp8.net/pdp8cgi/os8_html?act=dir;fn=images/os8/diagpack2.rk05;sort=name#DTCOPY.SV
This has a .BN file, use the convert to 8 bit PIP image format option.
http://www.pdp8.net/pdp8cgi/os8_html?act=dir;fn=images/jby/jby9.tu56;sort=name
Also the TC01 formatter is at
http://www.pdp12.org/pdp-common/reference/papertapes/dec-08.html
Tim Radde
> In article <0d354e47-aa92-410e-b86b-ab70d10b8...@n77g2000hse.googlegroups.com>,
> Tim Radde <tra...@excite.com> wrote:
>
> >Only one way to find out. Can someone point me to a paper tape image
> >of the
> >TC08 formatter? I can only find the TD8e one. Thanks.
>
> Any save file on my software archive can be converted back to paper
> tape image by clicking on more (or the file name for .SV) and
> select convert to bin loader format.
> This has a .BN file, use the convert to 8 bit PIP image format option.http://www.pdp8.net/pdp8cgi/os8_html?act=dir;fn=images/jby/jby9.tu56;...
I didn't know I could save individual SV format programs from your
site like this. Very nice. I only knew
of the entire image able to be saved in various formats.
I found some notes on the TU56 about what came with it when I got it.
Several tapes were listed so
I looked thru my stash and on several it says "formatted", but I am
not sure if it meant on this drive
or not. So I tried booting one. It does something and the machine
stays running. Seems to be in
some sort of wait loop. Not sure waiting for what. I did not have a
terminal connected. The tape
mentions a "monitor" and I thought maybe 4k monitor, but the system
ends up in field 1 looping
there so it can't be that. I am not sure if this is an OS/8 tape or
not. There is no little printout stuffed
into the dectape box like I used to do. I'll have to try running an
terminal emulator and see if it echos
anything. I believe I tried this long ago and it did not. But maybe
somehow I have made things a
bit better by other work I have done on this system. Thanks for all
the help/suggestions from
everyone.
Tim
Tim Radde
I do have to make an update. I do in fact get parity errors and
timing errors
on the tape that Dave supplied. I do not get either on the tapes that
were
provided with the TU56. I just wasn't looking at the status panel. I
was
able to load something from one of the tapes that came with the unit,
but
I do not know if it loaded Ok. It ends up looping in field one
waiting for
something. I am going to try to find the source and figure out what
it
is doing and if I lost any bits. I believe this is where I discovered
that
bit six was being dropped. And I am pretty sure it was fine coming
out
of the TC08 so must be somewhere in the external bus logic of the 8i.
I will continue to work this and will also try to create a formatted
tape
from this drive.
TIm
glen herrmannsfeldt
(snip)
> So is formatting the same as writing timing/mark tracks?
> Where I have to flip the switch on the TC08 to be able to
> write those? I have never formatted a dectape ever,
> so want to be sure. Or is formatting something else?
As I understand it, DECtape is block rewritable similar to
floppy disks.
Formatting has to write the block headers which are
not rewritten when a block is rewritten. The results should
be similar to the problems with misaligned floppy drives.
-- glen
Tim Radde
More strangeness. I was using one of the tapes that came with the
TU56 and it was loading fairly well, and would actually execute and
stay running. It was in a loop in field 1, but I don't think all the
code
was there. So I decided to try the other "bootable" tape that came
with this TU56. It wouldn't boot at all, and got parity and timing
errors. So I put the first tape back on and now it gets parity and
timing errors, where it was loading Ok a few minutes previous.
How can this happen? Is it possible the alignment is that close
to being out even on these tapes? I guess I have to copy the
dectape format code over and try to run the format on one of
my other tapes and see if that works.
What else was odd is that this bootblock on this "good" tape
was the same as Dave's, but would read in just fine. It even
overlayed the code and seemed to pick up Ok. And the data
to go to field 1 was there, well except for what should have
been at zero. Not sure what happened there. I did notice
one difference is that Dave's code has a 137 where this had
a 136 for a check value and it seemed to transfer one extra
word to field one. I am not sure if this matters or not.
From what I can tell the looping in field one is supposed to
wait for some character input. But there are no instructions
at zero or one. Location two has an ISZ followed by a jump
back to loc one, that is followed by a jump to zero. So something
odd seemed to happen in field one.
David Powell
<09ddadd8-5209-49b0...@i12g2000prf.googlegroups.com>,
>On Mar 3, 2:53 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> Tim Radde wrote:
>>
>> (snip)
>>
>> > So is formatting the same as writing timing/mark tracks?
>> > Where I have to flip the switch on the TC08 to be able to
>>
>> > write those? I have never formatted a dectape ever,
>> > so want to be sure. Or is formatting something else?
>>
>> As I understand it, DECtape is block rewritable similar to
>> floppy disks.
>>
>> Formatting has to write the block headers which are
>> not rewritten when a block is rewritten. The results should
>> be similar to the problems with misaligned floppy drives.
>>
>> -- glen
>
>More strangeness. I was using one of the tapes that came with the
>TU56 and it was loading fairly well, and would actually execute and
>stay running. It was in a loop in field 1, but I don't think all the
>code
>was there. So I decided to try the other "bootable" tape that came
>with this TU56. It wouldn't boot at all, and got parity and timing
>errors. So I put the first tape back on and now it gets parity and
>timing errors, where it was loading Ok a few minutes previous.
>How can this happen? Is it possible the alignment is that close
>to being out even on these tapes?
Watch the four white cheeks by the heads. As the tape reverses they
should all move a little together and "click". If they don't, first
clean them, then fiddle with the position of the hub wrt backplate
untill they do. The tape should run cleanly across the guides, not
touching the sides. It's supposed to float on an air cushion. A
spool not quite pushed home on the hub can cause mis-reads. Check that
tape spools onto the spool leaving a small gap either side. Push in a
piece of paper to check.
> I guess I have to copy the
>dectape format code over and try to run the format on one of
>my other tapes and see if that works.
>
>What else was odd is that this bootblock on this "good" tape
>was the same as Dave's, but would read in just fine. It even
>overlayed the code and seemed to pick up Ok. And the data
>to go to field 1 was there, well except for what should have
>been at zero. Not sure what happened there. I did notice
>one difference is that Dave's code has a 137 where this had
>a 136 for a check value and it seemed to transfer one extra
>word to field one. I am not sure if this matters or not.
>
>From what I can tell the looping in field one is supposed to
>wait for some character input. But there are no instructions
>at zero or one. Location two has an ISZ followed by a jump
>back to loc one, that is followed by a jump to zero. So something
>odd seemed to happen in field one.
Given that you also have data reliabilty with you RK8, suggest a
thorough check with the processor diagnostics.
Regards,
David P.
David Powell
A bit more beside. It writes a timing track on the two outer tracks
and a mark track on the next two. The most common problem is skew,
where the heads are not normal to tape motion. The fix is to hang a
'scope on the timing track, see what the skew is, then turn the tape
over and repeat. Add shims under the head assembly to correct.
Regards,
David P.
Tim Radde
I believe both of these problems are related with some problem in the
external
bus to the 8i. I can only run one of these devices at a time as I
have no DM04
to handle the multiple DMA requests.
Tim Radde
The 8i itself works fine and passes the maindecs.
Tim Radde
Tried a format. Got thru writing the mark/timing tracks (part 1),
then seemed to scan the tape (part 2),
and failed part way into part 3 which I guess was verifying that it
worked. I do not have a source listing
except for Bob Krten's disassembled version. So I am not sure exactly
what failed or why.
Tim Radde
How many words per block should there be for an 8? The default
appeared to be
129 (201 octal). I have also seen 128 (200 octal) mentioned. Was I
wrong to
use the default? The data written to the new tape appeared to be good
as far
as I checked. So I am not sure why this block is bad. At least not
yet.
I guess I have more work to do.
Tim Radde
>
> - Show quoted text -
The first 25 words match exactly to what I had written in my notes
from
before (correct values). I still got a MT error on the display panel,
but
no parity error.
Running the exercisor I see long spans of tape that read/write good,
and
then short areas that don't.
Rich Alderson
> How many words per block should there be for an 8? The default appeared to
> be 129 (201 octal). I have also seen 128 (200 octal) mentioned. Was I wrong
> to use the default? The data written to the new tape appeared to be good as
> far as I checked. So I am not sure why this block is bad. At least not yet.
> I guess I have more work to do.
128 words is of course the PDP-8 page size. 129 words is the smallest number
of words that will hold a page which is also capable of being represented in an
integral number of frames on the DECtape.
Remember that DECtape originated on the 18-bit family, and the basic format of
the mark track assumes 6 3-bit frames per word. The 12-bit word on the PDP-8
only takes 4 frames, so the least common multiple which fits all requirements
is 129 * 4 = 86 * 6.
Using anything other than the default is for those who want to write their own
DECtape handlers.
--
Rich Alderson "You get what anybody gets. You get a lifetime."
ne...@alderson.users.panix.com --Death, of the Endless