Repairing Mac128K board - memory problems

Hi, Doug, I can help you. In the meantime, if you have a 512Ke or Plus handy, you can move the ROMs over to test. I've done that and I've seen what others have reported on some of the forums - I did find a missing data signal on the Din pin for G8, the one reported by my 020800 Sad Mac code. There was a via a few millimeters away, so repairing the signal was easy. I now get one of two codes depending on the ROMs, as others have reported in the past year - 04114E with original 64K ROMs, or 03114E with 128K (512Ke/Plus) ROMs. I found the minivMac tools and disassembled both sets of ROMs with comments (applied automatically by FDisasm) and am still puzzling out what they are doing. I'll be happy when I can understand the code that renders the Sad Mac itself and how it renders the error code text because then I can backtrace that to what the code must be doing when the test fails. It's only a page or two of 68000 assembly, and I've written *lots* of it, so I'm not worried about puzzling out some RAM tests. To be fair, though, the code is slightly odd because there's no usable RAM yet, thus no stack, so all the early subroutine calls are done by stuffing the next instruction into a register (commonly A6) and BRAing to the subroutine which knows to branch back via that register. Not hard to understand, but it adds a little clutter to the flow. So that's where I'm at right now - I'm past the 02xxxx Sad Mac by repairing an open Din signal to the socket, and I have an 04xxxx or 03xxxx code that at least two other people have recently supported - one of whom has described his efforts to repair including replacing 100% of the RAM and 25% or more of the TTL on his board. Nobody else who is reporting this error has reported fixing their board, and some of the comments are from this month. I now know of three 128K Mac boards in this condition, all with different error numbers, but no resolution yet. As with the others, my code, if treated like a bitmask, suggests that 6 of 16 DRAMs are defective. I don't think that's so. I think the problem is elsewhere and I think I need to understand what the firmware is doing and where that number comes from before I can truly understand what's wrong. I'm very close, now, to pulling the CPU and installing 64 loose machined pins (stuck to the bottom of a proper 64-pin socket for alignment). It's not as mechanically sturdy as a 64-pin socket, but it's easier to reverse and easier to inspect between the pins for damaged traces or good upper solder joints. The purpose of pulling the socket, of course, is to stuff a Fluke 9010A into the hole and run bus and RAM/ROM tests. I'll contact you off-list about solutions to your problem. Cheers, -ethan On Sun, Sep 15, 2013 at 10:35 PM, Doug Jackson <doug at doughq.com> wrote: