Intellivoice disabling Controllers?

[+Lathe26]

This seems weird but I have a particular Intellivoice module that seems to disable the controllers. Has anyone else seen this?

 

When you tap the disk or press buttons on either controller, nothing happens. Otherwise it appears to be working fine; at least it will speak at the title screen (ex: "Mattel Electronics presents... Bomb Squad"). I have a 2nd Intellivoice that used to do the same thing but it magically started allowing the controllers to work recently.

 

Here's what I've done:

• Attempted lots of jiggling/repositioning of the Intellivoice and the game (no luck)
• Cleaned the contacts (no luck)
• Tried it in other Intellivision consoles (no luck)
• Swapped different Intellivoice units, but those ones all fully work.

I do know that Mattel planned to have a wireless controller that plugged into the secret Intellivoice socket (underneath the Mattel Electronics plastic panel on the top of earlier production Intellivoice units). When the wireless adapter was plugged in, it would disable the normal controllers. However, it seems very unlikely that that is occurring here since this disabling required the Keyboard Component to work (details: wireless controller enables the RMHC pin that goes into the Keyboard Component, Keyboard Component disables the BDIR/BC1/BC2 signals when 0x01FE-0x01FF are read).

 

Thoughts?

[intvnut]

Actually, I don't believe RMHC works that way.

 

If you study the schematic for the Intellivoice, you'll see that RMHC gets asserted regardless of whether anything is connected to the riser. Given that's the case, if the Keyboard Component always hijacked $1FE/$1FF and forwarded them to the Intellivoice without letting the Master Component's internal PSG respond to those addresses, then you would only be able to use wireless controllers with a KC + Intellivoice combo.

 

That is, there's no presence detect in the Intellivoice for the wireless controllers. So, the operation of RMHC has to be the same whether the wireless controllers are present or not.

 

The role of RMHC is to reverse the direction of the KC's bidirectional bus transceivers when certain address ranges in the Intellivoice are selected. If there's no KC, there's no bus transceivers to reverse because the Intellivoice can directly assert to the MC. On a read to those address ranges ($1FE/$1FF included), the Intellivoice will respond to the read. This means that the Intellivoice actually gets in a buffer fight with the PSG, either directly (if connected to the MC) or indirectly (via the KC and RMHC).

 

My guess is that they're treating it like an open-collector bus, with a wire-AND behavior. It is an NMOS world back then after all.

 

I would check that none of the lines D0 - D7 on the riser (see schematic above) are shorted to anything, and that their pullups are still intact.

Edited December 7, 2014 by intvnut

[+Lathe26]

My understanding of the Keyboard Component circuitry is a little shaky (not a lot of them around anyways). Are there any schematics for the Keyboard Component (suspect not much available)? Also, anything unusual about the bidirectional bus transceivers or were they basically just 74xx245 parts?

 

I don't think I said this well in my previous post, but I was basically trying to discredit that the RMHC pin would be at fault. First, the RMHC pin attached to a grounded pin in the MC so the signal can't go anywhere when no KC is involved, which pretty much nukes the idea that RMHC would be causing the problem I'm seeing. A second reason that RMHC wouldn't be at fault is that, the built in Intellivoice circuitry automatically pulls the RMHC pin high on a ADAR and BAR for only MC address ranges of 0080-00FF and 0700-0BFF (skipping 07FF and 01FE-01FF). It does this without anything plugged into the stacking connector. For the RMHC pin to be asserted for other bus phases or other addresses (notably 01FE-01FF), whatever device is plugged into the stacking connector would have to assert the RMHC pin itself. Given the Intellivoice circuitry design, wireless controller would have the necessary circuitry that would assert its RMHC signal (mainly just needs to look for an AD2/AD1/AD0 of 101 for the correct bus phases).

 

From the Papa Intellivision docs, I recall reading that if the wireless controller was installed that the build-in controllers would be disabled when the KC was used. Thus, when the KC later died, so did the wireless controllers via the Intellivoice stacking connector. However, my memory on this might be incorrect.

 

All that historical stuff aside, your suggestion to check for shorts and check the pull-ups on the D0-D7 stacking connector side is a really great suggestion.

[+Lathe26]

As an aside about the KC, does the KC do any funny business with the BDIR/BC2/BC1 signals, especially when RMHC is asserted?

[intvnut]

My understanding of the Keyboard Component circuitry is a little shaky (not a lot of them around anyways). Are there any schematics for the Keyboard Component (suspect not much available)? Also, anything unusual about the bidirectional bus transceivers or were they basically just 74xx245 parts?

 

