Asante MC3NB Rev G Nubus NIC - getting 10Base-T working

[speakers]

I’ve used a couple of the Rev G version of these NICs in Mac IIcx and IIci, and I’ve always have trouble with RJ-45 10Base-T. Operating through an external AUI transceiver is fine but direct RJ-45 connection mostly fails.

People have reported these NICs don’t sync with modern 100/1000 switches. I connect via a 10/100 switch and still have problems. The only way that I can get a connection is to boot/reset with Link Integrity enabled (jumper JP-2 open) and then disable this immediately after boot. Then the line syncs - although the switch reports a half-duplex connection. Obviously, diddling this jumper like this is not practicable. I see the same with MacOS, NetBSD and Linux — i.e. it’s not a driver issue.

But .. I also have a Rev B1 board which has only AUI and RJ-45. This is flawless using RJ-45 over regular cabling and the same networking switches etc. This card is a similar to Rev G and it uses the same NatSemi DP83902 network controller chip. What?

Does anyone know what’s going on with this NIC? Is there any way to fix/modify/bodge the Rev G board to work like its Rev B1 sibling?

 

[luminescentsimian]

A guess would be that it's auto-detecting the coax connection. You'll just have to rewire everything to thin net
It's not clear how the auto-detection logic works, and there aren't any suspicious aluminum electrolytic capacitors in sight. Maybe one of those ceramic disc or tantalum caps failed-short and that somehow translates to "there's a signal on the coax". Maybe you can poke at pin 72 on the controller, I suspect it's connected to JP1, and see if it's properly at 0V or if it's floating towards a high (force-AUI) signal.

 

[speakers]

Deciding not to rewire with thin net, I took your suggestion and took a look at pin 72, the AUI/TPI SELECT line, on both the rev B1 and rev G boards.

On the G1 board, pin 72 is tied firmly to 0V vis a 0Ω resistor - hence twisted-pair goodness albeit only half-duplex.

Whereas on the troublesome G board, pin 72 is driven from a gate whose inputs are funky and I think determined by JP2 (link integrity enable/disable) and two other sources -- one may be a bit in a register set by firmware or Nubus interface, and the other is derived from the mysterious link integrity logic which toggles hi/lo to flash an LED. The result is the state of pin72 being somewhat uncertain.

But it may be possible to hack the rev G board by disconnecting the dubious gate driving pin 72 and tying it to 0V. I'll try and report back.

 

[speakers]

One simple way to get RJ45 to work on the Rev G board is to:

• remove R45, a 0Ω resistor
• tie the end of R45 closest to the NIC controller (with trace to pin 72) to pin 7 of U20 which is the OV rail

See annotated photo:

 

[speakers]

A footnote to the above change is that AUI with outboard transceiver no longer works. But who would care?

 

[Glenn Anderson]

There is probably a way to modify the Rev G so that the jumper JP1 can still switch between AUI and TPI.

With the Rev B1, do you know if it auto switches between AUI and TPI, or does that have to use the jumper JP1?

The problem with cards like these not working with anything but old ethernet switches is a messy interaction between a custom link pulse detection circuit used to auto-switch the TP hardware on the DP83902, while the ethernet switch is trying to do auto MDI-X. The custom link pulse detection circuit is built from a 26LS32 and 74LS123 (U18 and U19), which are absent on the Rev B1, so I'm guessing it doesn't auto switch media?

 

[speakers]

There is probably a way to modify the Rev G so that the jumper JP1 can still switch between AUI and TPI.

Ideally, you'd hope.

With the Rev B1, do you know if it auto switches between AUI and TPI, or does that have to use the jumper JP1?

I've not been able to get an outboard transreceiver to work with the B1 via AUI regardless of JP1's setting.

The problem with cards like these not working with anything but old ethernet switches is a messy interaction between a custom link pulse detection circuit used to auto-switch the TP hardware on the DP83902, while the ethernet switch is trying to do auto MDI-X. The custom link pulse detection circuit is built from a 26LS32 and 74LS123 (U18 and U19), which are absent on the Rev B1, so I'm guessing it doesn't auto switch media?

