Huh, 64F3110 is connected to the FDC, the 85F0464 INT/KB/mouse ASIC,
maybe the FDC header, and possumbly the DBA-ESDI connectors [or at least
it WAS].
https://ardent-tool.com/9590/9590_Planar.html
U67 85F0464 ASIC (int/KB/mouse)
U72 64F3110, TI CF61533FN
U84 N82077AA Floppy Controller
Then I see a single line over to U68, a SIMMple logic, 74-series, I
think. U68 sendts a single trace up to 85F0464
https://ardent-tool.com/datasheets/Intel_82077AA.pdf
FDC reset initialization
Huh. So where is this on the Model 8595?
On 10/11
/2021 05:33, Tomas Slavotinek wrote:
The 64F3110 PAL can be found on the following planars:
https://ardent-tool.com/9590/9590_Planar.html
https://ardent-tool.com/PS55/5560/5560.html
https://ardent-tool.com/9533/9533.html
https://ardent-tool.com/2011_2121/2121_Planar.html
(the PS/1 stuff is unfinished and not listed on the Ardent Tool index)
And possibly many more, since we don't always track the PALs/GALs and
other glue...
PS/1 hmm, unless it uses the PS/2 FDC mode, my theory is probably wrong.
On 11.10.2021 12:00, Tomas Slavotinek wrote:
On 11.10.2021 1:47, Louis Ohland wrote:
Please do. It makes me curious, blue. What is this PAL doing? Is it
memory? Wired to the FDC, that doesn't seem quite sensible.
Why not? The PAL is sitting right next to the FDC and at least some of
the traces go towards the controller.
Does it add function? DSKBOOT seems to suggest something related to
booting,
Yeah... the name. The "DSK" part makes sense - floppy DiSK, DBA DiSK -
could be either (or both) if we go just by the name itself.
not sure it is O/S related, more like IML? Maybe DSKBOOT supports
DBA-ESDI?
That's the thing, everything related to the OS "BOOT" process is handled >>> in software/firmware. I can't think of anything boot-related that would
require a special HW logic.
The only IML-related thing that requires a special HW is the
E0000-FFFFFh range ROM/RAM switching, but that's implemented on the
processor complex.
You must.. probe it! Yes!
What pins of the FDC does it connect to? What other components does it >>>> connect to?
Yep... Probulation time!
How about this for an unsupported rumor... the DSKBOOT connects the FDC >>>> to NVRAM to enable booting from CDROM... ;)
:-D I like the enthusiasm, but that doesn't make much sense. The two
components are already connected to the planar I/O bus. Not because they >>> need to talk to each other directly, but because the CPU needs to be
able to address both of them.
Going by the little information we have currently, I only have one
theory - the PAL handles the FDC reset initialization. The 82077
controller can be switched between 3 different modes (PC AT, PS/2, and
Model 30). This is done by setting two of the inputs in a certain way
when the RESET line is toggled. I'll have to check the datasheet again,
but I don't think this can be achieved with high value pull-up or
something similar in this particular case. So perhaps "DSKBOOT" means
"DiSK controller BOOT"? Though something like "FDCINIT" would make much
sense in this context...
The 64F3110 PAL can be found on the following planars:
https://ardent-tool.com/9590/9590_Planar.html https://ardent-tool.com/PS55/5560/5560.html https://ardent-tool.com/9533/9533.html https://ardent-tool.com/2011_2121/2121_Planar.html
(the PS/1 stuff is unfinished and not listed on the Ardent Tool index)
And possibly many more, since we don't always track the PALs/GALs and
other glue...
PS/1 hmm, unless it uses the PS/2 FDC mode, my theory is probably wrong.
On 11.10.2021 12:00, Tomas Slavotinek wrote:
On 11.10.2021 1:47, Louis Ohland wrote:
Please do. It makes me curious, blue. What is this PAL doing? Is it
memory? Wired to the FDC, that doesn't seem quite sensible.
Why not? The PAL is sitting right next to the FDC and at least some of
the traces go towards the controller.
Does it add function? DSKBOOT seems to suggest something related to
booting,
Yeah... the name. The "DSK" part makes sense - floppy DiSK, DBA DiSK -
could be either (or both) if we go just by the name itself.
not sure it is O/S related, more like IML? Maybe DSKBOOT supports DBA-ESDI? >>That's the thing, everything related to the OS "BOOT" process is handled
in software/firmware. I can't think of anything boot-related that would
require a special HW logic.
The only IML-related thing that requires a special HW is the
E0000-FFFFFh range ROM/RAM switching, but that's implemented on the
processor complex.
You must.. probe it! Yes!
What pins of the FDC does it connect to? What other components does it
connect to?
Yep... Probulation time!
How about this for an unsupported rumor... the DSKBOOT connects the FDC
to NVRAM to enable booting from CDROM... ;)
:-D I like the enthusiasm, but that doesn't make much sense. The two
components are already connected to the planar I/O bus. Not because they
need to talk to each other directly, but because the CPU needs to be
able to address both of them.
Going by the little information we have currently, I only have one
theory - the PAL handles the FDC reset initialization. The 82077
controller can be switched between 3 different modes (PC AT, PS/2, and
Model 30). This is done by setting two of the inputs in a certain way
when the RESET line is toggled. I'll have to check the datasheet again,
but I don't think this can be achieved with high value pull-up or
something similar in this particular case. So perhaps "DSKBOOT" means
"DiSK controller BOOT"? Though something like "FDCINIT" would make much
sense in this context...
Huh, 64F3110 is connected to the FDC, the 85F0464 INT/KB/mouse ASIC,
maybe the FDC header, and possumbly the DBA-ESDI connectors [or at
least > it WAS].
Huh. So where is this on the Model 8595?
Intel has a listing for a PAL to be used on an ISA board under AT mode,
but nothing for PS/2 mode.
I wonder... if this PAL was used on DBA-ESDI systems for some reason.
The 9533 MIGHT have been designed for use with the 2.5" DBA-ESDI that
were used in the ThinkPad 700 720 ?
On 11.10.2021 15:21, Louis Ohland wrote:
Huh, 64F3110 is connected to the FDC, the 85F0464 INT/KB/mouse ASIC,
maybe the FDC header, and possumbly the DBA-ESDI connectors [or at
least > it WAS].
Looking at some more detailed photos, there are quite a few connections between the PAL and the FDC - specifically data lines D0-7 and address
lines A0 and A1 (maybe more). This is part of the planar I/O bus, so
yes, if you see connections that go to the IO/INT controller, that makes perfect sense as well...
Huh. So where is this on the Model 8595?
On the 1S1P planar there's a PAL near the FDC as well, but it's a
different P/N.
On 11.10.2021 16:00, Louis Ohland wrote:
Intel has a listing for a PAL to be used on an ISA board under AT mode,
but nothing for PS/2 mode.
I wonder... if this PAL was used on DBA-ESDI systems for some reason.
The 9533 MIGHT have been designed for use with the 2.5" DBA-ESDI that
were used in the ThinkPad 700 720 ?
It's possible that the PAL implements a few different functions that are
not directly related, but seeing that it's connected to the planar I/O
bus, it probably has nothing to do with the DBA interface (a subset of
the MCA bus, which has no place in the ISA-based PS/2 E and PS/1 systems).
transformer module
On 10/11/2021 10:02, Tomas Slavotinek wrote:
transformer module
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...
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 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...
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.
On Monday, October 11, 2021 at 11:02:17 AM UTC-4, Tomas Slavotinek wrote:patents quickly, hundreds of other invention disclosures could sit in limbo for a long time.
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
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...
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?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 62:18:30 |
| Calls: | 6,654 |
| Files: | 12,200 |
| Messages: | 5,331,626 |