Once found in a dark dumpster, I have relentlessly tried to revive this Ultimedia Video Adapter (7-5) for RS/6000:

http://www.holzapfel.biz/UltimediaVideo7-5.jpg

Here's the tool:

https://www.ardent-tool.com/RS6000/RS6000_7-5.html

I also have the JPEG compression/decompression guest card.

It would be such a nice addition to my -59H or -42T system, and usually when someone claims something being "broken", I usually state they just didn't try hard enough...

It appears to be "broken" in a way that it
a) either falsely reports itself to the bus, like when in RS/6000 diagnostics, the adapter's ID is shown as 0xFFFF or 0x8FFF instead of the actual 0x8F96 ID
b) completely disturbs the Microchannel Bus adapter recognition so that other adapters aren't recognized at all (like Corvette, Audio 7-6, Ethernet 9-K, all show up as ID 0xFFFF in the Diagnostics).

I tried many things to determine what - or where - it is actually broken, like: - warming the board with a fan, both completely and in different local areas
- chilling the board with ice spray, all over and locally
- "baking" the board at ~350 °F / 180 °C like some folks do to revive their GPUs. I know it is not enough to reflow the solder, but success reports pop up here and there
- measuring all MCA Bus pins from the card edge to the MIAMI MCA Interface chip 34G1520, they all beep through. I found one broken via next to U47 and enforced about two dozen by soldering a thin wire through just any suspicious via in that area
- measuring +5 V voltage on the board - of course it's fine
- replacing some of the SMD tantal capacitors near the MCA connection edge

I am close to swapping all generic 74xx logic chips like the 74ABT16245 and 74ABT16652 (U26/27, U32/33, U37/38) which are the *data* bus transceivers between the MIAMI MCA Interface chip and the board-local video processing components on the left side,
because when I see an adapter ID of 0x86FF on the diag, it *could* be falsely transmitted data on the board coming from the MCU (U15) through U26/27, U32/33, U37/38 to the MIAMI (U43).
But then there's the other error where the card completely hogs the Microchannel bus - so it's not all / only about the data, but possibly also about some MCA control lines. (MIAMI, really? Don't leave me.)

Digging into the MIAMI's data sheet https://www.ardent-tool.com/tech/miamimca.html
reveals that this is the 2nd iteration of the chip ("Miami Pass 2 (w/o heat spreader) - 34G1520 No Longer in Production") which has been superseded by 34G1521 which HAS a heat spreader, but assumingly remains the same in silicon.
Could it be my MIAMI - lacking the heat spreader - has gone toast?
From the errata list, nothing describes the errors I am seeing.

Looking at the board, some more conditions make me wonder:
- the board has quite some hand made corrections and additions
- some hand written or -corrected PAL / ASIC labels
Those make me assume this might be one of the earlier boards produced, which makes it an interesting piece of history (at least for me).
Looking at the label of U20 it appears to be printed once, but molten off at some point, so maybe U20 got hot one day? It feels just normal in today's "operation" though.

What I found out about the internal structure:
- The MIAMI (U43) acts as a Microchannel Interface Controller that *should* properly handle all control signals on the MCA Bus and translate this board's local address space onto the Microchannel Bus.
- The upper-right part U41, U53 is the AD/DA video frontend
- Left of MIAMI are the bus transceivers (U26/27, U32/33, U37/38) for the local *data* bus between MIAMI and the digital video processor U16 and (probably) microcontroller U15, which *should* be the component delivering the 0x8F96 ID via local data bus
address 0x1FFA000C according to MIAMI datasheet.
- The mystic PAL logic U20-U25, U28, U30, U34 controls the data bus transceivers' control lines, and probably much more. They are the glue logic for *controlling* everything between the MIAMI and the chips that do the actual video processing.

So what am I missing, what remains there to check?
Unfortunately I don't have a 64 channel logic analyzer to monitor the whole bus - and even then I'm not sure what I would be looking out for.
Any hints?

Thanks,
Christian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dogrob a 34G1520 off a Passplay or Cheetah?

Christian Holzapfel wrote:

Once found in a dark dumpster, I have relentlessly tried to revive this Ultimedia Video Adapter (7-5) for RS/6000:

http://www.holzapfel.biz/UltimediaVideo7-5.jpg

Here's the tool:

https://www.ardent-tool.com/RS6000/RS6000_7-5.html

I also have the JPEG compression/decompression guest card.

It would be such a nice addition to my -59H or -42T system, and usually when someone claims something being "broken", I usually state they just didn't try hard enough...

It appears to be "broken" in a way that it
a) either falsely reports itself to the bus, like when in RS/6000 diagnostics, the adapter's ID is shown as 0xFFFF or 0x8FFF instead of the actual 0x8F96 ID
b) completely disturbs the Microchannel Bus adapter recognition so that other adapters aren't recognized at all (like Corvette, Audio 7-6, Ethernet 9-K, all show up as ID 0xFFFF in the Diagnostics).