I've not been able to dig up schematics for these things. Since I'm only interested in TP, my hack is sufficient .. so I've not bothered to reverse engineer the Rev G board

 

[Glenn Anderson]

I have a Rev G I also want to modify. Your hack is good, it is the most direct way to force TP only. One refinement I think makes sense, is to actually install JP1. The way JP1 appears to work is to disable the coax circuitry when it is installed. With JP1 off it is dynamically disabled by the TP link detection circuit.

I'm still trying to understand how the switching on the Rev B board works, as I might try and mod my Rev G so that it can still switch between TP and AUI.

 

[Glenn Anderson]

Another solution, the problematic link detection circuit can be made to work by changing R28 from 36K to 220K. This increases the time allowed between detected link pulses to be long enough to allow for Auto MDI-X. I've tested this on a Rev B2 and a Rev G card, with a TP-Link TL-SG1016DE ethernet switch.

R28 is in the same physical location on all the boards I have, by pin 3 of U19 (74LS123), which is also to the left of the unpopulated D3 on Rev B1/B2/C1 boards, or to the left of the unpopulated R43 on Rev G.

For cards with TP, AUI, and Coax, I also recommend installing jumper JP1, as that will power down the coax circuitry. On the cards with all 3 connectors, TP still takes priority over AUI when JP1 is installed.

 

[speakers]

Another solution, the problematic link detection circuit can be made to work by changing R28 from 36K to 220K.

That looks like a much more elegant solution than mine. I’ll try it on my Rev G board to confirm it works with my network.

 

[speakers]

I can report that my Rev G board, with my hack reverted, and with R28 changed, does indeed work with TP or with external MAU via AUI. In fact, I used a value of 270k because I didn't have a 220k at hand, but evidently the resulting longer delay is fine.

Many thanks Glenn.

 

[Glenn Anderson]

Here are schematics I've made of the media sections of the Rev B2 and Rev G

To do a full conversion of a Rev G to remove coax and the problematic TP link detection circuit, it looks like the AUI/TPI pin of the DP83902 can be connected to the AUI detection circuit by removing the link at R45, and adding links at R43 and R34. The 1M R33 would have to be moved to R35. A bunch of other components would also have to be removed, I think at a minimum U17, U19, C11, and R22. Much more involved than replacing a single resistor, but I might give it a go at some point.

 

[Mk.558]

Hey @Glenn Anderson you wouldn't happen to know if the MacCon SE / SE30 cards are compatible with such a modification like the 220K ohm resistor change above?

 

[Glenn Anderson]

Hey @Glenn Anderson you wouldn't happen to know if the MacCon SE / SE30 cards are compatible with such a modification like the 220K ohm resistor change above?

The ones I have don't have this issue, so it isn't applicable to them. I have a MacCon for SE Rev C, and a MacCon for IIsi SE30 Rev C2. I haven't had any issues with these cards and modern ethernet switches.

Cards that have this compatibility problem have a DP83902, and automatic media selection, using a 26LS32 and 74LS123 to detect link pulses. Changing the resistor is changing the time constant for the 74LS123.

The MacCon for SE Rev C that I have uses a DP8390, with an AT&T T7220 transceiver IC on the connector board. The MacCon for IIsi SE30 I have uses a DP83901, with an LXT902 transceiver IC on the connector board. The MacCon for SE has a switch for manual media selection.

The switch on the MacCon for SE has 3 positions, TPL, TPN, and TK. For 10base-T it needs to be on the TPL position, the TPN position turns off link pulses. TK is an abbreviation for Thick, which selects the AUI connector. The MacCon for IIsi SE30 has JP8 labeled LINK TEST DISABLE, that jumper needs to be off.

I you are having trouble getting this style of card to work, try an AUI transceiver. If you can't get an AUI transceiver to work, then the problem is probably with either the main card, or the ribbon cable and it's connectors. Although if the AUI transceiver doesn't power up at all, do check the fuse on the connector board.

