Read the IPs, nothing mind-blowing. Mention of DMA arbitration, 82072
compatibility. Some mentions in the datasheet about inverting a signal,
dunno if this was just internal to the 82077AA, or if it has to be
actually inverted externally.

On 10/11/2021 11:15, Tomas Slavotinek wrote:
> On 11.10.2021 17:44, Louis Ohland wrote:
>> On 10/11/2021 10:02, Tomas Slavotinek wrote:
>>> transformer module
>
> Patent speech at its best...
>
>

The gate array interface circuit is primarily intended to be used with
the Intel 82077 diskette controller so as to provide compatibility with
DMA controllers which transfer only one byte of data. Diskette
controllers, such as the 82077, contain a sixteen-byte first-in,
first-out (FIFO) buffer, such that there is a possibility whereby a
second or more bytes can be transferred if the data from the diskette
drive is not transferred in time. Without compatibility between the two
controllers, a time-out condition can occur.

So. The Model 90 DMA controller can't do better than one byte of data?

DATA 0-7
-BURST IN, BURST OUT
ADDR 0-2
MDS0-2
CS, RD, WR
MMEN0
MNEN1-2
MET0-1
DRVT0-1

Looking at this, the BURST IN/OUT makes sense, if the DMA controller was
limited. Just not accepting that the Model 90 has a byte wide DMA
controller.

On 10/11/2021 10:02, Tomas Slavotinek wrote:
> How about this:
>
> https://priorart.ip.com/IPCOM/000107744
>
> That would explain the presence of the address/data lines...

The Model 90 maintains hardware compatibility with the Intel 8272
diskette drive controller.

On 10/11/2021 13:17, Louis Ohland wrote:
> The gate array interface circuit is primarily intended to be used with
> the Intel 82077 diskette controller so as to provide compatibility with
> DMA controllers which transfer only one byte of data. Diskette
> controllers, such as the 82077, contain a sixteen-byte first-in,
> first-out (FIFO) buffer, such that there is a possibility whereby a
> second or more bytes can be transferred if the data from the diskette
> drive is not transferred in time. Without compatibility between the two
> controllers, a time-out condition can occur.
>
> So. The Model 90 DMA controller can't do better than one byte of data?
>
> DATA 0-7
> -BURST IN, BURST OUT
> ADDR 0-2
> MDS0-2
> CS, RD, WR
> MMEN0
> MNEN1-2
> MET0-1
> DRVT0-1
>
> Looking at this, the BURST IN/OUT makes sense, if the DMA controller was
> limited. Just not accepting that the Model 90 has a byte wide DMA
> controller.
>
>
> On 10/11/2021 10:02, Tomas Slavotinek wrote:
>> How about this:
>>
>> https://priorart.ip.com/IPCOM/000107744
>>
>> That would explain the presence of the address/data lines...
>

The DMA controller is on the complex, so it depends.

The Model 90 XP in particular was designed with the Type 0 complex in
mind, but we can't say the same thing about the 95 XP. So maybe this has
to do with the 386-era chipsets... that is if we are right about the
DSKBOOT PAL and its function.

There are also some additional restrictions posed on the planar I/O
devices, in regard to the bus width, streaming modes, etc. But I'm not
sure if it adds any DMA restrictions to the mix.

On 11.10.2021 20:17, Louis Ohland wrote:
> The gate array interface circuit is primarily intended to be used with
> the Intel 82077 diskette controller so as to provide compatibility with
> DMA controllers which transfer only one byte of data. Diskette
> controllers, such as the 82077, contain a sixteen-byte first-in,
> first-out (FIFO) buffer, such that there is a possibility whereby a
> second or more bytes can be transferred if the data from the diskette
> drive is not transferred in time. Without compatibility between the two
> controllers, a time-out condition can occur.
>
> So. The Model 90 DMA controller can't do better than one byte of data?
>
> DATA 0-7
> -BURST IN, BURST OUT
> ADDR 0-2
> MDS0-2
> CS, RD, WR
> MMEN0
> MNEN1-2
> MET0-1
> DRVT0-1
>
> Looking at this, the BURST IN/OUT makes sense, if the DMA controller was
> limited. Just not accepting that the Model 90 has a byte wide DMA
> controller.
>
>
> On 10/11/2021 10:02, Tomas Slavotinek wrote:
>> How about this:
>>
>> https://priorart.ip.com/IPCOM/000107744
>>
>> That would explain the presence of the address/data lines...
>

