Building ST506 to CDC "Finch" drive hardware interface

[Forgotten Machines]

In an effort to assist the project being documented at

https://www.youtube.com/watch?v=C_hdrK30Sdo&t=1045s

I'm wanting to build a serviceable adapter to image this CDC Finch drive, and I'm hoping that this will be a reasonable adaptation to at least READ the flux transitions on the drive and get them captured before they get accidentally erased or something else goes wrong.

Here's the pinout for this Finch drive, on PDF pages 8-9:

https://bitsavers.computerhistory.org/pdf/cdc/discs/finch/77711061A_SMD_Finch_Adapter_Board_Feb1982.pdf#page=8

Is there a name for this pinout standard, or is it proprietary to this drive?

Has this been done before, or am I forging new territory here?

For reference, here's the best manual bitsavers has for the Finch drive itself, but sadly lacks anything about the hardware interface pinout

http://20.69.243.200/pdf/cdc/discs/finch/77653532C_Finch_Disk_Drive_General_Description_Vol_1_Dec1981.pdf

Thanks to all in advance for your feedback.

Best,

AJ

[Forgotten Machines]

Possibly a better resource for the hardware interface is this manual, starting with PDF pages 40-41

http://20.69.243.200/pdf/cdc/discs/finch/77653332C_Finch_9410-3F_Product_Specification_Mar1982.pdf#page=40

[Al Kossow]

On 5/30/22 3:00 PM, Forgotten Machines wrote:
> In an effort to assist the project being documented at
>
> https://www.youtube.com/watch?v=C_hdrK30Sdo&t=1045s
>
> I'm wanting to build a serviceable adapter to image this CDC Finch drive

Zilog built an adapter from the Finch to another format.
I had collected a few drives to try to recover Zeus from it.
I'll see if I can find my notes on the project.

[Al Kossow]

there is some drive characteristics in the zilog hw reference 03-3237-04_hwRef_Dec82.pdf
they appear to be like the fujitsu 2301 drives with separate clock and data

[David Gesswein]

Looks like this drive has the data separator internal so sends NRZ data with
clock. Will require significant changes for the MFM board to work with. You
can use the SPI interfaces to receive the data but also keeping
syncronization with the byte clock will be difficult. The 6.45 MHz clock
gives 30 instructions between clocks for the PRU.

> --
> You received this message because you are subscribed to the Google Groups "MFM Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mfm-discuss...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/mfm-discuss/ca44b08f-301d-497b-bc76-66215d99cacbn%40googlegroups.com.

[Forgotten Machines]

OK, understood.  Thank you, David, as always.  So instead of just a read data pulse, we also have additional 6.45MHz Clock pulse and Servo Data pulses to capture simultaneously.  I get that that's two more signals than the MFM reader is set up to capture for now.  

BUT, to start, wouldn't it be at least feasible to have the reader device control the drive, and then possibly just use a logic analyzer (like my DSView) to capture at 20, 50 or even 100MHz, and learn how to decode the data from those 3 signals?

That way, we could potentially see how these signals really do result in the end data.

Unless I'm mistaken, the basic control signals work the same, with index, step, direction, etc, right?  

With that initial approach, what might we be missing?

Thanks, everyone for your thoughts on this!

[David Gesswein]

Since this is a one time need using other equipment to capture the data and
the MFM emulator to drive the control interface is probably the easiest
approach.

You will want to capture index, byte clock, read clock, and read data.
Probably can have the MFM board talk to your capture computer to automate.

Decoding should be pretty easy. You have byte clock so you know byte
boundaries. Will need to see what sync pattern they used and if they followed
the suggested format. The CRC section should help in finding polynomial though
I think you have delt with that from your other projects already.
http://www.pdp8online.com/mfm/revb/adding_new_formats.shtml

If drive isn't going ready that will make life more difficult.

> To view this discussion on the web visit https://groups.google.com/d/msgid/mfm-discuss/6ea4d83f-a080-440f-bca0-c8731b88ff8fn%40googlegroups.com.

[Forgotten Machines]

Thanks for this insight, David, very helpful!

We have a separate discussion about this going over on a Discord server for this project, so I thought I'd try to loop back in here.  Here's a comment from a contributor, and I wondered what your thoughts might be:

"MacGyver75 — Today at 1:24 AM

Looking at the schematics of the MFM Disk Reader it does not have a 2nd differential to single ended converter in it's base config. But the Emu extension offers a 2nd one (actually pair as bidi) may the SA1000 adapter has a attiny for providing a clock on the SA1000 Data header not sure if that is what the drive wants, the second half of the 75LBC176 is not connected so some mods may be needed to get the SA1000 Adapter to work with the Finch. To me it looks like the Finch delivers a Differential Read Clock to the host and expects an differential Write clock from the host on the data connector. While the SA1000 http://www.bitsavers.org/pdf/shugart/SA1000/39010-2_SA1000_OEM_Manual_Dec80.pdf expects only a clock from Host. If I get that right there is a plugin for drive emulation and uses a dedicated port for that on that port sits the second SN65HVD33DR so I think with minor rewiring the Emulation plugin could be repurposed as a secondary read(/write) channel for clock/servo info. "

Of course, modification to the C code would be necessary, and I could potentially talk Tom Trebisky or some others into helping me with this should it seem the most feasible route.

The SA1000 adapter, of course, also needs to be adjusted to correct pinout and, the Atmel ATTINY and the 75LBC176 would be questionable may be useful for write function. 

But as of right now, I fully plan on obtaining a logic analyzer capture of your suggested above signals with a deep enough buffer to store multiple revolutions of multiple tracks and heads.

But while the discussion is going, I wanted to put these ideas out there.

All feedback is welcome, always, and thank you!

Best,

AJ

[David Gesswein]

On Tue, May 31, 2022 at 01:01:25PM -0700, Forgotten Machines wrote:
> Thanks for this insight, David, very helpful!
>
>

> "MacGyver75 — Today at 1:24 AM
> Looking at the schematics of the MFM Disk Reader it does not have a 2nd
> differential to single ended converter in it's base config. But the Emu
> extension offers a 2nd one (actually pair as bidi) may the SA1000 adapter
> has a attiny for providing a clock on the SA1000 Data header not sure if
> that is what the drive wants, the second half of the 75LBC176 is not
> connected so some mods may be needed to get the SA1000 Adapter to work with
> the Finch. To me it looks like the Finch delivers a Differential Read Clock
> to the host and expects an differential Write clock from the host on the
> data connector. While the SA1000
> http://www.bitsavers.org/pdf/shugart/SA1000/39010-2_SA1000_OEM_Manual_Dec80.pdf

Cutting and jumpering the SA1000 adapter may be a way to get the pinout.
The chip is single ended to differential so not that useful for reading.
Writing is going to be tough if your trying that. With lines properly terminated
I would think you could just hook the logic analyzer to the + lines. Signals
have looked clean with terminated short cables.

> expects only a clock from Host. If I get that right there is a plugin for
> drive emulation and uses a dedicated port for that on that port sits the
> second SN65HVD33DR so I think with minor rewiring the Emulation plugin
> could be repurposed as a secondary read(/write) channel for clock/servo
> info. "
>

The emulator shares one signal line for reading and writing. The SA1000
adapter doesn't change that.