I tried many things to determine what - or where - it is actually broken, like:
- warming the board with a fan, both completely and in different local areas - chilling the board with ice spray, all over and locally
- "baking" the board at ~350 °F / 180 °C like some folks do to revive their GPUs. I know it is not enough to reflow the solder, but success reports pop up here and there
- measuring all MCA Bus pins from the card edge to the MIAMI MCA Interface chip 34G1520, they all beep through. I found one broken via next to U47 and enforced about two dozen by soldering a thin wire through just any suspicious via in that area
- measuring +5 V voltage on the board - of course it's fine
- replacing some of the SMD tantal capacitors near the MCA connection edge

I am close to swapping all generic 74xx logic chips like the 74ABT16245 and 74ABT16652 (U26/27, U32/33, U37/38) which are the *data* bus transceivers between the MIAMI MCA Interface chip and the board-local video processing components on the left side,

because when I see an adapter ID of 0x86FF on the diag, it *could* be falsely transmitted data on the board coming from the MCU (U15) through U26/27, U32/33, U37/38 to the MIAMI (U43).

But then there's the other error where the card completely hogs the Microchannel bus - so it's not all / only about the data, but possibly also about some MCA control lines. (MIAMI, really? Don't leave me.)

Digging into the MIAMI's data sheet https://www.ardent-tool.com/tech/miamimca.html
reveals that this is the 2nd iteration of the chip ("Miami Pass 2 (w/o heat spreader) - 34G1520 No Longer in Production") which has been superseded by 34G1521 which HAS a heat spreader, but assumingly remains the same in silicon.
Could it be my MIAMI - lacking the heat spreader - has gone toast?
From the errata list, nothing describes the errors I am seeing.

Looking at the board, some more conditions make me wonder:
- the board has quite some hand made corrections and additions
- some hand written or -corrected PAL / ASIC labels
Those make me assume this might be one of the earlier boards produced, which makes it an interesting piece of history (at least for me).
Looking at the label of U20 it appears to be printed once, but molten off at some point, so maybe U20 got hot one day? It feels just normal in today's "operation" though.

What I found out about the internal structure:
- The MIAMI (U43) acts as a Microchannel Interface Controller that *should* properly handle all control signals on the MCA Bus and translate this board's local address space onto the Microchannel Bus.
- The upper-right part U41, U53 is the AD/DA video frontend
- Left of MIAMI are the bus transceivers (U26/27, U32/33, U37/38) for the local *data* bus between MIAMI and the digital video processor U16 and (probably) microcontroller U15, which *should* be the component delivering the 0x8F96 ID via local data bus

address 0x1FFA000C according to MIAMI datasheet.

- The mystic PAL logic U20-U25, U28, U30, U34 controls the data bus transceivers' control lines, and probably much more. They are the glue logic for *controlling* everything between the MIAMI and the chips that do the actual video processing.

So what am I missing, what remains there to check?
Unfortunately I don't have a 64 channel logic analyzer to monitor the whole bus - and even then I'm not sure what I would be looking out for.
Any hints?

Thanks,
Christian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Look at SSA adapters for a 34G1521, both PCI and MCA use MIAMIs.

Louis Ohland wrote:

Dogrob a 34G1520 off a Passplay or Cheetah?

Christian Holzapfel wrote:

Once found in a dark dumpster, I have relentlessly tried to revive
this Ultimedia Video Adapter (7-5) for RS/6000:

http://www.holzapfel.biz/UltimediaVideo7-5.jpg

Here's the tool:

https://www.ardent-tool.com/RS6000/RS6000_7-5.html

I also have the JPEG compression/decompression guest card.

It would be such a nice addition to my -59H or -42T system, and
usually when someone claims something being "broken", I usually state
they just didn't try hard enough...

It appears to be "broken" in a way that it
a) either falsely reports itself to the bus, like when in RS/6000
diagnostics, the adapter's ID is shown as 0xFFFF or 0x8FFF instead of
the actual 0x8F96 ID
b) completely disturbs the Microchannel Bus adapter recognition so
that other adapters aren't recognized at all (like Corvette, Audio
7-6, Ethernet 9-K, all show up as ID 0xFFFF in the Diagnostics).

I tried many things to determine what - or where - it is actually
broken, like:
- warming the board with a fan, both completely and in different local
areas
- chilling the board with ice spray, all over and locally
- "baking" the board at ~350 °F / 180 °C like some folks do to revive
their GPUs. I know it is not enough to reflow the solder, but success
reports pop up here and there
- measuring all MCA Bus pins from the card edge to the MIAMI MCA
Interface chip 34G1520, they all beep through. I found one broken via
next to U47 and enforced about two dozen by soldering a thin wire
through just any suspicious via in that area
- measuring +5 V voltage on the board - of course it's fine
- replacing some of the SMD tantal capacitors near the MCA connection
edge