The 90 SSI says the DMA controller can work with 8 bit and 16 bit DMA
slaves. Also, the Type 2 FDC comes up as a Type 1, and uses Type 1 mode
to accept all commands. Way past me.

On 10/11/2021 13:50, Tomas Slavotinek wrote:
> The DMA controller is on the complex, so it depends.
>
> The Model 90 XP in particular was designed with the Type 0 complex in
> mind, but we can't say the same thing about the 95 XP. So maybe this has
> to do with the 386-era chipsets... that is if we are right about the
> DSKBOOT PAL and its function.
>
> There are also some additional restrictions posed on the planar I/O
> devices, in regard to the bus width, streaming modes, etc. But I'm not
> sure if it adds any DMA restrictions to the mix.
>
> On 11.10.2021 20:17, Louis Ohland wrote:
>> The gate array interface circuit is primarily intended to be used with
>> the Intel 82077 diskette controller so as to provide compatibility with
>> DMA controllers which transfer only one byte of data. Diskette
>> controllers, such as the 82077, contain a sixteen-byte first-in,
>> first-out (FIFO) buffer, such that there is a possibility whereby a
>> second or more bytes can be transferred if the data from the diskette
>> drive is not transferred in time. Without compatibility between the two
>> controllers, a time-out condition can occur.
>>
>> So. The Model 90 DMA controller can't do better than one byte of data?
>>
>> DATA 0-7
>> -BURST IN, BURST OUT
>> ADDR 0-2
>> MDS0-2
>> CS, RD, WR
>> MMEN0
>> MNEN1-2
>> MET0-1
>> DRVT0-1
>>
>> Looking at this, the BURST IN/OUT makes sense, if the DMA controller was
>> limited. Just not accepting that the Model 90 has a byte wide DMA
>> controller.
>>
>>
>> On 10/11/2021 10:02, Tomas Slavotinek wrote:
>>> How about this:
>>>
>>> https://priorart.ip.com/IPCOM/000107744
>>>
>>> That would explain the presence of the address/data lines...
>>
>

The 90 and 95 SSI only cover the Type 1 complex unfortunately (it has
specs for "Type 1" and "Type 2", but what that really means is Type 1
"J" and Type 1 "K").

Anyway, we need more info about the actual circuit. I'll try to probe
the planar tomorrow, if the time allows...

On 11.10.2021 21:03, Louis Ohland wrote:
> The 90 SSI says the DMA controller can work with 8 bit and 16 bit DMA
> slaves. Also, the Type 2 FDC comes up as a Type 1, and uses Type 1 mode
> to accept all commands. Way past me.
>
> On 10/11/2021 13:50, Tomas Slavotinek wrote:
>> The DMA controller is on the complex, so it depends.
>>
>> The Model 90 XP in particular was designed with the Type 0 complex in
>> mind, but we can't say the same thing about the 95 XP. So maybe this has
>> to do with the 386-era chipsets... that is if we are right about the
>> DSKBOOT PAL and its function.
>>
>> There are also some additional restrictions posed on the planar I/O
>> devices, in regard to the bus width, streaming modes, etc. But I'm not
>> sure if it adds any DMA restrictions to the mix.
>>
>> On 11.10.2021 20:17, Louis Ohland wrote:
>>> The gate array interface circuit is primarily intended to be used with
>>> the Intel 82077 diskette controller so as to provide compatibility with
>>> DMA controllers which transfer only one byte of data. Diskette
>>> controllers, such as the 82077, contain a sixteen-byte first-in,
>>> first-out (FIFO) buffer, such that there is a possibility whereby a
>>> second or more bytes can be transferred if the data from the diskette
>>> drive is not transferred in time. Without compatibility between the two
>>> controllers, a time-out condition can occur.
>>>
>>> So. The Model 90 DMA controller can't do better than one byte of data?
>>>
>>> DATA 0-7
>>> -BURST IN, BURST OUT
>>> ADDR 0-2
>>> MDS0-2
>>> CS, RD, WR
>>> MMEN0
>>> MNEN1-2
>>> MET0-1
>>> DRVT0-1
>>>
>>> Looking at this, the BURST IN/OUT makes sense, if the DMA controller was
>>> limited. Just not accepting that the Model 90 has a byte wide DMA
>>> controller.
>>>
>>>
>>> On 10/11/2021 10:02, Tomas Slavotinek wrote:
>>>> How about this:
>>>>
>>>> https://priorart.ip.com/IPCOM/000107744
>>>>
>>>> That would explain the presence of the address/data lines...
>>>
>>
>

