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

 

[BeniD82]

Friend of mine let me use the SWIM and sound chips from one of his currently dead IIci boards so I can try to get the portable going again (I'll still be looking for another SWIM and set of Sony chips so we can fix his board next). Soldered on the new SWIM, crossed my fingers and fired up the the machine... and it booted to the cursor/flashing floppy disk icon! Hooked up my BlueSCSI and was able to load 6.0.8 and get to the desktop no issues. Success!

It doesn't detect the RAM card currently so full testing was limited and I still need to add back the Sony DACs and sound related caps but so far so good! Probably a few extra broken lines to the RAM socket. Anyway, thanks for the pointers and guiding me into the right direction! Ignore the haphazardly soldered jumper wires, once ready I'll properly attach, route and secure them.

 

[BeniD82]

It's been a minute to so figured I should provide a status update. If interested, see the details below, otherwise TL;DR: Got it fully working and project completed.

---

After going over all traces between the RAM connector, CPU, CPU Glue, and MISC Glue several times (ROM and PDS for good measure as well), I was not able to locate anything apparent that would point to bad traces being responsible for the card not being detected. I did notice that on the RAM card itself pin 32 (Delay_CS) appeared to be cut which struck me as odd (not sure why that'd be the case, clearly you'd need some sort of chip select signal to control when external RAM should be active I imagine). Bodged the trace but unfortunately that made no difference.

Figured that it might be worth probing the various logic ICs responsible for generating the on-card chip select and noted that for several of them I was able to read system voltage (5.22V) on signal pins rather than fluctuating voltage levels which tends to be the case when data's shuffled across (had returned the oscilloscope I had borrowed so couldn't check data/addressing related activity). Some of the chips apparently had shorted out internally.

Since it seemed the system did have some sort of catastrophic power related event that had been responsible for its early demise, took a chance and pulled the logic ICs off the card and replaced them (also swapped the buffer chips just in case). Plugged the card back in, started the machine, and noticed that it was now sitting on the gray screen quite a bit longer than before, and after a few more seconds of agony waiting, boom, booted to a full 5MB of RAM!

Went a bit too heavy with the hot air gun on the card but was able to get the discoloration you see on the pic gone, this RAM board has the thickest conformal coating imaginable. Performed thorough testing, loaded up a bunch of software and everything appeared to be in good working order.

After a good while of me trying to route the bodge wires neatly on the logic board I gave up and just made sure they're connected securely to the ICs and glued them down so they won't come loose (magnet wire is fiddly). Not my best work and won't win a beauty contest but not like anyone's really going to see that anyway.

The rest was all fairly routine maintenance. Cleaning everything, lubricating the floppy drive, replacing the cheese gear, replacing the rollers on the track ball. Also rolled myself a power cable so I can provide dedicated power to the BlueSCSI from the unused floppy connector (the SCSI connector does not provide power immediately after the system is turned on and may shut off power or cause freezes due to the delayed start so that's a good way to bypass that).

The parts shown above are pretty much everything I had to replace to get the machine going again. Not shown are all the caps that were needed, the new hybrid module, and replacement battery pack.

Restoring a dead portable definitely is not for the faint of heart, I have to say, but once you do get them working again, rather nice. One bucket list item has now been checked off