• 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.

SE/30: Yet another scsi issue

jmacz

68020
Procured another SE/30 and have been testing the logic board with a working recapped analog board/PSU. Gave it a good bath, recapped it, fixed a couple traces to the ASC to resolve sound issues, and got it working, or so I thought.

I had been testing it with the logic board out of the chassis, tested it initially with an external ZuluSCSI without issues. Tested it with an internal ZuluSCSI and it was also working. Both booting into System 7.1.1 using the same SD card (moved the SD card between the ZuluSCSIs). I thought I was finished so put the logic board into the chassis and booted it up to adjust the screen geometry... but I got a flashing disk icon. Huh? Try with an external ZuluSCSI with the same SD card. Works fine. Try with the internal, nope.

Ruled Out
  • Internal ZuluSCSI is properly terminated.
  • External ZuluSCSI is also properly terminated.
  • Same SD card so rules out an OS issue, SD card issue, etc.
  • Tried a different ZuluSCSI internally, nope, same issue.
  • Tried external power on the internal ZuluSCSI, nope, same issue.
Continuity and Resistance Tests
  • All 25 ground pins look good on the internal 50 pin connector.
  • All 25 non-ground pins look good to the external SCSI connector as well as the onboard SCSI chip.
Other Tests
  • Power voltage for 5V (and 12V/-12V) look good.
  • Termination power is present.
  • No ground shorts or any of the non-ground pins shorted to ground.
Weirdness Begins

Pulled the logic board out and tested with the internal ZuluSCSI. Not working. But it was working before when I was working on it earlier. Swapped to a shorter SCSI cable (8 inches vs 16 inches). Worked! But not 100%... like 90% of the time. Use the longer cable. Nope, no good. Tested both SCSI cables in a IIci and the cables are fine, no issues.

While attempting to boot from the internal ZuluSCSI with the longer cable, I plugged in the external ZuluSCSI (with no SD card) and powered up. It booted! WTF? Unplug the external ZuluSCSI and try again, nope. Flashing disk icon. Plug the external ZuluSCSI back in, works. Huh? And note, both Zulus are properly terminated.

Then just to try things out, I removed the external ZuluSCSI and replaced it with an external Zip drive (with no Zip disk inserted). Works! Disabled the termination on the external Zip drive, still works. Powered off the external Zip drive but still plugged in, works. Unplug the Zip drive, nope, doesn't work. Plug it in, it works. Hmm.

Schematics

Looking at the schematics, the external scsi connector is directly connected to the same pins on the internal scsi connector. And then they go to the SCSI chip. There are no traces that aren't common between the two ports.

I saw some comments on the forum about the Bourne filters, but according to the schematics, no Bourne filter is connected to the SCSI subsystem. It's just for serial ports and the floppy drive and so I'm not sure what those comments were about. I saw a note about some of the external connector traces bypassing the internal connector but that doesn't seem to be the case according to the schematics as well as the Guide to the Macintosh Family Hardware book. And I beeped it out and no traces bypass.

Anyone have any ideas?
 
Earlier today, I had a Macintosh II that wouldn't boot from SCSI (Floppy EMU worked fine). I also toned out the SCSI connector like you did.

I've been working on a hunch with my pile of bad IIsi computers that often the SCSI problem is with VIA1 or VIA2, as they connect to the SCSI chip. In the case of the Mac II, I noticed some of those VIA pins didn't look as shiny as they should. Reflowed them. Sure enough, fixed the problem.

Inspect VIA1 and VIA2 and consider reflowing.

Alternatively, you have a cracked trace that is connecting/disconnecting as you handle the board to connect or disconnect the drive.
 
Inspect VIA1 and VIA2 and consider reflowing.

Will check.

Alternatively, you have a cracked trace that is connecting/disconnecting as you handle the board to connect or disconnect the drive.

Yeah, this is what I initially thought, and could still be the case. But after trying it over and over, it's pretty consistent. The external SCSI always works. The internal SCSI almost always fails with changing success rate based on length of cable. Doesn't seem likely but I could be wrong.
 
Unfortunately reflowing VIA1 and VIA2 didn't help and the connections look clean. I would think the internal SCSI would either work or not work. I don't see why it works if something is connected to the external port. In fact, I just tried with connecting a SCSI cable alone (nothing attached to it) into the external port and it works. I tried removing the external port to see if perhaps something's shorted unless you plug something in, but removing the port doesn't help the situation. Suggests something is out of spec and adding something to the external SCSI port allows it to work? My 5V line is at around 4.9V. The SCSI term power however is around 4.1V. I did notice that although SCSI is working, the chip itself doesn't seem to have any heat. My thermal camera shows the SCC next to the SCSI chip is much warmer along with a few other chips near it but the SCSI chip is no where near it in temperature.
 
