• Hello, Guest! Welcome back, and be sure to check out this post for more info about the recent service interruption and migration.

Reverse Engineering the Macintosh LC Logicboard

max1zzz

Well-known member
So, pepperoni, mushrooms, bell peppers, and onions? 🍕 Um... no, that's a pizza. Nevermind. ;)
I'm with you up until the onion! :)
It occurs to me, that it might be helpful to people who are restoring original PCBs that got capacitor/battery bombed to have the raw scans of the various layers, so as to see what traces went exactly where... 🤔
The original scans aren't always the clearest, (Apparently my scanner won't scan at higher than 600dpi despite canon clearly claiming it is a 2400dpi scanner.....) I'll export the top and bottom copper from sprint to images as those are much clearer (I did just do this, then I remembered I still need to fix a couple of layout issues, so I'll upload them once I have done this)
 

bdurbrow

Well-known member
I'm with you up until the onion!
WHAT!?!?! No onion! What kind of uncouth, plebeian hooligan are you?!?! 😜



2400 "digitally interpolated" DPI, perhaps?

Yes; but the original scans are of the original PCB; and your redraw will have small variations (those layout issues you mention)... so I would suggest posting both.
 

Daniël

Well-known member
Apparently my scanner won't scan at higher than 600dpi despite canon clearly claiming it is a 2400dpi scanner.....

As someone shooting film photography, (film) scanners lying about their true DPI is all too familiar. Sure, the software can save 2400DPI pictures, but the optics aren't going to push beyond 600DPI. It gets worse with my Epson V600, claims a grandiose 6400DPI despite it optically really not being able to go beyond 1600DPI or so, it's terrible.
 

mg.man

Well-known member
Well... as it happens, I do have a Creo IQSmart 3 - which is an A3, 5500 (true optical) flatbed scanner. Probably too late for the LC 'board (I assume it got sanded?), but if the LC III has not met this fate, I'd be happy to scan that...
 

max1zzz

Well-known member
I didn't actually sand the LC, didn't need to in the end (I managed to figure out all the splits in and connections to the planes with just a bright tourch) Also managed to get the III board scanned to a acceptable enough quality for reverse engineering

However I might send a stripped Classic II board and maybe a stripped LC II and 475 board to you for scanning :)
 

mg.man

Well-known member
However I might send a stripped Classic II board and maybe a stripped LC II and 475 board to you for scanning
Sure! I also need to send some bits your way - like those 30 pin angled sockets... ;) I'll PM you on our other thread.
 

max1zzz

Well-known member
So, finally got around to doing some testing and everything seems to be working perfectly :)
Audio in and out both work fine, Ext scsi works fine, PDS works fine (At least a PDS Ethernet card works and I was successfully able to connect to my network), I connected up a real floppy drive and verified it formats, reads, writes and ejects the disk fine, serial works (at least on a basic level, I was able to send and receive data on both ports using a serial to usb adapter connected to a modern machine)

As I am now confident these are fully working I'll correct the errors in the design and get another batch assembled :)

Is there anyone wanting on of these boards? (They'll be £35 each excluding shipping, Assembly will be available for a additional cost) If not I'll just order the minimum quantity. This run of boards will be in matte black, any future runs will be in blue
 

max1zzz

Well-known member
I'd love one with assembly if I can find where my donor board went :D
Great :) I'll PM you in a little bit

So, Just when I thought it was all working I have found another issue.
NVRAM data is not being kept when the board is powered off, this appears to be because when you power off the voltage on the EGRET's power supply line dips while it is transitioning from AC power to backup battery power (This is done by pulling the base of Q2 low through a 3.3M resistor, when on AC power this is pulled up to +12V by a 470R resistor. Q2 is a PNP transistor that connects the backup battery to EGRET's power supply line).

On a stock board the voltage never dips below that of the backup battery. (At least my multimeter doesn't see it, so if it dose dip it happens faster than the refresh rate of my multimeter)

If I connect the battery to EGRET's power supply line through just a diode NVRAM data is retained just fine, also if I tack a higher value cap over C9 (Like on some early / pre-release boards) NVRAM data also survives just fine so it appears the transition is just not happening quick enough

I have verified the pull up / pull down resistors are the correct value and have tried swapping Q2 and EGRET from the known good board and the issue still persists. I'm now at a bit of a loss as to what the issue is....
 

max1zzz

Well-known member
Swapping the 3.3M for a 100K also fixes the issue, I'm OK with ths fix as it dosen't require modifying the board or and bodges, but it still bugs me that the original board seems to work with a 3.3M in that position!
 

max1zzz

Well-known member
V1.1 PCB's are here!

IMG_1683.jpg

Unfortunatly I forgot to connect /OE and /CE on the one chip I missed the connection on the V1.0 PCB so these will require a jumper wire....
 

max1zzz

Well-known member
After much confused probing of the board the mystery NVRAM issue has been solved!

So what was the issue? something bizarre and abstract? Not really....
10-11-21.JPG
One single via which should be connecting pin 4 of the MC34064 at UD9 to GND was instead connected to nothing

One small piece of bodge wire later (Connecting pin 4 of UD9 to a very conveniently placed ground pin on the Egret)
10-11-21-2.jpg
Testing the board with this fix in place reveals that the NVRAM data now survives power cycles just fine with no component substitutions :)

So what's going on here? UD9 is a MC34064 undervoltage sensing IC, it's output is connected to pin 12 of the Egret. What exactly pin 12 of the egret dose is not completely clear, it's not the reset pin of the MCU and the BOMARC schematic of the LCII mark it as "reset in" so perhaps once the voltage of the +5V rail starts dropping this instructs the Egret to yank /RST low and stop the CPU etc running and this slows down the rate at which the voltage on +5v drops, giving the power supply circuit for the Egret a little more time to switch over to the battery? Or maybe this simply instructs the Egret to go into a low power standby mode? Whatever is supposed to happen UD9 isn't going to be able to tell the Egret do it with no ground reference!

Either way with pin 4 of UD9 grounded the EGRET's supply voltage drops slowly rather than the sharp drop and bounce back I was seeing before and NVRAM data is not lost
 
Top