Actually the Type 1 and Type 0 complexi use the same DMA controller,
originally from the 50Z/55/65/70. Hmm... moar data needed.

On 11.10.2021 21:19, Tomas Slavotinek wrote:
> The 90 and 95 SSI only cover the Type 1 complex unfortunately (it has
> specs for "Type 1" and "Type 2", but what that really means is Type 1
> "J" and Type 1 "K").
>
> Anyway, we need more info about the actual circuit. I'll try to probe
> the planar tomorrow, if the time allows...
>
> On 11.10.2021 21:03, Louis Ohland wrote:
>> The 90 SSI says the DMA controller can work with 8 bit and 16 bit DMA
>> slaves. Also, the Type 2 FDC comes up as a Type 1, and uses Type 1 mode
>> to accept all commands. Way past me.
>>
>> On 10/11/2021 13:50, Tomas Slavotinek wrote:
>>> The DMA controller is on the complex, so it depends.
>>>
>>> The Model 90 XP in particular was designed with the Type 0 complex in
>>> mind, but we can't say the same thing about the 95 XP. So maybe this has
>>> to do with the 386-era chipsets... that is if we are right about the
>>> DSKBOOT PAL and its function.
>>>
>>> There are also some additional restrictions posed on the planar I/O
>>> devices, in regard to the bus width, streaming modes, etc. But I'm not
>>> sure if it adds any DMA restrictions to the mix.
>>>
>>> On 11.10.2021 20:17, Louis Ohland wrote:
>>>> The gate array interface circuit is primarily intended to be used with
>>>> the Intel 82077 diskette controller so as to provide compatibility with
>>>> DMA controllers which transfer only one byte of data. Diskette
>>>> controllers, such as the 82077, contain a sixteen-byte first-in,
>>>> first-out (FIFO) buffer, such that there is a possibility whereby a
>>>> second or more bytes can be transferred if the data from the diskette
>>>> drive is not transferred in time. Without compatibility between the two
>>>> controllers, a time-out condition can occur.
>>>>
>>>> So. The Model 90 DMA controller can't do better than one byte of data?
>>>>
>>>> DATA 0-7
>>>> -BURST IN, BURST OUT
>>>> ADDR 0-2
>>>> MDS0-2
>>>> CS, RD, WR
>>>> MMEN0
>>>> MNEN1-2
>>>> MET0-1
>>>> DRVT0-1
>>>>
>>>> Looking at this, the BURST IN/OUT makes sense, if the DMA controller was
>>>> limited. Just not accepting that the Model 90 has a byte wide DMA
>>>> controller.
>>>>
>>>>
>>>> On 10/11/2021 10:02, Tomas Slavotinek wrote:
>>>>> How about this:
>>>>>
>>>>> https://priorart.ip.com/IPCOM/000107744
>>>>>
>>>>> That would explain the presence of the address/data lines...
>>>>
>>>
>>
>

On Monday, October 11, 2021 at 11:02:17 AM UTC-4, Tomas Slavotinek wrote:
> The only part that doesn't match is the date - 1992-Mar-01.
> That seems rather late, it should be more in the 1989-1991 ballpark.

Don't get too hung up on the date, back in the 90s IBM Legal would routinely take *forever* to finally decide to pursue a patent on something -- especially a rather "simple something" like this patent. Things that had obvious commercial value got patents quickly, hundreds of other invention disclosures could sit in limbo for a long time.

On 15.10.2021 17:08, RickE wrote:
> On Monday, October 11, 2021 at 11:02:17 AM UTC-4, Tomas Slavotinek wrote:
>> The only part that doesn't match is the date - 1992-Mar-01.
>> That seems rather late, it should be more in the 1989-1991 ballpark.
>
> Don't get too hung up on the date, back in the 90s IBM Legal would routinely take *forever* to finally decide to pursue a patent on something -- especially a rather "simple something" like this patent. Things that had obvious commercial value got patents quickly, hundreds of other invention disclosures could sit in limbo for a long time.

Fair point!

I've probed the 5560 planar and here is the pinout of the 64F3110 PAL:

