Re: [PATCH 0/4] Mac IOP driver fixes

[Finn Thain <fthain@telegraphics.com.au>]

On Mon, 1 Jun 2020, Brad Boyer wrote:

> On Tue, Jun 02, 2020 at 09:32:29AM +1000, Finn Thain wrote:
> > I'm hoping that the SWIM IOP can be used in bypass mode, so it could 
> > be used with the swim.c driver. I haven't been able to make that work 
> > yet.
> 
> Putting the IOP in bypass mode would have a couple issues. The obvious 
> one is that it will break ADB (and because the shift register attached 
> to the ADB transceiver is part of the IOP chip itself, there's not an 
> easy fix for that)

I see.

> but there's also some strangeness in the way the SWIM chip is attached 
> to the IOP chip that looks like it might break a few things. In 
> particular, it looks like they only enabled using the SWIM chip in ISM 
> mode and not IWM mode.

IIUC, swim.c only uses ISM mode.

> The notes I have imply that the normal Mac floppy driver didn't work on 
> a IIfx even in bypass mode.

I abandoned my failed attempt to put the SWIM IOP into bypass mode when I 
finally came across this text in the HW09 tech note:

    "Like the processor which controls floppy disk and ADB I/O, the IIfx 
    has another ASIC to control the SCC, but unlike the former, this 
    processor is capable of running in a special 'IOP Bypass' mode which 
    allows direct access to the SCC."

I suppose the problem being alluded to here is the one you mentioned: to 
put this IOP in bypass would kill ADB functionality (for the duration).

> In particular, note the direct use of a GPIO line on VIA1 in swim_select 
> in drivers/block/swim.c.  That won't work on an IOP based system as that 
> input line to SWIM doesn't appear to be hooked up to anything that can 
> be accessed directly.
> 
> Here's the way it's put in _Guide to the Macintosh Family Hardware_ 
> (Second Edition), on page 155:
> 
> "An IOP provides the state-control line SEL to the floppy disk drives. 
> Among other functions, this line selects which of the two heads is to be 
> used in a double-sided floppy disk drive."
> 
> The bit in VIA1 register A that is normally the "vHeadSel" line is 
> explicitly listed as "Reserved" on the IIfx.
> 

Yes, I was aware of that issue. But the GTMFH 2ed. figure 9-14 indicates 
that (on the IIfx) pin 12 in the drive connector is driven by the SWIM 
HDSEL pin instead of VIA1 Port A output. So, I wrote a patch to attempt to 
get the SWIM to drive this pin. But nothing worked because I never 
succeeded in putting the chip into bypass mode.

> It's definitely possible to access and drive the SWIM chip in bypass 
> mode, but that doesn't mean it's as transparent as for the SCC driver. 

OK.

BTW, I suspect there may be an issue with swim.c because it doesn't work 
on all models on which it should work. I know it works on Quadra 800, 650 
and a few others.

With regard to PowerBooks, we will need to power up the drive. And with 
regard to the IIfx, the A/UX iop.h header file indicates that, in bypass 
mode, the ISM registers have a 2-byte spacing (instead of 512-byte).

But I wish I knew why the driver doesn't work on an LC III, which 
supposedly has a SWIM 2, just like the Quadra 800.

> Apparently this external input line is not strictly required when the 
> SWIM chip is running in ISM mode. However, our driver appears to force 
> the chip into ISM mode and yet still depends on this input line.
> 

I can't comment on that. I don't really understand the ISM or IWM logic in 
any depth.