I don't think I said this well in my previous post, but I was basically trying to discredit that the RMHC pin would be at fault. First, the RMHC pin attached to a grounded pin in the MC so the signal can't go anywhere when no KC is involved, which pretty much nukes the idea that RMHC would be causing the problem I'm seeing. A second reason that RMHC wouldn't be at fault is that, the built in Intellivoice circuitry automatically pulls the RMHC pin high on a ADAR and BAR for only MC address ranges of 0080-00FF and 0700-0BFF (skipping 07FF and 01FE-01FF). It does this without anything plugged into the stacking connector. For the RMHC pin to be asserted for other bus phases or other addresses (notably 01FE-01FF), whatever device is plugged into the stacking connector would have to assert the RMHC pin itself. Given the Intellivoice circuitry design, wireless controller would have the necessary circuitry that would assert its RMHC signal (mainly just needs to look for an AD2/AD1/AD0 of 101 for the correct bus phases).

 

From the Papa Intellivision docs, I recall reading that if the wireless controller was installed that the build-in controllers would be disabled when the KC was used. Thus, when the KC later died, so did the wireless controllers via the Intellivoice stacking connector. However, my memory on this might be incorrect.

 

All that historical stuff aside, your suggestion to check for shorts and check the pull-ups on the D0-D7 stacking connector side is a really great suggestion.

 

You are correct that RHMC doesn't matter. That said, I think you got the logic backward. The way I read the docs, it would pull high for $1FE-$1FF only. Those are NAND gates, not NOR gates. The only valid address range that decodes AD0=1 && AD2=1 is $1FE-$1FF. ("All Others" decodes to AD0=1 && AD1=1 && AD2=1, but I imagine BC1/BC2/BDIR out of the SPB640 would be NACT in that case; why else would you buffer them through the SPB640? EDIT: BC1 and BDIR aren't buffered through the SPB640.)

 

I'm referencing this doc, page 17 of the PDF file: http://papaintellivision.com/pdfs/CCF10232011_00021.pdf

 

But RHMC is only needed to get the KC into the act, as you point out. I imagine the drivers in the KC must be open collector with pullups. Totem pole TTL would force $FF on the bus if the Intellivoice was plugged in to a KC with nothing on the riser.

Edited December 11, 2014 by intvnut

[intvnut]

As an aside about the KC, does the KC do any funny business with the BDIR/BC2/BC1 signals, especially when RMHC is asserted?

 

 

It does something with them, but I don't know what. I haven't traced out any of the circuits. All I know is that the Intellicart doesn't function on the KC in part due to sampling the bus control signals from the "rainbow" on the top-side of the PCB.

 