I was able to go through each pin on the external DB25 SCSI port and using a length of wire, was able to narrow down which one is having issues. It's the /REQ. If I leave a disconnected wire attached to that pin, things work. It's not connector specific. Unfortunately can't watch the behavior because adding a probe from my scope makes everything work. Need to relook at the traces from the two SCSI ports to the SCSI chip, which means I'll have to remove the internal connector and the SCSI chip.
 
Removed the chip and the internal socket, both are pristine underneath. Examined under a microscope and looks good. Cleaned everything anyway, put the chip and socket back on, same problem. Compared against my other working one and I am not seeing any differences. Very close voltage on the 5v line, same on the term power, I see no differences. Hmm.
 
Nice troubleshooting!

@dv- I recall you had a IIsi with goofy SCSI--could it be something like this?
I ended up narrowing that down to a defective termination on the old HDD I was trying to use. Other devices work fine, as long as that drive wasn’t part of the system.

The information about the VIA1/2 chips is interesting though; I’ll definitely be filing that away if I have further issues. 😎
 
Actually, gonna skip the sockets, forgot how painful it is to add them. I think I have a compatible scsi chip on a IIci parts board here somewhere.

Still can’t understand why an external device works, but the internal port is having this issue. I mean the pins are all direct connected so I don’t get it.
 
Still can’t understand why an external device works, but the internal port is having this issue. I mean the pins are all direct connected so I don’t get it.

Maybe your SCSI chip trips a little too easily? The cable (or length or wire) provides just enough inductance/capacitance to absorb a slight voltage dip?

BTW: /REQ has been a source of trouble for Apple before. (And, you made the first comment on my write-up in this thread)

 
Maybe your SCSI chip trips a little too easily? The cable (or length or wire) provides just enough inductance/capacitance to absorb a slight voltage dip?

I was considering the fact that a cable might act like either a small capacitor or possibly a drain and the issue is with either pulling up or down, but the part that was throwing me off is:
  • With just an external Zulu (it's a Zulu mini so the PCB is directly attached to the external SCSI port - no ribbons/cables) it works fine. <- I should probably test what happens if I run this Zulu mini via a longer DB25 cable.
  • The internal ZuluSCSI I am trying to use I have attached via an 18" 3 connector SCSI cable, a 12" 2 connector SCSI cable, and a shorter one, I think it's a 6" one. Issues with all of them, although the shortest one seems to work every so often.
  • Attaching a disconnected wire or cable or even a probe from a scope on the REQ makes things work.
  • I was thinking that the 6/12/18" ribbon should be similar but I guess I need one not driving a signal.
I was going to try adding a small capacitor to see if that helps or try a 10K resistor pull up to 5V / pull down to GND to see if that does anything.

BTW: /REQ has been a source of trouble for Apple before. (And, you made the first comment on my write-up in this thread)

I remember the thread, but totally forgot about the mention about the REQ. Thanks!
 
So more observations, beginning with the fact that I got it to not boot on the external by itself as well. I attached the external Zulu mini with a 18" SCSI cable and although it still works most of the time, I got it to fail boot twice (whereas I could never reproduce on the external when the Zulu mini was directly connected to the board). Note that issue occurs both with and without external power provided to the Zulu devices so it's not a term power not being enough type issue. But this makes me feel a bit better because now it's not some strangeness between internal/external, it's just that whatever weird out of spec issue is occurring doesn't happen as often with the external device.

Played around with adding a capacitor, trying a pull up / pull down, none of those things changed anything.

Next step is to swap the SCSI chip with one I have in a IIci logic board (I believe it's the same one, and I don't want to mess with my other SE/30).
 
Played around with adding a capacitor, trying a pull up / pull down, none of those things changed anything.

That surprises me. Did you mimic the IIfx terminator by adding a 470 ohm pullup to req (so the total pullup is 150 ohm) along with a 2.2 uF tantalum and 0.01 uF ceramic capacitor to term power?

I don't think those are magical values -- but I do think they put some thought into it.

The fact that we have introduced faster and faster SCSI devices suggests that we might be pushing the tolerance on some SCSI chips.
 
The capacitor/resistor playing around I did was not to mimic the IIfx termination in your other thread. This was just trying various things to see if I could get more deterministic behavior.

For the thread you showed me, I actually have one of those internal IIfx SCSI terminators (both the block and the filter) - same one you took apart in a different thread which provides the caps/resistors. I used the filter portion on my internal ZuluSCSI (with its own termination still enabled) and tried it after you reminded me about that thread, and that didn't change the behavior unfortunately.

Using that IIfx internal SCSI filter should be the same as adding those caps and the 470 ohm resistor? I think dougg3 mentioned the ZuluSCSIs have the ground pins wired so I would think this should be a valid test of whether it's the REQ issue you mentioned?
 
@David Cook you win! :)

