Macintosh SE/30 logicboard recreation (thread revival)

[croissantking]

OK, I've found something interesting. The ASC generates the C16M clock signal that drives the PAL we have been investigating at UE7. And, on my boards, this same ASC has the Y3 oscillator and two incorrect capacitors fitted to its circuit.

Swapped out these 2 caps for correct ones but that wasn’t it, still artifacting.

 

[croissantking]

Turning my attention to the diodes on the RAM circuit for a moment, do these look like the right parts - how would I check?

According to the BOM it’s supposed to be a BAS40-06-7-F.

 

[croissantking]

I found another interesting thing, which may or may not be important but I had some of the pick and place capacitors off for testing last night and the parts which should be 33pF are 10pF parts. Is this a reasonable substitution?

I know why my 33pF parts were wrongly picked now.

There is an error on the BOM on GitHub –



The 33pF parts have the wrong LCSC Part # listed. It is C1883, but it should be C1906.

Thanks to @ThisDoesNotCompute , I read your group buy thread over on TinkerDifferent, and I noticed that you flagged this up in your own BOM.

I imagine boards which were ordered with pick and place may have the wrong value caps at the five locations it applies to.

 

[croissantking]

I hope this last post doesn't come across as critical, the Reloaded project was a huge undertaking done for the benefit of the community, and I'm always appreciative. This is just a minor and probably unimportant error but I thought it would be good to flag it up.

 

[croissantking]

So tonight I’ve been looking at my original SE/30 boards and found that pin 6 of the PAL at UE7 doesn’t go to /Nubus. It has continuity with pin 89 on the PDS connector, which is labelled /LAS.

I’m really confused.

 

[croissantking]

I’ve cracked the puzzle surely. Can I have the revision 4 named after me?

 

[croissantking]

Ok. I think I see what’s going on. You know the bodge wire that the early revision boards have - well, the Apple photocopied schematics on the internet are from before Apple found and applied this. And if the Reloaded board was based off those schematics, then that would account for the error.

 

[dougg3]

And if the Reloaded board was based off those schematics, then that would account for the error.

Very nice sleuthing! I just looked at the Reloaded gerber files and you're right. They match the leaked Apple schematics with UE7 pin 6 going to U18 pin 33 and PDS pin 82.

Bomarc's reverse engineered schematics match what you observed on your original boards with UE7 pin 6 going to PDS pin 89 (C9):

 

[robin-fo]

So cool @croissantking! Well done! Though I wonder how such a mistake could cause such an issue, but let‘s see what happens when we apply the bodge wire on our boards as well!

 

[Bolle]

Lol, no way. I thought I had checked this. I guess /Nubus might switch a little earlier than /AS and that would result in addresses getting latched into the VRAM before setup times are met.
Let me know if connecting that pin to /AS will work for you.

 

[bigmessowires]

Woah, great job hunting down that detail! If that's the issue, then I don't understand how the PCB could work at all with the wrong connections on those signals. I will await the full report and I hope that this video glitching mystery is solved. Very interesting stuff.

 

[ThisDoesNotCompute]

well crap

 

[croissantking]

Let me know if connecting that pin to /AS will work for you.

It certainly looks like. I should run the boards for longer before claiming victory, of course, but one of them that used to show the issues after 6-8 minutes on a cold boot every single time has been running for over two hours with no signs of any artifacting. I keep stuff on screen that moves the pixels around and monitor it, and I'll interact with the machine a bit too. If there was still a problem I would likely have seen it by now.

Purely as an experiment, and for my own entertainment, I took one of my original SE/30 boards with the factory bodge wire and reversed it so that it would run like a Reloaded board, with UE7 connected to /Nubus. I ran it for an hour and could not see any artifacting. This is not really surprising since only like 1-2% (I guess??) of the Reloaded builds actually exhibit any issues and the same could be true for the original boards too. My conjecture is that it probably took Apple a while to find and fix the problem since it was only very occasionally showing up and by that time the boards had already gone to mass production. So the SE/30 engineers were probably very well aware of the problem and we've kind of gone through Apple's forgotten troubleshooting process again, almost 35 years later.

I guess /Nubus might switch a little earlier than /AS and that would result in addresses getting latched into the VRAM before setup times are met.

Two questions for you, @Bolle,
/AS stands for address strobe, correct?
What's the difference between /Nubus and /AS - and why do both options (almost) work?

What continues to strike me as odd is why the issue only shows up on a tiny minority of boards, why it comes and goes as the board warms up, and why swapping parts or touching certain pins changes the severity/pattern of the issue so much. Perhaps all this is normal for a circuit that's operating at the very edge of its spec, but I'm not experienced enough to say.

This has been an adventure and I've learned so much through the process. I started troubleshooting the issue in January and now we are in December so it's been a full year, which adds to a satisfying narrative. Seeing @bromaster post about their identical issue last week gave me a boost in motivation as I started to see it was not really an issue specific to me; and in the last few days I felt as though I was getting very close to a solution. And that solution was really staring me in the face the whole time, it just took perserverance – and lots of it. When I was looking at my Apple SE/30 board last night and seeing things wired differently, I was in a state of disbelief and confusion initially. Then I started looking at it more closely and the pieces came together.

 

[dougg3]

Here's what Designing Cards and Drivers for the Macintosh Family (3rd Edition) says about /NUBUS:



Sounds like it's basically a copy of /AS that is slightly delayed and only activates in the $60000000 to $FFFFFFFF range? Since onboard video is inside that range, they are basically the exact same signals for UE7's purposes except /NUBUS is 20-ish nanoseconds delayed...

Congrats on finding this! It must feel so satisfying after almost a year!

 

[bigmessowires]

...and those 20-ish nanoseconds of delay could be very important, if they're the difference between meeting the setup time requirements for data written to video memory, and not meeting those requirements. Touching /NUBUS with a probe would add extra capacitance like I was babbling about previously, which would cause the edge of /NUBUS to arrive at the RAM slightly later, which would give enough extra setup time for the data to be received and written correctly.

 

[croissantking]

...and those 20-ish nanoseconds of delay could be very important, if they're the difference between meeting the setup time requirements for data written to video memory, and not meeting those requirements. Touching /NUBUS with a probe would add extra capacitance like I was babbling about previously, which would cause the edge of /NUBUS to arrive at the RAM slightly later, which would give enough extra setup time for the data to be received and written correctly.

This explanation would make sense if /Nubus arrived early, but it’s arriving late?

 

[croissantking]

Congrats on finding this! It must feel so satisfying after almost a year!

I’m honestly delighted.

 

[WillJac]

Amazing work and I am more amazed at the talent that is in the community along with how others got involved to find this issue. Glad it is an easy fix and looking forward to updated Gerber & BOM. What funny, my 2 previous board orders had the wrong cap but my last order seems C1883 was out of stock and somehow I replaced it correctly with C1906.

 

[croissantking]

I've made a short video to demonstrate how the fix has cleared things up on my board:

 

[ThisDoesNotCompute]

I'm a little unclear on exactly how to implement the fix. The photo above of the factory bodge wire shows it going from (a test point apparently connected to) pin 14 of UG7 to under the socket on UI6. Where does it go? And would that bodge be applicable to the Reloaded board?