30 Mar
2015
30 Mar
'15
1:47 a.m.
I've gotten my RL-02 -> USB Mass Storage controller mostly working with a few
residual gremlins. Specifically, I've noticed from my testing that I have good packs,
ones that read out almost the same every time, and bad packs, ones where half the bits
seem to be in different states every time I read them. I've left write support
untested until I can solve this problem.
Right now, my working theory is that different controllers had slightly different timing
characteristics, and I may need to adjust more of my DPLL parameters dynamically to deal
with that (something I'd rather avoid). Of course, most of these packs haven't
been put into a drive since the mid-80s, and there could be some bit rot going on.
As many of you have much more experience dealing with these drives than I do, my questions
are:
- What type of long term reliability have people noticed from their RL02K packs?
- Is garbage data sometimes normal for certain packs until they are rewritten with ?fresh?
data?
- Has anyone noticed pack compatibility problems between various computers/RL-02
controllers?
Thanks,
Christopher
30 Mar
30 Mar
2:46 a.m.
Were all of the packs written on systems with the same word length? If come
were written on a PDP8-A, You might get garbage reading them on a PDP11.
On Mon, Mar 30, 2015 at 12:47 AM, Christopher Parish <
christopher.parish at parishcomputers.com> wrote:
I've gotten my RL-02 -> USB Mass Storage
controller mostly working with a
few residual gremlins. Specifically, I've noticed from my testing that I
have good packs, ones that read out almost the same every time, and bad
packs, ones where half the bits seem to be in different states every time I
read them. I've left write support untested until I can solve this problem.
Right now, my working theory is that different controllers had slightly
different timing characteristics, and I may need to adjust more of my DPLL
parameters dynamically to deal with that (something I'd rather avoid). Of
course, most of these packs haven't been put into a drive since the
mid-80s, and there could be some bit rot going on.
As many of you have much more experience dealing with these drives than I
do, my questions are:
- What type of long term reliability have people noticed from their RL02K
packs?
- Is garbage data sometimes normal for certain packs until they are
rewritten with ?fresh? data?
- Has anyone noticed pack compatibility problems between various
computers/RL-02 controllers?
Thanks,
Christopher
5:26 a.m.
On 2015-03-30 08:46, Paul Anderson wrote:
Were all of the packs written on systems with the same
word length? If come
were written on a PDP8-A, You might get garbage reading them on a PDP11.
For some definition of garbage, sure. But it would be the same garbage
every time.
The RL02 pack will use the same physical format no matter if used on a
PDP-8 or PDP-11.
Johnny
On Mon, Mar 30, 2015 at 12:47 AM, Christopher Parish <
christopher.parish at parishcomputers.com> wrote:
> I've gotten my RL-02 -> USB Mass Storage controller mostly working with a
> few residual gremlins. Specifically, I've noticed from my testing that I
> have good packs, ones that read out almost the same every time, and bad
> packs, ones where half the bits seem to be in different states every time I
> read them. I've left write support untested until I can solve this problem.
>
> Right now, my working theory is that different controllers had slightly
> different timing characteristics, and I may need to adjust more of my DPLL
> parameters dynamically to deal with that (something I'd rather avoid). Of
> course, most of these packs haven't been put into a drive since the
> mid-80s, and there could be some bit rot going on.
>
> As many of you have much more experience dealing with these drives than I
> do, my questions are:
>
> - What type of long term reliability have people noticed from their RL02K
> packs?
>
> - Is garbage data sometimes normal for certain packs until they are
> rewritten with ?fresh? data?
>
> - Has anyone noticed pack compatibility problems between various
> computers/RL-02 controllers?
>
> Thanks,
> Christopher
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
5:28 a.m.
On 2015-03-30 07:47, Christopher Parish wrote:
I've gotten my RL-02 -> USB Mass Storage
controller mostly working with a few residual gremlins. Specifically, I've noticed
from my testing that I have good packs, ones that read out almost the same every time, and
bad packs, ones where half the bits seem to be in different states every time I read them.
I've left write support untested until I can solve this problem.
Right now, my working theory is that different controllers had slightly different timing
characteristics, and I may need to adjust more of my DPLL parameters dynamically to deal
with that (something I'd rather avoid). Of course, most of these packs haven't
been put into a drive since the mid-80s, and there could be some bit rot going on.
As many of you have much more experience dealing with these drives than I do, my
questions are:
- What type of long term reliability have people noticed from their RL02K packs?
I have not had any problems with long term reliability. I have packs
that are 20 years old that read just fine.
- Is garbage data sometimes normal for certain packs
until they are rewritten with ?fresh? data?
No.
- Has anyone noticed pack compatibility problems
between various computers/RL-02 controllers?
No.
I suspect you have some issues with your controller, and I wouldn't
think it was timing, but I really don't know enough at this point to
make any smart comments.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
6:36 a.m.
On 30/03/2015 10:28, Johnny Billquist wrote:
On 2015-03-30 07:47, Christopher Parish wrote:
> I've gotten my RL-02 -> USB Mass Storage controller mostly working
> with a few residual gremlins. Specifically, I've noticed from my
> testing that I have good packs, ones that read out almost the same
> every time, and bad packs, ones where half the bits seem to be in
> different states every time I read them.
I have not had any problems with long term
reliability. I have packs
that are 20 years old that read just fine.
I've got some with 35-year old data, written around 1980, that are fine.
I suspect you have some issues with your controller,
and I wouldn't
think it was timing, but I really don't know enough at this point to
make any smart comments.
Christopher, have you tried more than one drive? I have a problem with
one particular pack I was trying to make bootable. It shows no bad
blocks but after successfully SYSGENning a new RT-11 system, any attempt
to make it bootable on Unit 1 failed; it was fine on Unit 0, and still
fine on that unit (what was Unit 0) if the unit select plugs were
swapped to operate it as Unit 1. The drive passes all the diagnostics
except seek timing using the Oscillating Seek test. It looks like a DC
servo problem in the drive, but I'll know for sure later today or
tomorrow when I've done some more work on it.
You could also have damaged packs. I have one that is OK on the low
numbered tracks yet unreliable on the later ones, and I wasn't surprised
to find it has visible damage near the centre.
--
Pete
Pete Turnbull
11:20 a.m.
On 2015-03-30 07:47, Christopher Parish wrote:
> I've gotten my RL-02 -> USB Mass Storage controller
> mostly working with a few residual gremlins.
> Specifically, I've noticed from my testing that I have
> good packs, ones that read out almost the same every
> time, and bad packs, ones where half the bits seem to be
> in different states every time I read them. I've left
> write support untested until I can solve this problem.
>
Hmm, one comment is there will be erase glitches between
sector ID blocks and data blocks, where the erase and write
heads were turned on and off. If you don't have logic to
adequately ignore those bursts, it will foul up everything.
Most likely different vintage controllers may have some
difference in how big those bursts of noise are. Packs that
were written on heavily, or written on by different drives,
may have more complicated patterns of these bursts.
Jon
7:50 p.m.
Were all of
the packs written on systems with the same word length? If come
were written on a PDP8-A, You might get garbage reading them on a PDP11.
For some
definition of garbage, sure. But it would be the same garbage every time.
Johnny Christopher, have you tried more than one drive?
Pete
Yep. The effect seems somewhat random, which is why I suspect a problem with the
controller, although I can't rule the drives out.
there will be erase glitches between sector ID blocks
and data blocks, where the erase and write heads were
turned on and off.
If you don't have logic to adequately ignore those bursts,
it will foul up everything.
Jon
That's accounted for. After the header postamble, the controller goes back to
re-synchronization mode, looking for the data preamble and ignoring the contents.
Is an unmodified RL02 drive involved in this process
or have
you somehow modified a drive and attached the USB interface to
the guts?
Chris
My controller connects to the main logic board of the RL02 where the 40 pin berg
connectors normally attach. The RL02s are otherwise unmodified. As far as the overall
setup, it's just the drive, the controller card, and a PC.
Prototype one photo:
https://drive.google.com/file/d/0B-5J_nrTP33ESDk2QlNYdWFjbXc/view
I'm beginning to suspect I have two problems. Every once in a while (maybe once per
10MB), data is corrupted until the end of a sector, likely a timing glitch or phase
problem in the sampling DPLL. This one doesn't happen all that often, and should be
covered by the sector CRC and a re-read.
Second, I've noticed that the drive seems to mis-seek on occasion. I command the
drive to walk forward or back a single track, and the heads move but sometimes land on the
same starting track. This results in duplicate data for the next 10kB or so, and is
heavily pack dependent. Some packs don't exhibit it, others do. I imagine this is
related to the drive/pack runout condition described in the manual. Until I figure out
more, my plan is to add additional verification to the incoming data, checking the track
it landed on and re-commanding the difference if necessary.
Without a PDP-11 to checkout the drives and packs, it's no fun not having a known good
configuration to start from. :(
Christopher
7:57 p.m.
On Mar 30, 2015, at 7:50 PM, Christopher Parish
<christopher.parish at parishcomputers.com> wrote:
...
Second, I've noticed that the drive seems to mis-seek on occasion. I command the
drive to walk forward or back a single track, and the heads move but sometimes land on the
same starting track. This results in duplicate data for the next 10kB or so, and is
heavily pack dependent. Some packs don't exhibit it, others do. I imagine this is
related to the drive/pack runout condition described in the manual. Until I figure out
more, my plan is to add additional verification to the incoming data, checking the track
it landed on and re-commanding the difference if necessary.
As I recall, RL01/02 have embedded servo (one of the first DEC drives to do so). That
would suggest you have a marginal servo mechanism. As for wrong data, isn?t there a track
(cylinder) number in the headers? I would expect there to be one, so a wrong seek should
be detectable.
paul
11:41 p.m.
On 2015-03-31 01:57, Paul Koning wrote:
Right, right and right. Except I don't know if the servo mechanism
necessarily is marginal. The RL drives are "funny" in that there aren't
even any absolute seeks. When you seek on those drives you simply tell
it "seek n tracks in or out". The value of "n" is something you need
to
calculate based on what your current track is, and what track you want
to get to. And when the seek is done, you repeat if you detect that you
are not on the right track. The drive itself have absolutely no checking
if it got to the right track or not, since it don't even know what the
"right" track is.
And a switch of head select does an implicit seek to whatever track is
closest to the other heads, which means a head switch can cause the
drive to move to a different track. So you always need to do a seek
cycle after a head switch.
While disks would be formatted with the tracks on both side of the
platter aligned, there is no guarantee that the heads in the drive are
actually perfectly aligned, which is why you get the head movement on
head switch.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Mar 30, 2015, at 7:50 PM, Christopher Parish
<christopher.parish at parishcomputers.com> wrote:
...
Second, I've noticed that the drive seems to mis-seek on occasion. I command the
drive to walk forward or back a single track, and the heads move but sometimes land on the
same starting track. This results in duplicate data for the next 10kB or so, and is
heavily pack dependent. Some packs don't exhibit it, others do. I imagine this is
related to the drive/pack runout condition described in the manual. Until I figure out
more, my plan is to add additional verification to the incoming data, checking the track
it landed on and re-commanding the difference if necessary.
As I recall, RL01/02 have embedded servo (one of the first DEC drives to do so). That
would suggest you have a marginal servo mechanism. As for wrong data, isn?t there a track
(cylinder) number in the headers? I would expect there to be one, so a wrong seek should
be detectable. 
11:52 p.m.
That's a very interesting project. Do you have plans to make this
thing available in some form once the bugs are out?
It's high time someone collated all the 'new hardware' projects out
there - this, Vince's Omnibus memory boards, the widget drive
replacements for Lisa, Guy Sotomayor's stuff, all these things -
should be a one-stop shop where info on all this stuff is held. Rich
Alderson, I know you guys have done work towards plug-compatible
pdp-10 memory & disk replacements, do you think that could ever be
shared? I'd love to see a Massbus connector with a CF or SD card
slot... :-)
Maybe I'll have to take up the job of collating these projects :-)
On Tue, Mar 31, 2015 at 4:41 PM, Johnny Billquist <bqt at update.uu.se> wrote:
On 2015-03-31 01:57, Paul Koning wrote:
Right, right and right. Except I don't know if the servo mechanism
necessarily is marginal. The RL drives are "funny" in that there aren't
even
any absolute seeks. When you seek on those drives you simply tell it "seek n
tracks in or out". The value of "n" is something you need to calculate
based
on what your current track is, and what track you want to get to. And when
the seek is done, you repeat if you detect that you are not on the right
track. The drive itself have absolutely no checking if it got to the right
track or not, since it don't even know what the "right" track is.
And a switch of head select does an implicit seek to whatever track is
closest to the other heads, which means a head switch can cause the drive to
move to a different track. So you always need to do a seek cycle after a
head switch.
While disks would be formatted with the tracks on both side of the platter
aligned, there is no guarantee that the heads in the drive are actually
perfectly aligned, which is why you get the head movement on head switch.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
--
http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'
On Mar 30, 2015, at 7:50 PM, Christopher Parish
<christopher.parish at parishcomputers.com> wrote:
...
Second, I've noticed that the drive seems to mis-seek on occasion. I
command the drive to walk forward or back a single track, and the heads move
but sometimes land on the same starting track. This results in duplicate
data for the next 10kB or so, and is heavily pack dependent. Some packs
don't exhibit it, others do. I imagine this is related to the drive/pack
runout condition described in the manual. Until I figure out more, my plan
is to add additional verification to the incoming data, checking the track
it landed on and re-commanding the difference if necessary.
As I recall, RL01/02 have embedded servo (one of the first DEC drives to
do so). That would suggest you have a marginal servo mechanism. As for
wrong data, isn?t there a track (cylinder) number in the headers? I would
expect there to be one, so a wrong seek should be detectable. 
31 Mar
31 Mar
2:13 a.m.
On Tue, Mar 31, 2015 at 04:52:13PM +1300, Mike Ross wrote:
That's a very interesting project. Do you have
plans to make this
thing available in some form once the bugs are out?
It's high time someone collated all the 'new hardware' projects out
there - this, Vince's Omnibus memory boards, the widget drive
replacements for Lisa, Guy Sotomayor's stuff, all these things -
should be a one-stop shop where info on all this stuff is held. Rich
Alderson, I know you guys have done work towards plug-compatible
pdp-10 memory & disk replacements, do you think that could ever be
shared? I'd love to see a Massbus connector with a CF or SD card
slot... :-)
I second that, I'd want it for my 2020! It could be retrofitted into a
terminator :)
/P
30 Mar
30 Mar
11:35 p.m.
On 2015-03-31 01:50, Christopher Parish wrote:
That was my thought as well, even if I was dealing with 12-bit data word size packs, I
should always get the same data every read out
Right.
Seems more likely to be the controller. But we shouldn't rule anything
out. :-)
[...]
Were all of the packs written on systems with the same
word length? If come
were written on a PDP8-A, You might get garbage reading them on a PDP11.
For some
definition of garbage, sure. But it would be the same garbage every time.
Johnny Christopher,
have you tried more than one drive?
Pete
Yep. The effect seems somewhat random, which is why I suspect a problem with the
controller, although I can't rule the drives out. Second, I've noticed that the drive seems to
mis-seek on occasion. I command the drive to walk forward or back a single track, and the
heads move but sometimes land on the same starting track. This results in duplicate data
for the next 10kB or so, and is heavily pack dependent. Some packs don't exhibit it,
others do. I imagine this is related to the drive/pack runout condition described in the
manual. Until I figure out more, my plan is to add additional verification to the
incoming data, checking the track it landed on and re-commanding the difference if
necessary.
Without a PDP-11 to checkout the drives and packs, it's no fun not having a known
good configuration to start from. :(
I assume you are aware of that any software driver for the RL drives
needs to read the headers to verify that they are on the right track,
after doing a head select (or rather a change in which head you have
selected), and do a new seek if on the wrong track. Repeat until on the
right track.
Essentially, seeks on the RL drives are not reliable, and you must
always first check that you are on the right track before doing anything
else.
I would almost suspect your controller is just fine in this aspect.
(This is documented in manuals, if you read enough.)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
31 Mar
31 Mar
1:43 a.m.
Second,
I've noticed that the drive seems to mis-seek on occasion.
[...]
I assume you are aware of that any software driver for the RL drives
needs to read the headers to verify that they are on the right track,
after doing a head select (or rather a change in which head you have
selected), and do a new seek if on the wrong track. Repeat until on the
right track.
Essentially, seeks on the RL drives are not reliable, and you must
always first check that you are on the right track before doing anything
else.
I would almost suspect your controller is just fine in this aspect.
(This is documented in manuals, if you read enough.)
Johnny
11:26 p.m.
Thanks for your help everyone. I finally figured out what was happening. Something is
wrong with my (everyone's?) drives. Every once in a while I get stuck on a track.
The drive has no conception of where it is cylinder-wise. It just accepts a difference in
track number and direction, so something like this was occurring:
Current Track:0 Desired track:1 Commanded Difference:+1
Current Track:0 Desired track:1 Commanded Difference:+1
... Repeat N times ...
Current Track:0 Desired track:1 Commanded Difference:+1
I've fixed it by having my controller perturb the track number after several (5)
unsuccessful seeks:
Current Track:0 Desired track:1 Commanded Difference:+1
...
Current Track:0 Desired track:1 Commanded Difference:+1
Current Track:0 Desired track:1 Commanded Difference:+2
Current Track:2 Desired track:1 Commanded Difference:-1
Current Track:1 Desired track:1 Commanded Difference:0 (YAY!)
In the process, I have confirmed that sometimes the drive does mis-seek when making larger
jumps across the pack. A single follow up seek is almost always enough.
I have a feeling this is related to the the special things the RL02 does when making
single track movements (kick pulses?) that must not be working very well in my drives. Of
course, this could be totally normal, and the controllers/software drivers hide it.
Regardless, it never hurts to make the controller more robust than it needs to be.
Christopher
11:41 p.m.
On Tue, Mar 31, 2015 at 11:26 PM, Christopher Parish
<christopher.parish at parishcomputers.com> wrote:
Thanks for your help everyone. I finally figured out
what was happening. Something is wrong with my (everyone's?) drives.
...this could be totally normal, and the controllers/software drivers hide it.
I'd have to dig out driver code (perhaps rl.c from 2BSD would be the
quickest to read and digest if you already know C) but IIRC, yes...
all the drivers "hide this" because that's what the drives do. I
don't know chapter and verse about how they handle multiple 1-track
seek fails (the OS/8 RL8A driver probably has the least room for fancy
footwork), but they should all handle this to one degree or another.
I'm very interested in this. I have a *lot* of packs to image and it
would be nice to not have to run them across a serial port or to dump
them on a real MicroVAX or Unibus VAX and transport the images off of
that.
I look forward to your continued success!
-ethan
1 Apr
1 Apr
1:49 p.m.
On Mar 31, 2015, at 11:41 PM, Ethan Dicks
<ethan.dicks at gmail.com> wrote:
On Tue, Mar 31, 2015 at 11:26 PM, Christopher Parish
<christopher.parish at parishcomputers.com> wrote:
The general rule of device drivers is to assume that the hardware is misbehaving, and
double check everything. If it looks like the seek didn?t work right, reissue it, or tell
the drive to recalibrate and then reissue it, or whatever it takes to beat the device into
conformance. In the case of the RL01/02, the details are a bit different because seek is
by delta rather than absolute cylinder number, but the basic principle carries over.
paul
Thanks for your help everyone. I finally figured
out what was happening. Something is wrong with my (everyone's?) drives.
...this could be totally normal, and the controllers/software drivers hide it.
I'd have to dig out driver code (perhaps rl.c from 2BSD would be the
quickest to read and digest if you already know C) but IIRC, yes...
all the drivers "hide this" because that's what the drives do. I
don't know chapter and verse about how they handle multiple 1-track
seek fails (the OS/8 RL8A driver probably has the least room for fancy
footwork), but they should all handle this to one degree or another.
31 Mar
31 Mar
11:58 p.m.
On 2015-04-01 05:26, Christopher Parish wrote:
Thanks for your help everyone. I finally figured out
what was happening. Something is wrong with my (everyone's?) drives. Every once in a
while I get stuck on a track. The drive has no conception of where it is cylinder-wise.
It just accepts a difference in track number and direction, so something like this was
occurring:
Current Track:0 Desired track:1 Commanded Difference:+1
Current Track:0 Desired track:1 Commanded Difference:+1
... Repeat N times ...
Current Track:0 Desired track:1 Commanded Difference:+1
I've fixed it by having my controller perturb the track number after several (5)
unsuccessful seeks:
Current Track:0 Desired track:1 Commanded Difference:+1
...
Current Track:0 Desired track:1 Commanded Difference:+1
Current Track:0 Desired track:1 Commanded Difference:+2
Current Track:2 Desired track:1 Commanded Difference:-1
Current Track:1 Desired track:1 Commanded Difference:0 (YAY!)
In the process, I have confirmed that sometimes the drive does mis-seek when making
larger jumps across the pack. A single follow up seek is almost always enough.
I have a feeling this is related to the the special things the RL02 does when making
single track movements (kick pulses?) that must not be working very well in my drives. Of
course, this could be totally normal, and the controllers/software drivers hide it.
Regardless, it never hurts to make the controller more robust than it needs to be.
This sounds strange. Are you sure you are not just fiddling with the
head here? A head switch will taste like a seek, but it might actually
not move you as you would expect...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
1 Apr
1 Apr
2:09 a.m.
This sounds strange. Are you sure you are not just
fiddling with the
head here? A head switch will taste like a seek, but it might actually
not move you as you would expect...
Johnny
The head bit is not adjacent to the cylinder offset field in the command word, and
I've verified with the logic analyzer that my intended commands are being sent.
Actually, it's ironic because the head alignment on my drive is near perfect. I can
switch heads and I am on the same track, opposite side, every time.
Now I'm almost certain this seeking problem has something to do with the logic on the
drive because so far, the drive only ever mis-seeks when trying to land on an odd numbered
track. The controller re-issues the seek, but there's a time penalty.
A normal single track seek on my drive takes ~12ms. Most bad seeks to odd numbered tracks
tend to take me an additional track beyond what I wanted, requiring another ~12ms seek to
get back on track. Not that performance is a key factor here, but I'd like to
understand why this is happening.
Christopher
2:27 a.m.
This sounds
strange. Are you sure you are not just fiddling with the
head here? A head switch will taste like a seek, but it might actually
not move you as you would expect...
Johnny
The head bit is not adjacent to the cylinder offset field in the command
word, and I've verified with the logic analyzer that my intended commands
are being sent. Actually, it's ironic because the head alignment on my
drive is near perfect. I can switch heads and I am on the same track,
opposite side, every time.
Now I'm almost certain this seeking problem has something to do with the
logic on the drive because so far, the drive only ever mis-seeks when
trying to land on an odd numbered track. The controller re-issues the
seek, but there's a time penalty.
A normal single track seek on my drive takes ~12ms. Most bad seeks to odd
numbered tracks tend to take me an additional track beyond what I wanted,
requiring another ~12ms seek to get back on track. Not that performance
is a key factor here, but I'd like to understand why this is happening.
Christopher
6:02 a.m.
On 01/04/2015 07:27, E. Groenenberg wrote:
Could this odd behavior have something to do with the
revision of the
internal RL02 controller board? From what I remember, there a 3 versions
of this board.
Indeed, but the earliest (54-12175) only works on an RL01 (the second is
54-13531, used on RL02s as well), and the third (54-14025) has (at
least) three variations I've seen. One is used for drives with brushes,
those modified to Rev. K1 and L1 have have obvious mods to deal with the
lack of brushes and take a while to bring a pack ready after pressing
load, and the later variations have no visible wired mods and bring the
pack ready much more quickly.
--
Pete
Pete Turnbull
6:01 a.m.
On 01/04/2015 07:09, Christopher Parish wrote:
On 01/04/2015 04:58, Johnny Billquist wrote:
> This sounds strange. Are you sure you are not just fiddling with
> the head here? A head switch will taste like a seek, but it might
> actually not move you as you would expect...
Actually, it's ironic because the
head alignment on my drive is near perfect. I can switch heads and I
am on the same track, opposite side, every time.
That doesn't necessarily mean they're perfectly aligned, because the
servo will correct for small differences. Switching heads and still
being on the same track is what's supposed to happen even if the heads
are almost half a track off. You'd need to check with a scope to be sure.
A normal single track seek on my drive takes ~12ms.
That's about right, if a shade fast. "Less than 17ms" is nominal; mine
take about 14-15ms. Have you tried setting up an oscillating seek over
longer distances? It should be about 55ms for 170 tracks, and a little
less than 100ms (about 95ms on mine) for 511 tracks.
Most bad seeks
to odd numbered tracks tend to take me an additional track beyond
what I wanted, requiring another ~12ms seek to get back on track.
That's similar to what mine did with a faulty DLM, although I don't know
that it made a difference whether the destination was an odd or even
track. I did notice that sometimes the heads would move beyond track
511 into the guard area in the centre of the disk, and the times went up
from ~95ms to around 110ms or more. It no longer does
that, of course.
--
Pete
Pete Turnbull
6:01 a.m.
On 01/04/2015 04:58, Johnny Billquist wrote:
On 2015-04-01 05:26, Christopher Parish wrote:
> Thanks for your help everyone. I finally figured out what was
> happening. Something is wrong with my (everyone's?) drives.
> In the process, I have confirmed that sometimes
the drive does
> mis-seek when making larger jumps across the pack. A single follow up
> seek is almost always enough.
This sounds strange. Are you sure you are not just
fiddling with the
head here? A head switch will taste like a seek, but it might actually
not move you as you would expect...
It does sound strange. As I mentioned a couple of days ago, I've been
ministering to an RL02 that occasionally had problems on the outer
tracks (possibly elsewhere but I never noticed that). Copying packs and
almost all seek/read/write worked fine but a very few operations didn't.
All the voltage, alignment and timing tests in the technical manual
checked out except for jitter running the oscillating seek tests (access
time checks) - especially for longer seeks. To cut a long story short,
there was a fault in the drive's DLM. Replacing it removed the jitter
and the drive now behaves perfectly.
--
Pete
Pete Turnbull
30 Mar
30 Mar
11:43 a.m.
On Mon, 30 Mar 2015 05:47:26 +0000
Christopher Parish <christopher.parish at parishcomputers.com> wrote:
I've gotten my RL-02 -> USB Mass Storage
controller mostly working
with a few residual gremlins. Specifically, I've noticed from my
testing that I have good packs, ones that read out almost the same
every time, and bad packs, ones where half the bits seem to be in
different states every time I read them. I've left write support
untested until I can solve this problem.
Right now, my working theory is that different controllers had
slightly different timing characteristics, and I may need to adjust
more of my DPLL parameters dynamically to deal with that (something
I'd rather avoid). Of course, most of these packs haven't been put
into a drive since the mid-80s, and there could be some bit rot going
on.
As many of you have much more experience dealing with these drives
than I do, my questions are:
- What type of long term reliability have people noticed from their
RL02K packs?1
I've found the reliability of RL01s and RL02s to be excellent. I have
(3) RL02's drives I use regularly with about (30) different cartridges.
Over the years I have rarely had problems reading/writing packs between
drives.
- Is garbage data sometimes normal for certain packs
until they are
rewritten with ?fresh? data?
I have had packs on rare occasions which when I first obtained them had
a few records which were unreadable - and a clean reformat made them
100% error free. After doing so, the packs will run reliably for years.
- Has anyone noticed pack compatibility problems
between various
computers/RL-02 controllers?
No.
Regards,
Lyle
--
Bickley Consulting West Inc.
http://bickleywest.com
"Black holes are where God is dividing by zero"
12:07 p.m.
Is an unmodified RL02 drive involved in this process or have you somehow
modified a drive and attached the USB interface to the guts?
In an unmodified drive, you can adjust the read gain (it's part of the
tuneup/calibration process) and I found that after doing this adjustment
and even increasing the gain slightly beyond what the spec called out,
I was able to turn suspect or unreliable packs to reliable ones.
I think you can encounter varying read levels from the packs as a function
of the drives they were written on and maybe even degradation in signal
level over time. A slight "tweak" to your read gain can make up for this,
that is, if you still have the read amplifier circuit in the drive :-)
Chris
On Monday (03/30/2015 at 08:43AM -0700), Lyle Bickley wrote:
On Mon, 30 Mar 2015 05:47:26 +0000
Christopher Parish <christopher.parish at parishcomputers.com> wrote:
--
Chris Elmquist
I've gotten my RL-02 -> USB Mass Storage
controller mostly working
with a few residual gremlins. Specifically, I've noticed from my
testing that I have good packs, ones that read out almost the same
every time, and bad packs, ones where half the bits seem to be in
different states every time I read them. I've left write support
untested until I can solve this problem.
Right now, my working theory is that different controllers had
slightly different timing characteristics, and I may need to adjust
more of my DPLL parameters dynamically to deal with that (something
I'd rather avoid). Of course, most of these packs haven't been put
into a drive since the mid-80s, and there could be some bit rot going
on.
As many of you have much more experience dealing with these drives
than I do, my questions are:
- What type of long term reliability have people noticed from their
RL02K packs?1
I've found the reliability of RL01s and RL02s to be excellent. I have
(3) RL02's drives I use regularly with about (30) different cartridges.
Over the years I have rarely had problems reading/writing packs between
drives.
- Is garbage data sometimes normal for certain
packs until they are
rewritten with ?fresh? data?
I have had packs on rare occasions which when I first obtained them had
a few records which were unreadable - and a clean reformat made them
100% error free. After doing so, the packs will run reliably for years.
- Has anyone noticed pack compatibility problems
between various
computers/RL-02 controllers?
No.
Regards,
Lyle
--
Bickley Consulting West Inc.
http://bickleywest.com
"Black holes are where God is dividing by zero"
3478
days inactive
3480
days old
23 comments
12 participants
participants (12)
-
bqt＠update.uu.se -
chrise＠pobox.com -
christopher.parish＠parishcomputers.com -
elson＠pico-systems.com -
ethan.dicks＠gmail.com -
lbickley＠bickleywest.com -
paulkoning＠comcast.net -
pete＠dunnington.plus.com -
pontus＠Update.UU.SE -
quapla＠xs4all.nl -
tmfdmike＠gmail.com -
useddec＠gmail.com