RL02K Pack Reliability/Characteristics

[Christopher Parish]

>> 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

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

> 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