(Probably it doesn't bring signals out on the top-side, and does the "rainbow" reflection inside the KC, as the KC functions without a cartridge plugged in.)

[+Lathe26]

It does something with them, but I don't know what. I haven't traced out any of the circuits. All I know is that the Intellicart doesn't function on the KC in part due to sampling the bus control signals from the "rainbow" on the top-side of the PCB.

 

(Probably it doesn't bring signals out on the top-side, and does the "rainbow" reflection inside the KC, as the KC functions without a cartridge plugged in.)

 

That's some good info, thanks.

[+Lathe26]

 

You are correct that RHMC doesn't matter. That said, I think you got the logic backward. The way I read the docs, it would pull high for $1FE-$1FF only. Those are NAND gates, not NOR gates. The only valid address range that decodes AD0=1 && AD2=1 is $1FE-$1FF. ("All Others" decodes to AD0=1 && AD1=1 && AD2=1, but I imagine BC1/BC2/BDIR out of the SPB640 would be NACT in that case; why else would you buffer them through the SPB640? EDIT: BC1 and BDIR aren't buffered through the SPB640.)

 

I'm referencing this doc, page 17 of the PDF file: http://papaintellivision.com/pdfs/CCF10232011_00021.pdf

 

But RHMC is only needed to get the KC into the act, as you point out. I imagine the drivers in the KC must be open collector with pullups. Totem pole TTL would force $FF on the bus if the Intellivoice was plugged in to a KC with nothing on the riser.

 

I think I got the decoding correct in that RMHC is asserted for all stacking connector addresses except for $1FE-$1FF. However, please check my work below. The material referred is the same Intellivioce PDF and the Intellivoice circuit at http://atariage.com/forums/uploads/monthly_09_2010/post-14113-128399304199.jpg. As you point out, those are NAND gates and not NOR gates.

 

Here's the truth table that was worked out. My main concern is that I messed up Q1 (PNP transistor part PN2906). Note that 0 for RMHC really means "float" but I put 0 since the Master Component has this pin tied to ground. The formulas are:

TP2 = AD2 NAND AD0

TP3 = NOT BDIR

TP1 = BC1 NAND TP2 NAND TP3

RMHC = NOT TP1

AD2  AD0  BDIR BC1 | TP2  TP3  TP1 | RMHC
-------------------+---------------+-----
0    0    0    0   | 1    1    1   | 0
0    0    0    1   | 1    1    0   | 1
0    0    1    0   | 1    0    1   | 0
0    0    1    1   | 1    0    1   | 0
0    1    0    0   | 1    1    1   | 0
0    1    0    1   | 1    1    0   | 1
0    1    1    0   | 1    0    1   | 0
0    1    1    1   | 1    0    1   | 0
1    0    0    0   | 1    1    1   | 0
1    0    0    1   | 1    1    0   | 1
1    0    1    0   | 1    0    1   | 0
1    0    1    1   | 1    0    1   | 0
1    1    0    0   | 0    1    1   | 0
1    1    0    1   | 0    1    1   | 0
1    1    1    0   | 0    0    1   | 0
1    1    1    1   | 0    0    1   | 0

Thus, assuming I didn't make any mistakes, is that RMHC is only asserted for certain bus cycles when AD2/AD0 are 10, 01, or 00. From the PDF, this means MC address ranges of 0080-00FF and 0700-0BFF (skipping 07FF and 01FE-01FF).

[+Lathe26]

BTW, if I'm distracting you from LTO stuff, feel free to ignore my ramblings.

[intvnut]

 

I think I got the decoding correct in that RMHC is asserted for all stacking connector addresses except for $1FE-$1FF. However, please check my work below. The material referred is the same Intellivioce PDF and the Intellivoice circuit at http://atariage.com/forums/uploads/monthly_09_2010/post-14113-128399304199.jpg. As you point out, those are NAND gates and not NOR gates.

 

Here's the truth table that was worked out. My main concern is that I messed up Q1 (PNP transistor part PN2906). Note that 0 for RMHC really means "float" but I put 0 since the Master Component has this pin tied to ground. The formulas are:

TP2 = AD2 NAND AD0

TP3 = NOT BDIR

TP1 = BC1 NAND TP2 NAND TP3

RMHC = NOT TP1

AD2  AD0  BDIR BC1 | TP2  TP3  TP1 | RMHC
-------------------+---------------+-----
0    0    0    0   | 1    1    1   | 0
0    0    0    1   | 1    1    0   | 1
0    0    1    0   | 1    0    1   | 0
0    0    1    1   | 1    0    1   | 0
0    1    0    0   | 1    1    1   | 0
0    1    0    1   | 1    1    0   | 1
0    1    1    0   | 1    0    1   | 0
0    1    1    1   | 1    0    1   | 0
1    0    0    0   | 1    1    1   | 0
1    0    0    1   | 1    1    0   | 1
1    0    1    0   | 1    0    1   | 0
1    0    1    1   | 1    0    1   | 0
1    1    0    0   | 0    1    1   | 0
1    1    0    1   | 0    1    1   | 0
1    1    1    0   | 0    0    1   | 0
1    1    1    1   | 0    0    1   | 0

Thus, assuming I didn't make any mistakes, is that RMHC is only asserted for certain bus cycles when AD2/AD0 are 10, 01, or 00. From the PDF, this means MC address ranges of 0080-00FF and 0700-0BFF (skipping 07FF and 01FE-01FF).

 

 

I looked back at my notes (which consist of a hastily scribbled Post-It, actually), and I think you're right. That definitely flips my understanding of the circuit around. I still don't see why you exclude $7FF. I guess there's a typo on that page. (It says $0700-$07FE.) If you zoom forward to page 51, it says the address range is $0700 - $07FF. That seems much, much more likely.

 

The PNP transistor really messes with my head. I'm not an expert in M²L.

 

 

(M²L = Mickey Mouse Logic)

[+Lathe26]

I'd overlooked that 51 shows $7FF, which does make more sense. As for my M2L decoding, I'm pretty weak at it. I had to Wikipedia to make sure I didn't goof anything.

 

Looking more at the document, there are a number of mistakes in there. I think we can agree that the Intellivoice is not decoding an address of $001 (they likely meant $0081). :-)

[intvnut]

I'd overlooked that 51 shows $7FF, which does make more sense. As for my M2L decoding, I'm pretty weak at it. I had to Wikipedia to make sure I didn't goof anything.

 

Looking more at the document, there are a number of mistakes in there. I think we can agree that the Intellivoice is not decoding an address of $001 (they likely meant $0081). :-)

 

Yeah, the $001 is an obvious typo.