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

[Brad Boyer <flar@allandria.com>]

On Thu, Jun 04, 2020 at 02:49:24PM +1000, Finn Thain wrote:
> On Wed, 3 Jun 2020, Brad Boyer wrote:
> > On Tue, Jun 02, 2020 at 01:48:22PM +1000, Finn Thain wrote:
> > > 
> > There does appear to be a bit in the mode register to directly control 
> > the SEL line to the drive. Nothing in our code appears to use it. You 
> > would write HEDSEL to mode0 to clear the line, and write HEDSEL to mode1 
> > to set the line. However, it looks like the first bit in the setup 
> > register controls if that line is input or output. Not sure why we have 
> > it named S_INV_WDATA, but the state machine to the actual floppy drive 
> > is way beyond my comprehension. I'll note that the swim3.c driver uses 
> > the SELECT bit in the control register to do the same basic thing (and 
> > it's the same bit value as HEDSEL in swim.c).
> > 
> 
> I think that agrees with the patch I wrote a couple of years ago, back 
> when I was working on this problem:

Yes, that seems to fit with my understanding. In the pinout list I have
for the original SWIM chip, one line is called /Q3/HEDSEL. The pinout
specifically says it can be configured to either be an input (Q3) or
an output (HEDSEL). However, there's another pin in the list that is
simply listed as HEDSEL. Not sure why they would have had the same
output on two separate pins.

> > I know we at least used to have a problem where the SCC ports only 
> > worked if they were already in bypass mode. There was something we 
> > weren't doing right about setting the bypass mode. I'm not sure if we 
> > ever fixed it. If you turn off the "Compatible Mode" in the Serial 
> > Switch control panel, does the Linux kernel SCC driver still work 
> > afterwards? I know that was a problem at one point.
> > 
> 
> Yes, it's still a problem. This relates directly to patch 2/4, so I asked 
> Stan to confirm this before I sent the present patch series. Apparently 
> the IOP_BYPASS bit is read-only. To effect a switch to bypass mode I 
> believe that it is necessary to send the right message to the IOP kernel.

OK. Yes, I have a list of structures and one of them appears to be the
bypass command. The outbound message is 3 bytes (the command code:4, a
byte for a flag with 0 meaning off and 1 meaning on, and an ID byte).
The reply is a byte of error (0 is success) followed by extra bytes
depending on the error value.

One of the listed error values is "driver in use", so it's possible
it will reject the request. We are just taking advantage of the
existing drivers, so probably both the SWIM and ADB drivers are
still running on the IOP.

It looks like shutting down a driver is another command. The command
byte for that is 2, and the second byte is which driver to stop (0/1).
I'm not sure if there's a way to restart the driver after that other
than reloading everything.

> > > 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.
> > 
> > If I had to guess, the select line isn't in the same place. For example, 
> > on the Mac Portable (which obviously isn't supported in Linux) that line 
> > is apparently in VIA2 register B (as are most of the other bits that 
> > normally show up in register A). Based on looking at the driver, being 
> > unable to drive that line to the disk drive would break lots of stuff, 
> > including the detection of the disk inserted in the drive.
> > 
> 
> OK. I see that figure 9-11 has these details. I never noticed that, being 
> that the Portable seemed to have no relevance.
> 
> We will have to experiment further to find out whether setting this bit 
> has any effect on the LC III.

Thinking of those figures, I'll note that Figure 9-13 specifically
shows HDSEL on the SWIM chip on the IIcx/IIci as not connected while
the VIA1 PA5 output line is connected to the pin on the drive cable.
The IIfx version in Figure 9-14 shows the HDSEL line on the SWIM
chip as the only thing connected to the same pin on the drive cable.

Based on some of the other hints I've read, actually connecting
HDSEL on the SWIM chip to the cable instead of having it accessible
directly by the CPU makes it impossible to use the SWIM in IWM mode.
Perhaps in some later models they gave up and decided to just always
use it in ISM mode so they didn't need to use up a pin on the VIA.

	Brad Boyer
	flar@allandria.com