I am close to swapping all generic 74xx logic chips like the
74ABT16245 and 74ABT16652 (U26/27, U32/33, U37/38) which are the
*data* bus transceivers between the MIAMI MCA Interface chip and the
board-local video processing components on the left side, because when
I see an adapter ID of 0x86FF on the diag, it *could* be falsely
transmitted data on the board coming from the MCU (U15) through
U26/27, U32/33, U37/38 to the MIAMI (U43).
But then there's the other error where the card completely hogs the
Microchannel bus - so it's not all / only about the data, but possibly
also about some MCA control lines. (MIAMI, really? Don't leave me.)

Digging into the MIAMI's data sheet
https://www.ardent-tool.com/tech/miamimca.html
reveals that this is the 2nd iteration of the chip ("Miami Pass 2 (w/o
heat spreader) - 34G1520 No Longer in Production") which has been
superseded by 34G1521 which HAS a heat spreader, but assumingly
remains the same in silicon.
Could it be my MIAMI - lacking the heat spreader - has gone toast?
 From the errata list, nothing describes the errors I am seeing.

Looking at the board, some more conditions make me wonder:
- the board has quite some hand made corrections and additions
- some hand written or -corrected PAL / ASIC labels
Those make me assume this might be one of the earlier boards produced,
which makes it an interesting piece of history (at least for me).
Looking at the label of U20 it appears to be printed once, but molten
off at some point, so maybe U20 got hot one day? It feels just normal
in today's "operation" though.

What I found out about the internal structure:
- The MIAMI (U43) acts as a Microchannel Interface Controller that
*should* properly handle all control signals on the MCA Bus and
translate this board's local address space onto the Microchannel Bus.
- The upper-right part U41, U53 is the AD/DA video frontend
- Left of MIAMI are the bus transceivers (U26/27, U32/33, U37/38) for
the local *data* bus between MIAMI and the digital video processor U16
and (probably) microcontroller U15, which *should* be the component
delivering the 0x8F96 ID via local data bus address 0x1FFA000C
according to MIAMI datasheet.
- The mystic PAL logic U20-U25, U28, U30, U34 controls the data bus
transceivers' control lines, and probably much more. They are the glue
logic for *controlling* everything between the MIAMI and the chips
that do the actual video processing.

So what am I missing, what remains there to check?
Unfortunately I don't have a 64 channel logic analyzer to monitor the
whole bus - and even then I'm not sure what I would be looking out for.
Any hints?

Thanks,
Christian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

https://www.ebay.com/itm/271310985827

34G1521 does not have a heat spreader.


Louis Ohland wrote:

Look at SSA adapters for a 34G1521, both PCI and MCA use MIAMIs.

Louis Ohland wrote:

Dogrob a 34G1520 off a Passplay or Cheetah?

Christian Holzapfel wrote:

Once found in a dark dumpster, I have relentlessly tried to revive
this Ultimedia Video Adapter (7-5) for RS/6000:

http://www.holzapfel.biz/UltimediaVideo7-5.jpg

Here's the tool:

https://www.ardent-tool.com/RS6000/RS6000_7-5.html

I also have the JPEG compression/decompression guest card.

It would be such a nice addition to my -59H or -42T system, and
usually when someone claims something being "broken", I usually state
they just didn't try hard enough...

It appears to be "broken" in a way that it
a) either falsely reports itself to the bus, like when in RS/6000
diagnostics, the adapter's ID is shown as 0xFFFF or 0x8FFF instead of
the actual 0x8F96 ID
b) completely disturbs the Microchannel Bus adapter recognition so
that other adapters aren't recognized at all (like Corvette, Audio
7-6, Ethernet 9-K, all show up as ID 0xFFFF in the Diagnostics).

I tried many things to determine what - or where - it is actually
broken, like:
- warming the board with a fan, both completely and in different
local areas
- chilling the board with ice spray, all over and locally
- "baking" the board at ~350 °F / 180 °C like some folks do to revive
their GPUs. I know it is not enough to reflow the solder, but success
reports pop up here and there
- measuring all MCA Bus pins from the card edge to the MIAMI MCA
Interface chip 34G1520, they all beep through. I found one broken via
next to U47 and enforced about two dozen by soldering a thin wire
through just any suspicious via in that area
- measuring +5 V voltage on the board - of course it's fine
- replacing some of the SMD tantal capacitors near the MCA connection
edge

I am close to swapping all generic 74xx logic chips like the
74ABT16245 and 74ABT16652 (U26/27, U32/33, U37/38) which are the
*data* bus transceivers between the MIAMI MCA Interface chip and the
board-local video processing components on the left side, because
when I see an adapter ID of 0x86FF on the diag, it *could* be falsely
transmitted data on the board coming from the MCU (U15) through
U26/27, U32/33, U37/38 to the MIAMI (U43).
But then there's the other error where the card completely hogs the
Microchannel bus - so it's not all / only about the data, but
possibly also about some MCA control lines. (MIAMI, really? Don't
leave me.)

