Portable's First Signs of Life, Need Help Deciphering Error Codes / Next Steps

[BeniD82]

First post here on Tinkerdifferent!

So the Macintosh Portable had been one of my long term goal “bucket list” items and a few months ago I was finally able to grab a rather inexpensively priced machine. The system itself was in great cosmetic condition but sold as non-working, which of course is expected, but also with the caveat that repair had already been attempted and had been unsuccessful which generally does not bode well (and probably also why it was affordable). The thing was dead as a doornail when I received it.

The hybrid module had been mangled pretty badly and from what I can tell this machine must’ve suffered some serious power related damage in the past, either running it with bad caps or on a power supply without using a good battery (assuming by the state of the Sony sound chips, absolutely cooked, shorting the 12v for sound to ground for one).

Between a new hybrid module from Androda (which works perfectly by the way), completely cleaning and redoing the recap properly, as well as having to remove the Sony sound chips and a dead SWIM chip I was able to get the machine to boot to ROM. Obviously no sound currently but perfect image on the LCD and power manager seems to be functional thankfully.

This is where I’d need a bit of guidance/help with deciphering the ROM error codes received and next steps. The code that pops when booting appears to be the following (this is the most consistent code the machine displays):

00000005
00010000

I believe 0005 is an addressing related error but unsure how to decipher the minor code unfortunately. I was also able to get the machine to start in diag mode over serial and performed additional testing there as well (https://tinkerdifferent.com/threads/freshly-recapped-portable-ram-faults.3200/ was incredibly helpful). On rare occasion I may also receive 0000008 / 0000FFFF error codes on start but not frequently (I am assuming the system halts at an earlier stage generally).

Walking the individual 64KB blocks appears to return an “ok” response based on how I interpret the results, but who knows if the test is actually targeting the correct chips or working correctly if addressing isn't working as anticipated.

*S
*A
*4
*000000000
*10000FFFF
*T000600010000
*R

000000000000*R

Walking larger blocks, e.g. 000000000 – 00001FFFF (128KB segment) will result in 0000FFFF0000*R, and that’s regardless of the size/location of tested blocks and also the same if I try running the test over the entire 1MB range.

I also attempted the address line test *T0003 executing 0x901FEE which seems to return 000100000000*R as response.

So, wanted to see if anyone has any pointers on where I should be looking next? I traced out the address and data lines from RAM to their respective buffers and to the CPU and they all do appear to be connected. What I gather from Techknight's repair experiences/Youtube content (the content's been a great resource by the way) the address buffers and other discrete logic ICs seem to get taken out by overvoltage fairly often as well but not certain if these are the culprit? Some of the RAM chips do look pretty cooked as well (writing worn off quite bit) so fair chance I'll have to swap some eventually but before randomly plucking off chips would like to try to see if the specific failed area can be identified first?

Would be grateful for any tips, and thanks in advance!

 

[SuperSVGA]

The address line test failure (error 5) is a bit tricky to precisely decode because it's an XOR of the contents of memory against the expected value.

My guess would be that it wrote 0x00010000 to location 0x00010000, but when it read it back it got 0x00000000. This would be the point where it was testing address line 16.
The location it tested prior to this would have been 0x00008000.

Also notable is that the memory sizing and data bus tests at the beginning and end of RAM passed to get up to this point, so the buffers and other critical parts are working.

Address line 16 and above are not actually connected to the RAM. They go through the MISC GLU which then generates the CS* lines for each pair of RAM chips. If you were missing a CS* to RAM, I'm guessing the computer would read garbage rather than 0x00000000, but I'm not certain. You definitely wouldn't be able to write to those chips.

At this point in time there is a location that contains 0x00000000 which is the address 0x00000000. So if the CPU drove address line 16 but it didn't work, no address lines would be driven and you would reach location 0x00000000 instead.

My thoughts would be to check A16 between the 68000 and the MISC GLU, or possibly RAM CS1* between the MISC GLU and RAM.

 

[BeniD82]

Thank you very much for your response SuperSVGA! I did not think of that, I was focusing on just the lines from the CPU/RAM chips so hadn't looked at the MISC GLU/chip select. I should have some time tonight to check the area you called out. Good to know that all the critical parts seem to be working, so already pretty stoked about that. I'll let you know what I find. Appreciated!

 

[BeniD82]

Hi SuperSVGA, had a chance this evening to work on the board some more. I did end up tracing the address lines between CPU and MISC GLU. Those turned out be OK but I do want to give you a shout out because you were absolutely spot on with your suggestion that there may be issues with the chip select lines. CS5, CS6 and CS13 did not connect to their corresponding RAM chips at all! I added some temporary bodge wires and the board no longer throws a sad mac/error codes and now remains at the half gray pattern (I believe this is the behavior one should expect if not having a SWIM installed). Hard to say if it chimes since I don't have working Sony sound chips either at present

Ran the same memory diags over serial and they are now passing even if I check larger segments including the entire 1MB range at once (takes several seconds to complete if testing the whole range), so seems once I have a working SWIM installed I *might* have a somewhat functional board. Stay tuned