Post repair summary

[pinto_guy]

I recently acquired a Lisa 2/10 from its original owner, on Craigslist (SF Bay Area). It came with an original Lisa 1 mouse p), and lots of software with manuals in mint condition. The cosmetic condition of the Lisa was impeccable, but it did not quite work. The screen was shaky, and you could tell that the Lisa did not want to boot. After two weeks of diagnostic/repair, I'm happy to announce that it's now working perfectly.

So here is the list of things that I did. If this post can help our community, that would be great. This is the intent.

1) Video board
- Recapped all electrolytic caps. This helped the video output quite a bit, but I still had a horizontal fold-over that the HOR PHASE trimpot (R34) could not fix
- Then realized that this trimpot was shot (open resistance). After I replaced it, the video was perfect

2) RAM Card
- One RAM card threw a "Parity Error". This actually did not prevent the system from booting, but it was annoying. I could not fix it, and ended up buying a replacement one on eBay ($125)

3) FDD
- We had the usual seizure of the eject mechanism, and the lubrication job did the trick
- There was a loud rubbing noise at every turn of the motor, which I eventually found came from a small plastic shim under the disk, that had a corner folded. This small fold was rubbing against the disk. That was an easy fix.

4) Widget
- Amazingly, the Widget initially worked. However, it died quickly and suddenly (read error #52 on NeoWidEx), and it took me a long time to fix
- Thankfully, I had a spare, working widget, and a series of swaps identified the culprit: The "Lizzy" chip (341-0301 U4 with green sticker on photo) on the controller card was fried. I had to purchase a spare card on eBay ($25 or so)
- However, even after the new chip was installed, I could not format the drive. It took me a whole afternoon of trial-and-error using NeoWidEx and BLU to finally succeed. I think what did it was to re-initialize the servo offset table. I cannot thank enough the great people (Tom Stepleton and James MacPhail) who give these fantastic tools to our community for free.
- Finally, I realized that the solenoid that holds the actuator latch was not working. Not a big deal since the widget still works without it, but the loud "clonk" when it releases is such a part of the widget, that I really wanted to make it work
- Found the culprit: a 2N4403 transistor (Q5) near the solenoid connector on the small card at the bottom of the drive (motor and solenoid controller) was shot (see photo in red, plus close-up). After replacement, a healthy "clonk" could be heard again.

Thanks again for all the great postings on this board that are of tremendous help. A youtube video was made, showing the latch-actuator mechanism during startup

 

[cheesestraws]

Thankyou for posting this! These machines are incredibly fixable, and the more people know that the better.

And—working widgets? What magic is this?! Both mine are dead and are being donated to science (or perhaps wizardry, since they're going off to @stepleton whose skill amazes me)

 

[stepleton]

Congratulations on fixing the Widget! It sounds like you had an intense troubleshooting session, so getting everything working again must have been really sweet. So far the biggest Widget repair mystery I've had to solve has been needing to replace one of the 74LS09s on the controller board. I'm really looking forward to the challenge of @cheesestraws' drives, and will probably reconfigure my "lab" space just to have room to work on them properly.

In the meantime, it really makes me happy to hear about people getting good use out of NeoWidEx! Whatever wizardry I possess, though, is just reflected light. I'll add Dr. Patrick Schäfer [1][2] and Bitsavers to the honour roll --- their research and preservation made my stuff possible.

 

[pinto_guy]

Thanks @stepleton and @cheesestraws for your comments. Once again, I greatly benefited from your insight, and I could not have done this without your previous posts and these software tools.

Looking forward to reading about these two Widgets.

By the way, would you have any pointer for fixing a parity error on the RAM card ?

Also, do you know the function of the Lizzy chip ? Data channel perhaps, converting the waveform to bits ? What I noticed is that even though it was dead, the head could still servo, telling me that the data/servo waveform could still be read.

 

[stepleton]

I'm afraid I don't know for the RAM card, but I'm glad to hear you're going to keep at it

Meanwhile, I'm pretty sure that "Lizzy" is just a Z8 microcontroller with a mask ROM. This makes it fairly easy to replace by the standards of early '80s custom chips: you can find a period-appropriate Z8 without a mask ROM that has a "piggyback" ROM socket (this seems to be an arrangement that Zilog was fond of back then), and then burn an EPROM with the firmware from Bitsavers and plug it in. In fact, there are a lot of Widgets that use this arrangement instead of a single chip, including both of my own. You can see a photo of a Widget with one of these piggyback setups on this blog post.

BTW, that same blog has a post about fixing Lisa memory errors. It's a different problem than the one you have, but you might be able to recycle some of its techniques.

Finally, don't hesitate to ask on http://www.lisalist2.com/, where you'll find even more people who've been a tremendous help over the years.

 

[pinto_guy]

Thanks @stepleton

I hope my Lizzy doesn't fail me again, but if it does, I will try the Z8 piggyback solution, although what I paid for the whole controller card was about the same price, and simpler (thanks vintagemicros.com)

And yeah, I read the posts about the memory errors. Nothing specific about parity errors though. And for the life of me, I could not find out whether this parity error would render the 512k board non-functional or not. The fact that I could still boot and run Lisa Office tells me that perhaps I got the whole 1MB firing. And I did not find a way to display the actual RAM size used by the system while powered up.

Thanks for the mention about Lisalist2. I knew it existed, but did not have the link. I tend to be loyal to 68kmla.org, but Lisalist seems like a better choice for all Lisa stuff.

 

[stepleton]

No need to choose IMHO, both are great

Depending on your preferences for reading material, the Lisa Boot ROM source code has decent comments --- reading it was actually how I got into writing 68000 assembly code in the first place. Searching it for "parity error" turned up some comments about the ROM storing address information for found defects: you may be able to work from that and isolate the problem to a small subset of the chips on your memory card.

 

[pinto_guy]

Oh thanks! My programming skills are limited to FORTRAN (yes I know ) and high level stuff like MATLAB. Assembly language always scared me... But you're right, there are several mentions of faulty parity chip location, so I'll look into it.

 

[pinto_guy]

And about 68kmla vs Lisalist, I noticed no posting since February in this Lisa forum, before mine. Did the newer stuff get wiped out during the recent outages ?

 

[cruff]

Look at the post referenced in the banner at the top of the page for the problems.

 

[pinto_guy]

Oh I see, thanks for pointing this out. I'll be in the camp of those who appreciate the patience and dedication of the people who donate their time to make this forum possible, and who clearly feel the pain more than everyone else.

 

[pinto_guy]

@stepleton : Thanks again. I found the location of the faulty chip using the info stored in memory locations 27C and 27D. This is also described in the LisaFAQ site. I had some spare 64k chips from a similar repair on a Mac 128h, and a soldering job did the trick. I could have saved $125 !

Thanks again for your help !

0000| 0000 0268 XPCTADDR .EQU $0268 ;memory test address for parity error CHG015
0000| 0000 026C XPCTDATA .EQU $026C ;memory test expected data CHG015
0000| 0000 0270 ACTADDR .EQU $0270 ;parity error address, phase 2 CHG015
0000| 0000 0274 ACTDATA .EQU $0274 ;actual data read on parity error, phase 2 CHG015
0000| 0000 0278 PEADR2 .EQU $0278 ;address read from error latch CHG015
0000| 0000 027C PCHPROW .EQU $027C ;parity chip row CHG015
0000| 0000 027D PCHIP .EQU $027D ;parity chip id CHG015

 

[cheesestraws]

I could have saved $125 !

Ah, but then you wouldn't have a spare :-D

Nicely done.

 

[pinto_guy]

Ah, but then you wouldn't have a spare :-D

Nicely done.

True

By the way, I botched the link to the LisaFAQ page where you'll find the solution to errors 70 and 71. It's here:

3.15.1. The self-test fails at the memory board icon and reports Error 70 or 71, can it be fixed?

 

[pinto_guy]

Oh, and in case you'll have the same problem that I had when following LisaFAQ instructions, read on.

When it says: "To display the 16 words at $186 type: 1186 20<return>"

It is actually: type 1 to get into the ROM sub-menu, then type the actual address (186 in this example, or 27C in my case), and then 20 to display the 16 words (20 in hexadecimal) following the 27C address.

Like an idiot, I kept typing 127C instead of 27C. Took me a while to understand my mistake.

 

[Greniu]

hello Gentelmens,

I am receiving #71 (parity error) and my Lisa cannot boot successfully. I put only non-working 512k memory into Lisa.

This is my result from Service Mode test:



Does anyone is familiar what might be wrong with this memory board?

I appreciate any help. Thanks

 

[pinto_guy]

Sorry Greniu for the (very) late reply. Please follow the procedure below from the lisafaq website

Parity Error 71​

You may have noticed something missing... there are 18 columns of chips, not 16. The extra 2 are for parity bits, one for each byte.

If there was a parity error, then all the data bits might be clean, represented by 0 in all 8 words at $186. In this case, you will get error 71 instead of 70 from the memory test.

In the case of a parity error:

• one byte at $27C contains a number that corresponds to the row as follows:

00 = row B when the problem board is in MEM 1, with MEM2 empty
01 = row C when the problem board is in MEM 1
02 = row D when the problem board is in MEM 1
03 = row E when the problem board is in MEM 1

04 = row B when the problem board is in MEM 1, with 512K in MEM2
05 = row C when the problem board is in MEM 1
06 = row D when the problem board is in MEM 1
07 = row E when the problem board is in MEM 1

00 = row E when the problem board is in MEM 2, regardless of MEM1
01 = row D when the problem board is in MEM 2
02 = row C when the problem board is in MEM 2
03 = row B when the problem board is in MEM 2

• one byte at $27D contains $09 or $14, which correspond directly to the board coordinate column of the bad parity chip, column 9 or 14. If this byte is zero, exit service mode by typing 7, then type apple-1 to run the self-test again; it seems that sometimes this is necessary to obtain the parity error data.
• long word $270 contains the logical address where the error occurred