Digging into the MIAMI's data sheet
https://www.ardent-tool.com/tech/miamimca.html
reveals that this is the 2nd iteration of the chip ("Miami Pass 2
(w/o heat spreader) - 34G1520 No Longer in Production") which has
been superseded by 34G1521 which HAS a heat spreader, but assumingly
remains the same in silicon.
Could it be my MIAMI - lacking the heat spreader - has gone toast?
 From the errata list, nothing describes the errors I am seeing.

Looking at the board, some more conditions make me wonder:
- the board has quite some hand made corrections and additions
- some hand written or -corrected PAL / ASIC labels
Those make me assume this might be one of the earlier boards
produced, which makes it an interesting piece of history (at least
for me).
Looking at the label of U20 it appears to be printed once, but molten
off at some point, so maybe U20 got hot one day? It feels just normal
in today's "operation" though.

What I found out about the internal structure:
- The MIAMI (U43) acts as a Microchannel Interface Controller that
*should* properly handle all control signals on the MCA Bus and
translate this board's local address space onto the Microchannel Bus.
- The upper-right part U41, U53 is the AD/DA video frontend
- Left of MIAMI are the bus transceivers (U26/27, U32/33, U37/38) for
the local *data* bus between MIAMI and the digital video processor
U16 and (probably) microcontroller U15, which *should* be the
component delivering the 0x8F96 ID via local data bus address
0x1FFA000C according to MIAMI datasheet.
- The mystic PAL logic U20-U25, U28, U30, U34 controls the data bus
transceivers' control lines, and probably much more. They are the
glue logic for *controlling* everything between the MIAMI and the
chips that do the actual video processing.

So what am I missing, what remains there to check?
Unfortunately I don't have a 64 channel logic analyzer to monitor the
whole bus - and even then I'm not sure what I would be looking out for.
Any hints?

Thanks,
Christian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Some PCI SSA cards use BGA mounted ICs on the component side, while the
7-5 uses a flat pack with gull wing leads.

Louis Ohland wrote:

https://www.ebay.com/itm/271310985827

34G1521 does not have a heat spreader.

Louis Ohland wrote:

Look at SSA adapters for a 34G1521, both PCI and MCA use MIAMIs.

Louis Ohland wrote:

Dogrob a 34G1520 off a Passplay or Cheetah?

Christian Holzapfel wrote:

Once found in a dark dumpster, I have relentlessly tried to revive
this Ultimedia Video Adapter (7-5) for RS/6000:

http://www.holzapfel.biz/UltimediaVideo7-5.jpg

Here's the tool:

https://www.ardent-tool.com/RS6000/RS6000_7-5.html

I also have the JPEG compression/decompression guest card.

It would be such a nice addition to my -59H or -42T system, and
usually when someone claims something being "broken", I usually
state they just didn't try hard enough...

It appears to be "broken" in a way that it
a) either falsely reports itself to the bus, like when in RS/6000
diagnostics, the adapter's ID is shown as 0xFFFF or 0x8FFF instead
of the actual 0x8F96 ID
b) completely disturbs the Microchannel Bus adapter recognition so
that other adapters aren't recognized at all (like Corvette, Audio
7-6, Ethernet 9-K, all show up as ID 0xFFFF in the Diagnostics).

I tried many things to determine what - or where - it is actually
broken, like:
- warming the board with a fan, both completely and in different
local areas
- chilling the board with ice spray, all over and locally
- "baking" the board at ~350 °F / 180 °C like some folks do to
revive their GPUs. I know it is not enough to reflow the solder, but
success reports pop up here and there
- measuring all MCA Bus pins from the card edge to the MIAMI MCA
Interface chip 34G1520, they all beep through. I found one broken
via next to U47 and enforced about two dozen by soldering a thin
wire through just any suspicious via in that area
- measuring +5 V voltage on the board - of course it's fine
- replacing some of the SMD tantal capacitors near the MCA
connection edge

I am close to swapping all generic 74xx logic chips like the
74ABT16245 and 74ABT16652 (U26/27, U32/33, U37/38) which are the
*data* bus transceivers between the MIAMI MCA Interface chip and the
board-local video processing components on the left side, because
when I see an adapter ID of 0x86FF on the diag, it *could* be
falsely transmitted data on the board coming from the MCU (U15)
through U26/27, U32/33, U37/38 to the MIAMI (U43).
But then there's the other error where the card completely hogs the
Microchannel bus - so it's not all / only about the data, but
possibly also about some MCA control lines. (MIAMI, really? Don't
leave me.)

