• Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.

Mac IIx NUBUS issues

Hey all. I'm hoping someone can help me. I acquired a Mac IIx, did the standard recap and repaired some traces, pretty standard work. However, the NUBUS is not working. The machine is otherwise healthy, boots to floppy and SCSI, responds to ADB, etc.

I checked traces and everything seems fine. When probing the NUBUS slots and the Nuchip, I get the proper clock signals, /RESET, VCCs, and grounds are properly connected. During startup, I see the standard activity of the NUBUS probing for cards using /START, /TM0, /TM1, /AD0, /AD1, and /ACK. But no subsequent communication. I suspect that the NUBUS probing fails to detect a card for some reason.

One theory I have is that the /START and /TM0 assertion is not properly detected by the card due to excessive voltage fluctuation/ringing. According to NUBUS specs, the LOW (asserted) signal should be below 0.8v, while HIGH (unasserted) should stay above 2.0v. But on my IIx, the ringing is causing fluctuations well outside that range. I don't have another IIx to compare it to, but on my IIfx, the signals look very different.

The first picture is the /START signal on the IIfx asserted by the NUBUS master. I have the trigger set to roughly 0.8v, and you can see that the LOW (asserted) voltage stays well below that.

IIfx_Start.png

And this is the IIx /START signal. As you can see, it rings well outside the spec, which is why I believe the probing fails.

IIx_Start.png

The signals from the Nuchip are clean, and they are also clean on the inputs and outputs of the G1 buffer. So this ringing has to be introduced somewhere between G1 output and the NUBUS slots. The only other component in series is the RP8 resistor pack. I replaced both G1 and RP8, with no change in behavior. I also checked nearby 0.1uf bypass caps, as well as grounds and other inputs/outputs on those ICs. I'm quite confused as to what could be causing this.

Not sure where to go from here. I could also be going down a completely wrong rabbit hole - perhaps Mac IIx NUBUS is more tolerant than the specs suggest?

Any help would be greatly appreciated.

P.S. Before anybody asks, I did try, and multiple known good PSUs and multiple know good video cards in different slots. The tests were all performed without any cards connected, and then with known good cards connected. The signaling did not change, and the cards never responded. The cards are getting a clock and voltages and they do get warm (I'm assuming they are just waiting for initialization).
 
Last edited:
I don't have any insights into that. However, I have two boards where NuBus was working and then failed. So, any diagnosis of NuBus failures is of great interest to me. I'm looking forward to other people's thoughts.
 
I wouldn't worry about the ringing.

If you see activity on /START leading to /ACK in a short time frame - the card replying - instead of the bus error timeout of tens of microseconds, then you know the card addressing works and the card is recognizing the access.

Next step from here is Slot manager probing for the DeclROM. It will expect to read some magic bytes to identify first the byte lane it should use and sanity check the ROM signature. Finally it'll go for a checksum of the ROM.

So next point of failure here is the nubus address/data buffers, assuming you see appropriate behavior on /ACK.
 
Thanks, you saved me from spending the weekend barking up the wrong tree.

Based on your advice, I probed for the interval between /START and /ACK. Without a video card, the delay was roughly 26 microseconds. With the card, the delay was only about 450 nanoseconds. So based on your info, that must mean the card is responding!

Additionally, without the card, the probing appears to be repeating roughly every 80 microseconds (retry?). With the card, I get 5 /START /ACK interactions in a row about 8 microseconds apart (with /ACK following almost immediately), then it goes back to probing every 80 microseconds.

I then probed the bus transceivers C/D/E/F/7/8. On all the Address and Data pins I see continuous barrage of healthy-looking activity. On the NUBUS side, I see the same pattern I mentioned above of 5 assertions close together, then 80 microseconds apart. The NUBUS data signals appear to go LOW for 200ns, which is a bit odd, but maybe that's normal. I also probed the few address lines going directly to Nuchip.

I have not checked the control pins on the bus transceivers yet, so that's next.
 
Last edited:
Yep, that sounds like the card is alive and enough of the address bus is working correctly (upper 8 bits). I'd look at the data lines first as the most likely issue next. Broken connection/rotten traces, and so on. Specifically AD31-AD24 is most often where the declrom rom lives and D31-D24 on the CPU side.

Keep in mind nubus signaling is inverted, so watch out for that.
 
Machine is fully functional now!

The culprit was a defective bus transceiver at C7. This was not obvious at all, and I'm actually surprised that I was able to track this down. All of the input/output pins, and control pins were sending/receiving signals, but the wave shapes on pins 13 and 14 were a bit odd and unlike any of the other signals on the rest of the bus transceivers. Since I didn't have another IIx to compare it to, I just swapped out C7 (not expecting an improvement), and the machine works perfectly now.

Not sure why C7 died, perhaps the cap goo from a nearby electrolytic, but honestly the corrosion on the pins was minimal so I doubt it. The machine had all 6 slots filled with cards when I received it, so perhaps C7 died from being worked too hard?

Anyway, I spent WAY too much time on this project, but the sense of accomplishment is that much greater.
 
Last edited:
Just another follow-up. It looks like C7 must have been introducing some parasitic components (current/inductance?) to Nuchip and/or surrounding ICs. After rescanning, many of the pins that were previously showing some (minor) fluctuations are solid now. Here's an example of the first /START signal after reset - it looks very different (compared to the bottom picture in the original post). Again, the only modification I made is I swapped out UC7.

1750114372626.png
 
Last edited:
Thanks for the updates! I have one that was working before which I think has the exact same issue. Where do you get the replacement parts?
 
Thanks for the updates! I have one that was working before which I think has the exact same issue. Where do you get the replacement parts?

I just searched my boxes of lose parts and I found a couple of those exact transceivers. You might find some used ones on eBay cheap, but it might be more cost effective to just buy a battery bombed board to steal them off of. There are probably multiple Macs that used that part.

With that said, I would hate to send you down the wrong path. IMHO the chances of your issue being caused by the same exact IC are very small. NUBUS on these machines is very complicated and these symptoms can be caused by any number of issues. 99% will probably be broken traces, but if yours suddenly stopped working, it could certainly be a bad IC.

I would still check the basics like voltages and continuity, and if you have a scope, I would check clocks and probe for any obvious signal issues. Following that, if you’re good at soldering, you could probably just try to score a cheap damaged board and swap out the nuchip, the 3 buffer ICs, and the 8 bus transceivers. That might be the fastest route to fix or rule out bad ICs. Just my opinion.
 
Last edited:
Machine is fully functional now!

The culprit was a defective bus transceiver at C7. This was not obvious at all, and I'm actually surprised that I was able to track this down. All of the input/output pins, and control pins were sending/receiving signals, but the wave shapes on pins 13 and 14 were a bit odd and unlike any of the other signals on the rest of the bus transceivers. Since I didn't have another IIx to compare it to, I just swapped out C7 (not expecting an improvement), and the machine works perfectly now.

Not sure why C7 died, perhaps the cap goo from a nearby electrolytic, but honestly the corrosion on the pins was minimal so I doubt it. The machine had all 6 slots filled with cards when I received it, so perhaps C7 died from being worked too hard?

Anyway, I spent WAY too much time on this project, but the sense of accomplishment is that much greater.
Nice find. What data lane does this correspond to?
 
Back
Top