pin 1: DB2
pin 2: DB1
pin 3: DB0
pin 4: *unknown*
pin 5: Ground
pin 6: *unknown*
pin 7: A0
pin 8: A1
pin 9: A2
pin 10: -RD
pin 11: -WR
pin 12: FD conn. pin 9: Drive Type ID0 (TDB: "DRVT0")
pin 13: FD conn. pin 4: Drive Type ID1 (TDB: "DRVT1")
pin 14: FD conn. pin 40: -Motor Enable 2 (TDB: "MMEN2")
pin 15: FD conn. pin 12: -Drive Select 0 (TDB: "MDS0")
pin 16: FD conn. pin 36: Drive Select 2 (TDB: "MDS2")
pin 17: FD conn. pin 27: Media Type ID0 (TDB: "MET0")
pin 18: FD conn. pin 17: Media Type ID1 (TDB: "MET1")
pin 19: *unknown*
pin 20: Vcc (+5 V)
pin 21: FD conn. pin 10: -Motor Enable 1 (TDB: "MMEN1")
pin 22: FD conn. pin 14: -Drive Select 1 (TDB: "MDS1")
pin 23: FD conn. pin 16: -Motor Enable 0 (TDB: "MMEN0")
pin 24: DB7
pin 25: DB6
pin 26: DB5
pin 27: DB4
pin 28: DB3

(pin 1 is marked by a dot and from there it goes counter-clockwise when
looking from the top on the package)

Compare it to the "Gate Array Interface for Disk Controller" diagram:

https://priorart.ip.com/first-page/IPCOM000107744D

Yep, pretty much a perfect match!

The 3 unknown pins will be -BURST_IN, BURST_OUT, and CS (chip select)
most likely. They probably go to some other glue logic somewhere on the
board... I didn't want to disassemble the machine again just because of
this.

So, the PAL mostly deals with the Drive Select, Motor Enable, and
Drive/Media signals. And possibly with the BURST translation as well.
Err, why is it marked as "DSKBOOT" again? :-D

On 11.10.2021 20:17, Louis Ohland wrote:
> The gate array interface circuit is primarily intended to be used with
> the Intel 82077 diskette controller so as to provide compatibility with
> DMA controllers which transfer only one byte of data. Diskette
> controllers, such as the 82077, contain a sixteen-byte first-in,
> first-out (FIFO) buffer, such that there is a possibility whereby a
> second or more bytes can be transferred if the data from the diskette
> drive is not transferred in time. Without compatibility between the two
> controllers, a time-out condition can occur.
>
> So. The Model 90 DMA controller can't do better than one byte of data?
>
> DATA 0-7
> -BURST IN, BURST OUT
> ADDR 0-2
> MDS0-2
> CS, RD, WR
> MMEN0
> MNEN1-2
> MET0-1
> DRVT0-1
>
> Looking at this, the BURST IN/OUT makes sense, if the DMA controller was
> limited. Just not accepting that the Model 90 has a byte wide DMA
> controller.
>
>
> On 10/11/2021 10:02, Tomas Slavotinek wrote:
>> How about this:
>>
>> https://priorart.ip.com/IPCOM/000107744
>>
>> That would explain the presence of the address/data lines...
>

DIMM surprise. I am unaware of any need for diddling with arbitration or
the DMA controller, yet here is a solution possumbly looking for a
problem. The only plausible issue I have seen is interfacing a non-FIFO
DMA controller to a FIFO equipped FDC. Maybe it's the 85F0464
INT/KB/mouse ASIC that has the issue? Dunno.

Where's the plum brandy?

On 10/15/2021 16:44, Tomas Slavotinek wrote:
> So, the PAL mostly deals with the Drive Select, Motor Enable, and
> Drive/Media signals. And possibly with the BURST translation as well.
> Err, why is it marked as "DSKBOOT" again? :-D

Tom, I looked again, not sure. Any leads from 64F3110 go to anything
else other than the ASIC and FDC?

On 16.10.2021 20:55, Louis Ohland wrote:
> Tom, I looked again, not sure. Any leads from 64F3110 go to anything
> else other than the ASIC and FDC?

The address and data lines are shared with the FDC and the other planar
I/O devices.

The floppy interface signals go directly to the floppy connector (not to
the FDC).

The 3 unknown lines go who knows where... probably some glue. I may
revisit this later on, when I have one of the planars with the 64F3110
PAL on the workbench...

Here is how I've solved the PSU problems and why:

https://www.ardent-tool.com/PS55/5560/Power_ATX_Mod.html

The same method could be used for the Model 90 PSU.

The machine is finally up n running:

https://www.ardent-tool.com/PS55/5560/Done_01.jpg
https://www.ardent-tool.com/PS55/5560/Done_02.jpg
https://www.ardent-tool.com/PS55/5560/Done_03.jpg

My LCD didn't like the interlaced "115.2 Hz" mode... had to switch to my
trusty Targa CRT for the Windows session:

https://www.ardent-tool.com/PS55/5560/Screen_04.jpg