Digging into the MIAMI's data sheet
https://www.ardent-tool.com/tech/miamimca.html
reveals that this is the 2nd iteration of the chip ("Miami Pass 2
(w/o heat spreader) - 34G1520 No Longer in Production") which has
been superseded by 34G1521 which HAS a heat spreader, but assumingly
remains the same in silicon.
Could it be my MIAMI - lacking the heat spreader - has gone toast?
 From the errata list, nothing describes the errors I am seeing.

Looking at the board, some more conditions make me wonder:
- the board has quite some hand made corrections and additions
- some hand written or -corrected PAL / ASIC labels
Those make me assume this might be one of the earlier boards
produced, which makes it an interesting piece of history (at least
for me).
Looking at the label of U20 it appears to be printed once, but
molten off at some point, so maybe U20 got hot one day? It feels
just normal in today's "operation" though.

What I found out about the internal structure:
- The MIAMI (U43) acts as a Microchannel Interface Controller that
*should* properly handle all control signals on the MCA Bus and
translate this board's local address space onto the Microchannel Bus.
- The upper-right part U41, U53 is the AD/DA video frontend
- Left of MIAMI are the bus transceivers (U26/27, U32/33, U37/38)
for the local *data* bus between MIAMI and the digital video
processor U16 and (probably) microcontroller U15, which *should* be
the component delivering the 0x8F96 ID via local data bus address
0x1FFA000C according to MIAMI datasheet.
- The mystic PAL logic U20-U25, U28, U30, U34 controls the data bus
transceivers' control lines, and probably much more. They are the
glue logic for *controlling* everything between the MIAMI and the
chips that do the actual video processing.

So what am I missing, what remains there to check?
Unfortunately I don't have a 64 channel logic analyzer to monitor
the whole bus - and even then I'm not sure what I would be looking
out for.
Any hints?

Thanks,
Christian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 29.12.2022 22:24, Christian Holzapfel wrote:

Once found in a dark dumpster, I have relentlessly tried to revive this Ultimedia Video Adapter (7-5) for RS/6000

Since you have already tried all the basic troubleshooting steps, I'm
afraid you will have to do some probing to figure out what's wrong.

I agree that the issue most likely lies somewhere between the MCA edge connector and the MIAMI interface chip (hopefully not inside the ASIC
itself). You don't need a 64-channel analyzer to check the buffers and
the other glue. You can probe them one by one and monitor only a subset
of the data pins together with the relevant control pins (-output
enable, direction, or what have ya).

Before you dive into that, it may be worth checking if the oscillators
are stable and outputting what they are supposed to.

Also, looking at the photo, the A1 pin on the edge connector looks
really suspicious. This is the -CD SETUP line, responsible for putting
the adapter into the setup mode. And that's when the adapter ID is
obtained, among other things. So, an unreliable connection could
definitely cause the described behavior.

You could also test the adapter in another machine (even a PS/2) and
check if the behavior changes in any way.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 30.12.2022 0:37, Louis Ohland wrote:

https://www.ebay.com/itm/271310985827

34G1521 does not have a heat spreader.

Probably an internal IHS...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 30.12.2022 14:25, Louis Ohland wrote:

You can see what appears to be uniformly spaced gouges from the right, seemingly touching the edge of A2.

It looks almost intentional. But given the history of the card, it's
hard to tell what might have caused it. The beveled edge has a few
nibbles taken from it as well.

I wonder what the solder side looks like...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Also, looking at the photo, the A1 pin on the edge connector looks
really suspicious. This is the -CD SETUP line, responsible for putting
the adapter into the setup mode. And that's when the adapter ID is
obtained, among other things. So, an unreliable connection could
definitely cause the described behavior.

Good pointer! On the picture, it's just a reflection. All pins look equally shiny and beep through from the edge of the edge connector (world's end), going to MIAMI.
I thoroughly cleaned all pins and flooded the board with isopropanol and a soft toothbrush, but never saw a change.

Before you dive into that, it may be worth checking if the oscillators

are stable and outputting what they are supposed to.

Will do!

I agree that the issue most likely lies somewhere between the MCA edge connector and the MIAMI interface chip (hopefully not inside the ASIC itself).

That's what my guts tell me, too. Unfortunately, there are almost no external components between the MIAMI and the MCA connector - all drivers and logic has home in MIAMI.
I disturbed the board's local data bus by shortening two data pins of the 245 bus transceiver, which resulted in a POST error 288 "Adapter initialization failed", so that's what failures in the *data* path seem to look like.
Then what's left is MIAMI's MCA signal handling and the raw connections to the card edge.

You could also test the adapter in another machine (even a PS/2) and
check if the behavior changes in any way.

I once checked in my -59H, and it didn't work. Don't remember the precise error pattern though. Will repeat that step.
The -42T was sold with the Ultimedia Adapter 7-5 sometimes, so they should be compatible in general.
I also tried a different slot in the same machine - no change.

Look at SSA adapters for a 34G1521, both PCI and MCA use MIAMIs.

...brilliant! Those SSA adapters are even cheaper and more useless today than anything with "Ultimedia" in its name.
Though swapping a 240-pin chip may be challenging.
I followed Eric Schlaepfer's recommendation https://youtu.be/wsLpe4lLhbo?t=1047 for "Chip Quik", a low temperature solder that helps remove SMD components. Smells toxic, but works pretty well...

You can see what appears to be uniformly spaced gouges from the right, seemingly touching the edge of A2.

What do you mean, precisely?
The picture isn't great at all. A1 and A2 are not shortened, and connect to MIAMI.

I wonder what the solder side looks like...

How could I miss that. Here's the B side: http://www.holzapfel.biz/UltimediaVideo7-5_2.jpg

The solder on Pin B61 is a remainder of my attempt to "repair" a "broken" trace - until I found out that signal SDR1 is cut intentionally as proposed by the MIAMI datasheet, errata of Pass 2, to fix an error in MIAMI's handling of the 160 MB streaming
mode.