Here are pictures of the cards I have. If you have different version cards, feel free to post pictures and I'll be happy to take a look at them.

 

[Mk.558]

Wow what a post, I have to admit that with folks like you around this world can keep spinning!

Here's my cards. First up is one I got with the machine, which caused me a small amount of head issues owing to the fact that I didn't have an AUI adapter for it. Fun fact: Those cable-less AUI adapters won't work on these or the Mac II series ones because the body of the unit is larger than the space in the case, so you ... need to either buy a AUI drop cable or similar DB15 non-VGA cable. Revision C2.



This recent one I forked over 150 bones for. Rev. C1.



Back of both cards.



I found out that a common issue with these cards is the 20MHz oscillator on board likes to die. We won't talk about that day when I swapped out both of them and somehow cooked a trace on one of those boards. Anyways with both oscillators swapped they would work over AUI. But that's because I have a Farallon Etherwave AUI - 10BASE-T adapter. On the one with 10BASE-T, plugging in an Ethernet cable to anything modern causes it to simply blink green and no actions are possible.

Upon investigation yeah it was the auto negotiation MDI/MDI-X that's causing it. None of my routers can be forced to 10BASE-T full duplex. Mac OS X can, and Linux can too with the $ ethtools package, but that will only work for direct computer network which is OK but a router connection is better. So I'm wondering what I could do with my daughter card there to help it not be useless on a modern network without getting some kind of 10BASE-T hub that is old and won't work to bridge WiFi anyways because most people use 802.11n or ac these days not 802.11b or something.

While I have you on the sound power, you know anything about this thing? I used it many moons ago on the CMN Guide for general Ethernet things and also to peg a 10/100 card at the max using a Rocket under System 6. (Short story: 866KiB/sec down, 605KiB/sec up using a RAM disk on the Rocket itself.) Right now the Asante software installer can't even recognize the card.

 

[Glenn Anderson]

I found out that a common issue with these cards is the 20MHz oscillator on board likes to die. We won't talk about that day when I swapped out both of them and somehow cooked a trace on one of those boards. Anyways with both oscillators swapped they would work over AUI. But that's because I have a Farallon Etherwave AUI - 10BASE-T adapter. On the one with 10BASE-T, plugging in an Ethernet cable to anything modern causes it to simply blink green and no actions are possible.

Did you just replace the 20MHz oscillator on the main card, or did you also replace the one on the connector board? Between the connector and the AT&T T7220 chip.

Upon investigation yeah it was the auto negotiation MDI/MDI-X that's causing it.

Pretty much anything that stops the transmit path from working, while the receive path is still working, can result in a blinking LED when connected to a switch with auto MDI/MDI-X. The switch doesn't stop alternating between the two connection pairs until it detects link pulses from the other end. Definitely check for bent pins or corrosion in the socket. Zooming in on your picture, the pins look like they might be a bit squashed down and uneven:

If the socket doesn't seem to be the problem, check the 20F001. It is an isolation transformer, should read about 1 to 3Ω between pins 1 to 3, 6 to 8, 9 to 11, and 14 to 16. If any of those high resistance or open circuit, swap it out. There are newer revision 20F001N and 20F001NG parts available on eBay for reasonable prices.

I would have thought the 20MHz oscillator on the connector board failing would impact both the transmit and receive sides, but maybe the receive side could still be working well enough to detect link pulses, but the outgoing ones are too slow or infrequent?

None of my routers can be forced to 10BASE-T full duplex. Mac OS X can, and Linux can too with the $ ethtools package, but that will only work for direct computer network which is OK but a router connection is better. So I'm wondering what I could do with my daughter card there to help it not be useless on a modern network without getting some kind of 10BASE-T hub that is old and won't work to bridge WiFi anyways because most people use 802.11n or ac these days not 802.11b or something.