I was just re-reading your other thread here on active vs passive SCSI Terminators and it looks like although you found that the SCSI filter portion on the IIfx internal terminator has the two capactors, it looks like it does not have the 470 ohm resistor?


So instead of using the IIfx internal terminator, I added the 470 ohm resistor across /REQ and term power, and then added two capacitors (both are tantalum - I don't have any ceramics on me - does that matter?) .. a 2.2uF and a 0.1uF in parallel from term power to ground. And of course termination still enabled on the ZuluSCSI.

With those changes, it works! Nice!

So what does this mean? Is there something wrong with my SCSI chip (given my other SE/30 doesn't have an issue)? or are there SCSI chips out there that can handle the current crop of modern SCSI emulators while some cannot (without the active termination)? If so, does this mean it might be possible to tweak something in the ZuluSCSI configs (or add a new feature) that can change timings to get this to work on all SCSI chips? Hmm....
 
Yeah, so it's consistently working now. But now I really want to understand what's different about this SE/30 whereas my first SE/30 works fine. Is there some damage somewhere I'm overlooking (connectivity and resistance all look good across all the SCSI traces to/from the connectors to the SCSI chip)? Or is something generating noise that's being picked up on REQ? I can't observe the signals with my scope when it's not working since attaching my probe makes it work.. but perhaps I can look at the signals when it is working and see if there's anything out of the norm.

Now if I have to make these modifications permanent, it would be simple for an external drive as I can just add an active terminator. I could neatly place the resistor and two capacitors on the board (use F3 as the term power location and the REQ line off pin 34 on the SCSI chip). Or I guess I could make a custom mini PCB with a male and female 50 pin IDC connector with the resistor/capacitors as an internal IIfx-style termination helper? Maybe that would be cleaner?

But again, still curious whether this is the right fix or I need to fix the real underlying issue somewhere on this board.
 
It might be worth a read of the DV15 technical note (attached) to explain why they needed a special terminator.

>> ....a new SCSI chip that provides SCSI data transfer rates up to 3 megabytes per second...
>> The reason for the new terminator is that on the Macintosh IIfx and future hardware, the SCSI
>> controller chip is a 2 micron part, which makes it very fast. One of the results of this speed is
>> that the chip now thinks that glitches in the /REQ line are real signals.

and

>> Basically, if a majority of the data lines change state at once, there is a sudden drain on the
>> TPWR line, which is resistively coupled to all of the lines, including the /REQ line. This
>> sudden drain causes a spike in the line, and this spike is propagated into the /REQ line and to
>> the SCSI controller chip. The newer SCSI controller chip in the Macintosh IIfx interprets this
>> spike as a /REQ signal and starts reading data from the data lines; however, since the data
>> lines need 55 ns to settle, the data that the controller chip reads is junk.

>> Since the problem is caused by a drop in the TPWR line, the fix is to smooth out the line. One
>> need only add a 2.2 μF capacitor and a 0.01 μF ceramic capacitor as illustrated in Figure 2.
>> These capacitors act like a battery and provide a little extra current when it is needed. This
>> extra current results in a smoother signal, which the SCSI controller chip does not interpret as
>> a /REQ sign

Other interesting notes:
>> This problem is not likely to occur on all of the Macintosh IIfx machines

>> If your hard drive implements the new capacitors, you can, and should, install the capacitor filter—you cannot have too much
capacitance

>>The Macintosh Quadra computers require external SCSI termination at the end of the device chain
>> ... Note that this is the standard SCSI terminator, not the black terminator required by the Macintosh IIfx (although
>> the black IIfx terminator may be used as well).

So maybe:
* Term power diode is getting a little tired? I've doubled up the diode on a IIsi to reduce the voltage drop
* "My 5V line is at around 4.9V." Recapped Sony CR-44? I don't recall a trimmer on that to nudge it up slightly. Do you have any PDS cards that might be dragging down the voltage.
* Your SCSI chip is just a little sensitive

Permanently installing capacitors is not going to cause any harm. Maybe, maybe the pullup resistor might cause incompatibility with a drive that can't sink much current.
 

Attachments

Back
Top