I do have a Snark Barker card with the MCA debug pin header populated, so I *could* attach my 8-channel USB logic analyzer to the bus (probably together with the Ultimedia's dedicated CD_SETUP# signal) to capture some parts of the initialization, but
then again, what to do about it if something fails?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I once checked in my -59H, and it didn't work. Don't remember the precise error pattern though. Will repeat that step.

Same thing: No adapters recognized.
Since the -59H doesn't have in-ROM diagnostics and it can't IPL from the Corvette, the last chance of seeing anything would be booting diags from the CD-ROM on the internal SCSI port - but I've seen enough.

May try the P70 some time, but I bet the Ultimedia would disable the on-planar MCA DBA controller as well, leaving not more than booting from the RefDisk...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Christian Holzapfel schrieb am Freitag, 30. Dezember 2022 um 20:10:52 UTC+1:

I once checked in my -59H, and it didn't work. Don't remember the precise error pattern though. Will repeat that step.

Same thing: No adapters recognized.
Since the -59H doesn't have in-ROM diagnostics and it can't IPL from the Corvette, the last chance of seeing anything would be booting diags from the CD-ROM on the internal SCSI port - but I've seen enough.

May try the P70 some time, but I bet the Ultimedia would disable the on-planar MCA DBA controller as well, leaving not more than booting from the RefDisk...

Looks like many PALs/GALs are present. Please keep in mind, that all of these have a limited retention.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

If it is not essential, what else might be broken too?
What could be wrong here, technically?

I could probably use the UMS (Ultimedia Services) code examples to create some verbose test application. Maybe it shows more than just "initialization failed"... Will dig into the API.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Happy New Year everyone!

I finally progressed. After more probing of the MCA control lines I found U45, U48 and U49 (74F00, 74F245 and 74F10) dealing with the CD_CHRDY, /S0, /S1, /BURST, /CMD and /ADL signals.
The 74F245 had the most pins and complexity, so I swapped it first against another that I ripped off a dead Token RIng adapter.
And surprise: The system now boots from disk into AIX 4.3.3, identifies the adapter as "Ultimedia Video I/O Adapter sr0", assigns resources to the card and shows it in the diagnostics. Weeee!!

However, functional tests fail:
- UMS applications complain about "Video adapter not found" altough seen in the device list
- Device specific diagnostics fail reporting "Cannot run /usr/lpp/diagnostics/da/dsun". That file does not exist, and does not seem to come with the 8F96 driver package. It is not contained in the PCI Ultimedia Video Adapter device drivers either. Did
IBM miss packaging some files?
http://www.holzapfel.biz/8F96/8F96_DiagnosticsNotFound.jpg
- Viewing the Vital Product Data (VPD) in the Diagnostics reveals all empty fields, opposed to the DFE5 Ultimedia Audio Adapter:
http://www.holzapfel.biz/8F96/8F96_DisplayVPD.jpg
http://www.holzapfel.biz/8F96/DFE5_DisplayVPD.jpg
- Diagnostics allow me setting some VPD fields, however, opposed to the DFE5, all fields are read-write, which may not be intended:
http://www.holzapfel.biz/8F96/8F96_AlterVPD.jpg
http://www.holzapfel.biz/8F96/DFE5_AlterVPD.jpg
- On the good end, I committed some random data to the "USER" field, and it persisted through a power cycle as expected.

So if the initial VPD is missing, where on the board would it be stored? MIAMI's datasheet doesn't reveal much, so I would assume it to be part of the microcontroller U15. It needs to be a component with non-volatile memory, but I couldn't identify any
sort of discrete EEPROM, Flash or others.

Is the VPD data essential for the adapter's functionality?
How did it go lost?
Would setting the data to proper values help?
What are the proper values?
If it is not essential, what else might be broken too?
What could be wrong here, technically?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 02.01.2023 21:22, Christian Holzapfel wrote:

Happy New Year everyone!

I finally progressed. After more probing of the MCA control lines I found U45, U48 and U49 (74F00, 74F245 and 74F10) dealing with the CD_CHRDY, /S0, /S1, /BURST, /CMD and /ADL signals.
The 74F245 had the most pins and complexity, so I swapped it first against another that I ripped off a dead Token RIng adapter.
And surprise: The system now boots from disk into AIX 4.3.3, identifies the adapter as "Ultimedia Video I/O Adapter sr0", assigns resources to the card and shows it in the diagnostics. Weeee!!

However, functional tests fail:
- UMS applications complain about "Video adapter not found" altough seen in the device list
- Device specific diagnostics fail reporting "Cannot run /usr/lpp/diagnostics/da/dsun". That file does not exist, and does not seem to come with the 8F96 driver package. It is not contained in the PCI Ultimedia Video Adapter device drivers either. Did

IBM miss packaging some files?

http://www.holzapfel.biz/8F96/8F96_DiagnosticsNotFound.jpg
- Viewing the Vital Product Data (VPD) in the Diagnostics reveals all empty fields, opposed to the DFE5 Ultimedia Audio Adapter:
http://www.holzapfel.biz/8F96/8F96_DisplayVPD.jpg
http://www.holzapfel.biz/8F96/DFE5_DisplayVPD.jpg
- Diagnostics allow me setting some VPD fields, however, opposed to the DFE5, all fields are read-write, which may not be intended:
http://www.holzapfel.biz/8F96/8F96_AlterVPD.jpg
http://www.holzapfel.biz/8F96/DFE5_AlterVPD.jpg
- On the good end, I committed some random data to the "USER" field, and it persisted through a power cycle as expected.

So if the initial VPD is missing, where on the board would it be stored? MIAMI's datasheet doesn't reveal much, so I would assume it to be part of the microcontroller U15. It needs to be a component with non-volatile memory, but I couldn't identify any

sort of discrete EEPROM, Flash or others.

Is the VPD data essential for the adapter's functionality?
How did it go lost?
Would setting the data to proper values help?
What are the proper values?
If it is not essential, what else might be broken too?
What could be wrong here, technically?

Nice work, Christian!

I'm afraid I don't know enough about the AIX side of things to be of
much help.

Regarding the VPD storage - what kind of device is U10? Could be a PAL,
but I think an (E)EPROM is a more likely option. If it's the latter,
then that's probably your VPD store.

If it's not there, it's probably in the uC.

I'm more familiar with the PS/2 world, and IBM used both of these
methods there. The processor complex VPD is stored in the on-complex
flash memory, together with the POST/BIOS (when you do a flash update,
the BIOS has to copy the VPD block over to the new image, and only then
do the reprogramming). On the other hand, the planar and system VPD is
stored in a small on-planar EEPROM (together with some other data - like
the C2 security stuff).

The complex and planar VPD info isn't really "vital" in the case of the
late PS/2s. But I have no clue how pedantic AIX might be about this stuff.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

slavo...@gmail.com schrieb am Dienstag, 3. Januar 2023 um 16:06:59 UTC+1:

Nice work, Christian!

Thank you Tom.
It sure helps me finding causes if I take my time and write things down, explaining it to others.
With you folks pushing me over the edge, I finally achieved at least something...

The complex and planar VPD info isn't really "vital" in the case of the
late PS/2s. But I have no clue how pedantic AIX might be about this stuff.

Following Louis' path into the ODM database by
odmget -q "name = sr0" CuVPD"
reveals that all information I entered seems to be stored inside the ODM - at least.

The labeled ICs didn't reveal any NV memory:

U15 is not a microcontroller but a MACH435-15JC °High-Density EE CMOS Programmable Logic".
I'm not sure what this is capable of - only logic, or also hosting a soft core?

U10 is a N82LS135 "2K-bit TTL bipolar PROM°, but my cheap chinese USB prommer doesn't seem to support it - at least it is not in the list.

U6 is a PAL16R66-5JC.

I will have to probe more to see if the PROM may act as program memory for the U16 video processor, and if all connections between MIAMI and U15/U16 are fine.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Christian Holzapfel schrieb am Montag, 2. Januar 2023 um 21:22:08 UTC+1:

However, functional tests fail:
- UMS applications complain about "Video adapter not found" altough seen in the device list

No wonder: The AIX kernel did recognize the device on the bus, but the driver fails initializing it. So it is there, but being disabled.

When dumping the POS registers with my tool, it shows bits 6 and 7 of POS[5] being 0, indicating "a channel check excaption is active".
So it sounds to me like the card had found an error itself, and by reporting it through the POS registers, the driver refuses to load.

The MicroChannel Architecture HITR states:

"When bits 6 and 7 in POS Register 5 are set to 0, reading POS
Registers 6 and 7 will return the channel-check-status information.
This information can be status or a pointer to the status."

Using POS extended addressing (= writing an address to POS[6-7] to read alternative data in POS[3-4]) I learned that the card only supports subaddresses 0x0000 and 0x0001, and all further addressing halts the machine. Extended POS addressing is optional
and vendor defined. This is what I got:

Address POS3 POS4
POS6-POS7
0x0000 0xA5 0x01
0x0001 0x80 0x01

Without proper documentation on the vendor defined use of those fields, it looks pretty useless...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Christian Holzapfel schrieb am Donnerstag, 5. Januar 2023 um 19:30:38 UTC+1:

Without proper documentation on the vendor defined use of those fields, it looks pretty useless...

The MIAMI spec delivers.

There are precise descriptions of the POS registers. Meanings of each bit, and how to use extended addressing through a window to access the local bus.
Quite a lot to digest...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Christian Holzapfel schrieb am Donnerstag, 5. Januar 2023 um 19:19:15 UTC+1:

Following Louis' path into the ODM database by
odmget -q "name = sr0" CuVPD"
reveals that all information I entered seems to be stored inside the ODM - at least.

SA23-2643-00_RS6000_Hardware_Technical_Reference_General_Information_1990 claims that at least SOME data are required vor MCA adapters:

*PN L Part number
*EC L EC level
*FN L FRU number for field replacement unit
*SN L Serial number
*MF L Manufacturer and location.

So there maybe something wrong on the local bus of the board.
I wonder if the VPD is hosted in the PROM U10.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Christian Holzapfel schrieb am Donnerstag, 5. Januar 2023 um 19:30:38 UTC+1:

"When bits 6 and 7 in POS Register 5 are set to 0, reading POS
Registers 6 and 7 will return the channel-check-status information.
This information can be status or a pointer to the status."
[..]
Without proper documentation on the vendor defined use of those fields, it looks pretty useless...

The MIAMI spec delivers.

Obviously the card detected a "Channel Check" condition. "Channel" seems to refer to the Microchannel only, rathern than to a local bus error.

The MIAMI spec deciphers:

"With the -CHCK enable bit set in POS, -CHCK is asserted under the following conditions:

- An exception condition is detected on the Local Bus during a slave read from the Micro Channel. This function is only supported with the CD CHRDY Timeout Disable (Bit 12, PROC_CFG) set with Timeout enabled.
- Local Bus parity is detected during a slave read from the Micro Channel. This function is only supported with the CD CHRDY Timeout Disable (Bit 12, PROC_CFG) set with Timeout enabled.
- A data parity error is detected on the Micro Channel during a slave write from the Micro Channel.
- An address parity error is detected on the Micro Channel.
- Miami asserts CD CHRDY as a Micro Channel slave for longer than three microseconds.
- An invalid byte enable combination is detect on the Micro Channel during an access of Miami as a slave.
- An extra streaming data strobe is received after Miami indicates streaming termination as a slave."

So only MCA related errors pop up here. Great. MCA and MIAMI are properly documented, contrary to the PCB's local bus design.

When a -CHCK condition occurs, further status data can be read from POS6, which reads as 0x01 in my case:

"POS 6 (Status)
BIT 7-5: Reserved. These bits are set to zero when a channel check condition occurs.
BIT 4: Basic Cycle Data Parity Error. This bit, when set, indicates that a data parity error occurred on the Micro Channel during a basic transfer cycle to Miami
BIT 3: Streaming Cycle Data Parity Error. This bit, when set, indicates that a data parity error occurred on the Micro Channel during a streaming data cycle to Miami
BIT 2: Extra Streaming Data Strobe. This bit, when set, indicates that an extra streaming data strobe was active after Miami as a slave indicated streaming terminations.
BIT 1: Channel Ready Timeout. This bit, when set, indicates that Miami as a slave has negated Micro Channel channel ready for more than three microseconds.
BIT 0: Invalid Byte Enables. This bit, when set, indicates that an invalid combination of byte enables has occurred on the Micro Channel during a transfer to Miami as a slave. This error condition is checked for both basic transfer and streaming data
transfers."

Since BIT 0 is the only one set, *THIS* seems to be the specific bus error.

Sounds like SETUP transfers are running properly, but something is still wrong with the MCA's BE[3:0]# lines. Probing to the rescue!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

slavo...@gmail.com schrieb am Freitag, 30. Dezember 2022 um 00:41:26 UTC+1:

Before you dive into that, it may be worth checking if the oscillators
are stable and outputting what they are supposed to.

Just pulled out the 'scope, looking fine though.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I was having a good day, and swapped Miami. I've never replaced a 240-pin SMD component before, but that's kind of the secret goal of the project: discovering tools, getting hands on digital logic, leaving my comfort zone and becoming a better engineer.

Used a brutal, large heat gun to get the new Miami off the SSA adapter, carefully heating the zone bit by bit until it fell off, together with a lot of passive components. No serious pin bending there, and they all look pretty clean. Off to a good start.

Then I rubbed the Ultimedia's Miami pins with Chip Quik flux, and used an iron to attach a proper amount of Chip Quik low-temp solder to the pins. With an SMD hot air station I - more carefully this time - heated up the area until I could pick up Miami
from the board with a pair of tweezers.
Cleaned up the board with even more flux, solder braid and iron.
Then cleaned everything with isopropanol and cotton swabs.

Applied flux again, and dipped the new Miami into place. Carefully wiggled it until pins were sitting perfectly aligned to the pads. Used a cheap USB microscope to inspect.
Then I used a flat iron tip and leaded solder to fixate some of each side's pins to keep Miami in place. Then went around the chip, applying solder to all rows, following with braid to suck up the leftovers.
Inspection - cleaning - flux - solder - braid - inspection... you get it. Until no shorts were visible or measureable.

Going to the bottom side of the PCB, I measured all 0805 sized resistors, and found R202 went up from 4k7 to 6k73. Replaced it - fine.

Plugged in the card, held my breath, turned on the -42T and.... things remain unchanged -.-
No additional failure, but no improvement at all. Still no way of reading out local bus addresses through the MIOBUSGET ioctl, and no successful driver installation.

So Miami survived the transplantation, but it wasn't the problem's root cause either.

Now I will replace all off-the-shelf components piece by piece as I find them available for a fair price - can't get any worse than swapping Miami.
It's about the journey, right?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Christian Holzapfel wrote:

It's about the journey, right?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)