You would want 10base-T half duplex, these older cards don't support full duplex. Have you been able to test it with any non auto-MDI/MDI-X device? I suspect it has a fault that won't work with those either. The LED might light solid on this card, but the other end would never see a link up.

While I have you on the sound power, you know anything about this thing? I used it many moons ago on the CMN Guide for general Ethernet things and also to peg a 10/100 card at the max using a Rocket under System 6. (Short story: 866KiB/sec down, 605KiB/sec up using a RAM disk on the Rocket itself.) Right now the Asante software installer can't even recognize the card.

View attachment 14074

I've never seen one of those cards in person, they are rare. Does anything detect its presence? If the NuBus interface on the card and the ROM are working, it should show up in the Network/MacTCP/AppleTalk/TCP/IP control panels as an option, it will just fail promptly if you select it and the drivers are not installed.

However looking closely at your picture, it looks like the ROM might not be seated well in its socket?

 

[Mk.558]

Thank you for the response.

1.) I just replaced the 20MHz oscillator on the main board. I considered the one on the daughtercard but the order was already in place from Mouser along with a bunch of caps for the FDDs and two EtherWave Mac/PB adapters.

2.) It is true the pins are uneven. I'm not sure if I can bend those back without A) removing the socket (not doing that) B) using a dental pick to mess with them. See #4.

3.) I got 1.4, 1.3, 1.similar and 1.6 ohms on those 4 pin pairs. It picks up the ohmage slowly so I assume there's a capacitor involved in there, if it's like a Bourns network filter (i.e. RP2 on a SE/30 board).

4.) Mac OS X and Linux can set the port speed manually: OS X does it through the System Preferences and Linux does it with $ ethtool. If I set the link speed on my mac mini G4 to 10BASE-T full duplex OR half duplex the light stays good and everything is fine. Same deal with the Asante 10BASE-T card. Can FTP out and EtherTalk works. The 10/100 doesn't do anything. On my routers, they don't work properly at all, and I'm debating that topic with some other dudes on the DD-WRT forums.

5.) I don't have a DIP chip puller :X I'm gonna try some thin wire or gentle rockin' to get try to reseat those.

 

[Mk.558]

Update:

Readjusted the pins on the MacCon 30i and the card works perfectly fine with my router. Neat, good eye to notice the pins. I suspected I must have a problem with my daughter card of that sort since I checked all the resistors, the fuse, looked for swiped traces, and nothing, so I believed you had to be right and you were.

I went to swap R28 on the Asante Nubus card and I don't have resistors in stock for ranges between 82K ohms and 1M ohm. Whoops. I do have a loose 1/2W 470K ohm resistor though -- naaah it won't fit it's too big

The 10/100 NuBUS card I took another close look at. Reseated the ROM. Using a loupe, I saw no knackered pins on the main chip U15 or U16. There looked like a scratched trace from Pin 1 and possibly Pin 2 of U14 leading to U16 but a ohm test said it was OK.

Dunno. The green signal lights light up with 10 or 100Mbit connections respectively, but does nothing else. Huh.

 

[Glenn Anderson]

View attachment 14079



Dunno. The green signal lights light up with 10 or 100Mbit connections respectively, but does nothing else. Huh.

I think you might have the wrong Asante installer. I just got one of these cards, and it needs the AsanteFAST 10/100 installer, and the AsanteFAST 10/100 installer didn't need the card to be present to install the driver. Try this one https://www.macintoshrepository.org/23359-asantefast-10-100-nubus

 

[Mk.558]

@Glenn Anderson I already offloaded the card, sorry for the late reply. It's fine because you can't really get the full performance on a 68030 box anyways, although I guess I could have tried on a 68040, but I didn't have both at the same time. Also I prefer using cards that can be detected readily by System 7's NIC installation process built in, or at least the normal NSI software (so no Dayna or other weird cards).

I got a box of Ethernet cards recently, some more interesting than others (not all shown here), but I thought you might find this at least mildly interesting. Bottom right is the Asante card with the swapped resistor that I've been using for awhile in the IIci. The others have been dormant for a...whle.