Re: Connector P2 on 2040/4040 mainboard?

On Wed, Jun 19, 2019 at 4:03 AM Mia Magnusson <mia_at_plea.se> wrote:
> I've had a look at this a while ago.

Excellent, and thanks for all the insightful comments.

> If you modify a SA400 drive (or any other drive) then the interface
> would be locked to that specific drive.

True.

> Although it would be slightly more complicated, the interface would be
> much more universal if it did convert the Commodore "bit 0 and 1"
> stepper motor signals to the regular shugart compatible step/dir
> signals.

Also true.

> That way you could use any PC style disk drive, including for example
> 3.5" 1.44M drives, which would make it super easy to source media
> (although 5.25" media isn't that hard to find, it's far harder and more
> expensive than 3.5" HD disks) and for the 8050/8250/8250LP the disks
> would also physically be compatible with other drives making it easier
> to for example read/write disks with a cryoflux or similar.

I had not considered other drives but, yes, that would be possible.

> A cosnmetic problem with some kind of universal interface board is that
> you would want all connected drives being enabled all the time...

I'd been solving for connecting only a single drive to the board,
which does simplify the select logic.

> The result is that each connected drive needs to have it's own 34-pin
> connector on the interface

I was thinking that might be required to support two drives, with some
buffering to keep the drives independent of each other.

> ...and the LED on each connected drive will
> stay on constantly or could be gated by the motor signal, which might
> not reflect what the LED drive signal from the digital board tries to
> signal.

That's probably why Commodore had the drive LEDs independently
controllable from Select (the 320816 analog board has the HD SEL 0/1
going only to the R/W logic, not to the motor control logic, but the
SA390/SA400 analog board does some logic combining with Select n and
read/write enable lines)

> As I see it, the only slightly tricky part about decoding the stepper
> drive signals to step/direction is that you want to avoid glitches in
> the signals.

Definitely something to watch for.

> Perhaps add some circuit that is triggered by any change
> and has a delay waiting some microseconds before considering the
> signals stable, and then act upon them.

Looking at the code for the 6504 on zimmers.net, it appears that the
stepper logic is handled in an interrupt routine and there's a
built-in settling timer that keeps from driving the steppers too fast.
I didn't run the numbers, but motors of this type do take a few ms to
settle.  That's all handled in the firmware anyway.  The effect is
that the states of S0A/S0B/S1A/S1B only change every few ms during a
seek.

> Any reasonable drive of the stepper drive signals would be either the
> sequence 00,01,10,11,00,01,10,11 or 00,11,10,01,00,11,10,01. For each
> off the four possible states of the control signals, there are only two
> valid changes (one up or one down) so the invalid change (+/- two) can
> be ignored.

Agreed.

> You might be able to decode this using standard 74xx/40xx
> IC's but it seems simpler to use either a small eprom or programmable
> logic. You could also most likely do this with a microcontroller as
> they surely are fast enough to act upon signals intended to drive a
> (relatively slow) stepper motor.

It would certainly be a trivial matter for a small MCU which I have no
problems programming, but if it's implementable in a couple of DIP
packages, I'd still like to consider a discrete logic approach.  I
think a 'LS74 would be required to latch the previous state, but the
"change detected" logic might turn into several packages.

I think even an ATtiny85 should be able to do this (8 pin DIP with 5
GPIO pins before resorting to repurposing the /RESET pin to a GPIO,
which complicates reprogramming so it's a last resort).

> Btw if you or anyone else consider making some kind of universal
> interface, it might be a good idea to also have the ability to connect
> the regular Commodore analogue board to make it possible to combine one
> working Commodore drive with another Shugart/PC compatible drive.

Also an interesting suggestion.  A bit out of scope for my original
project but interesting.

> It might also be a good idea to consider making a board that can do the
> reverse, i.e. making it possible to connect the Commodore analogue
> board to a regular Shugart/PC compatible interface, making it possible
> to use Kryoflux or similar stuff with the non-standard 100 TPI drives
> used in the 8050/8250/8250LP/SFD1001 drives.

I think that's easier because converting from step/dir to a 2-bit
counter is very straightforward.

Finding a real Tandon TM-100-4M to use with a Kryoflux is not easy -
they were never popular compared to 96 TPI drives.  What might be
easier is pulling a TM-100-4M mech from an 8250 and borrowing an
analog board from a TM-100-4 drive.  That would be a much simpler fix
than a custom board, though TM-100-4 drives aren't exactly easy to
find either (compared to TM-100-2A drives which are somewhat abundant
since they were used in 5150 PCs, 5160 XTs and more).

I don't have a lot of 8050/8250 media myself but I do have an 8250
drive and a Zoomfloppy, which is _not_ the same as using a Kryoflux
but it does the job for media that is intact enough to read without
errors.

-ethan