Print

[pintoguy]

I was hoping to solve this on my own, but today I thought I needed to swallow my pride and ask for help.

The background: A Lisa 2/5 (with parallel card) plus two 5MB Profiles that I bought on eBay. The seller was in the LA area, and since my daughter lives there, she picked it up and brought it over to me in Palo Alto. This saved a few $100s in S/H. This 2/5 looks like it's actually a converted Lisa 1, as evidenced by the Twiggy power cable and the two floppy ribbon cables (see pic)

I was able to successfully reformat the two Profiles using the parallel card on one of my two 2/10. The CPU and both memory cards also tested OK. PS is good, after the two RIFA caps blew up and were replaced. The batteries of the 2/5 had never been removed, and the corrosion on the IO board and MB was extensive. I have not given up on the MB as yet, but decided to build a new one, using AlexTheCat123 github PCB info (Thanks !). I bought most of the components on AliExpress, and saved a ton of money (sorry Digikey...).This allowed me to do some good work on the IO board, and after replacing the 10uF Nichicon caps on the video board, taking the 400k FDD apart for de-seizing/lubing, removing corrosion on all sheet metal parts, retrobriting the case, and changing the light bulb in the on/off switch, I'm almost there.

I have a few remaining issues

1) The system boots only with one memory board in position Mem1. If I put the second board in Mem2, I have garbage on the screen
2) I still have the dreaded Error 57, stemming from the Disk Diag ROM test (documented in a previous post here). I did check that the Dskdiag signal (pin 11 on LS259 in U3E) was low, when it's high on my working 2/10
3) The keyboard is also not seen, nor do I have the "keyboard missing" error upon boot. The speaker also does not work
4) Past error 57, I can start booting from the Profile (with either MB or extension parallel ports), but get stuck after a while
5) The IO ROM version which should be H/A8 shows H/9F or sometimes H/91 or H/9D (see pics)
6) My good 2/10 IO board also throws error 57 when placed on the 2/5, but displays the correct H/88 ROM versions. It also boots from the Profile, using my parallel card. After booting, it gives me a diskette error ("not a proper Lisa diskette" etc..)
7) I swapped all common socketed chips with my 2/10 IO board, including the VIA2 chips, with no progress
8 ) I tested the 400k FDD on my 2/10 and it works

Thanks for reading this. Any help would be much appreciated, especially from AlexTheCat123 if he has time. Some of the questions I have

1) There are two floppy cables (see pic). Does it matter which one we plug in (I tried both with no luck)
2) How is the dskdiag signal generated ? How can I test upstream of that, perhaps on the LisaLite adapter ?
3) Could the floppy/speaker/keyboard problem be related ?
3) The next obvious test would be to swap the IO ROM with a known good one. Would one of you be coming to VCF-West this weekend, and be kind enough to give me a loan of one for a day ?

Thanks in advance

[AlexTheCat123]

1) There are two floppy cables (see pic). Does it matter which one we plug in (I tried both with no luck)

Yeah, the LisaLite should be plugged into the cable for the lower Twiggy drive. I'm not sure what would happen if you used the upper cable, but I'm pretty sure it wouldn't work.

2) How is the dskdiag signal generated ? How can I test upstream of that, perhaps on the LisaLite adapter ?

From what I understand (my knowledge of the floppy controller is somewhat limited), DISK_DIAG is generated by the 6504 once the floppy controller has passed its internal self-tests. So if it's not getting asserted, the controller isn't passing those tests. The LS259 is just an addressable latch, so it latches the state of MA0 into the DISK_DIAG latch (addressed by MA1-MA3) whenever the 6504 tells it to.

A couple of people have had issues where the 16 MHz clock on the I/O board never starts up thanks to Q1 and Q2 presumably not having enough capacitance. Try probing pin 2 of U7A to see if you're getting a 16 MHz clock there. Don't probe the traces coming out of the transistors directly because the extra capacitance from your scope probe will probably cause the clock to start running, making it look like things are working fine! If there's not a clock on that pin, those transistors might be your problem! I know one person who just threw a crystal oscillator in there to fix this, so that's definitely an option if this ends up being your issue.

If you're getting the clock, check pin 1 on the 6504 (the reset pin) to make sure that it's getting reset at power-on. If that looks good, try probing Q0-Q3 on the LS161 at U7A. This counter chip provides the state sequences that control the operations within the floppy controller, as well as the 6504's clock, so things could definitely go wrong if the counter isn't counting.

Also go through and probe all of the address and data lines on the I/O board ROM to make sure that they all have activity on them.

And one other thing: did you use an LS367 or an 8T97 for U2F? The original design uses an 8T97 (despite the silkscreen insisting otherwise) and I discovered that the LS367 is just too slow and can cause some really preplexing issues. This probably isn't the cause of your current problems, but it could definitely eliminate some confusion down the road!

The floppy controller is probably the subystem that I understand the least out of everything on the I/O board, so I apologize if the above suggestions aren't super helpful!

[pintoguy]

Thanks AlexTheCat123 for the great suggestions. I will check on this shortly.

In the meantime, I noticed in your MB wiring that the signal R1 and R2 (pins 71 and 72 of the J2 CPU Board connector) go to pins 8 of the Mem2 (R1) and Mem1 (R2) connectors, respectively. The schematics calls for these to go to Mem1 (R1) and Mem2 (R2). In other words, they were inverted. Could this explain the issue I have when I have a 512k card in the Mem2 board ?

[sigma7]

I was able to successfully reformat the two Profiles

Wow, two working ProFiles, good deal!

1) The system boots only with one memory board in position Mem1. If I put the second board in Mem2, I have garbage on the screen

What happens if you install in Mem2, leaving Mem1 empty?

5) The IO ROM version which should be H/A8 shows H/9F or sometimes H/91 or H/9D (see pics)

The I/O ROM version is collected from the RAM shared with the 6504/Floppy Disk Controller. If the 6504 isn't running, it won't have moved the ROM version into the shared RAM and you'd get random RAM contents as it seems you have. If the 6504 is fine but the CPU's access to the I/O board is not working properly, then you could have the same symptoms. If the I/O Board wasn't responding at all, you'd get a bus error, so I suspect at least some of the circuitry is working some of the time.

1) There are two floppy cables ...

As Alex said, only the "lower" drive is supported by the Lisa 2. The lower drive cable is the shorter one. Leave the long one disconnected (unless connected to a Sun20, X/ProFile, etc. for power)

All Lisa 2 computers (aside from the ones with the internal Widget) have the two floppy drive cables, so having two isn't an indication that it used to be a Lisa 1.

2) How is the dskdiag signal generated ? How can I test upstream of that, perhaps on the LisaLite adapter ?

"Disk Diag" is a misleading name IMHO; it is a software generated signal controlled by the 6504. It isn't connected to the Lite adapter or the floppy drive.

During normal operation, it indicates the FDC is performing a time sensitive routine (ie. reading/writing to the floppy), and so the 68K should not access the shared RAM (and is locked out if it attempts to do so). (When the 68K accesses the shared RAM, the speed of the FDC is briefly reduced giving the 68K time to access the RAM without contention with the 6504.)

In the I/O ROM listing, the Disk Diag signal is controlled via accesses to "DISL" and "DISH" with the comment that these are "Memory Enable/Disable for the 68k"

Since this signal is accessed through the parallel port VIA, it must also be working to read the signal properly.

3) Could the floppy/speaker/keyboard problem be related ?

The speaker is connected to the motherboard via the J2 card edge connector. The floppy and keyboard are connected via the J1 card edge connector. All 3 go to the I/O board. Since there are other issues with the CPU talking to the I/O board, I'd guess the I/O board is the problem. If a known working I/O Board has the same problems, then I'd suspect the motherboard... check the card edge connector contacts are in good shape.

3) The next obvious test would be to swap the IO ROM with a known good one.

The I/O ROM is involved with the FDC only. Since there are other I/O problems (keyboard, speaker), there must be another problem (perhaps in addition to the I/O ROM, or the ROM may be fine).

HTH

[sigma7]

I noticed in your MB wiring that the signal R1 and R2 (pins 71 and 72 of the J2 CPU Board connector) go to pins 8 of the Mem2 (R1) and Mem1 (R2) connectors, respectively. The schematics calls for these to go to Mem1 (R1) and Mem2 (R2). In other words, they were inverted. Could this explain the issue I have when I have a 512k card in the Mem2 board ?

R1 and R2 control which Memory slot is doing refresh cycles. The refresh alternates between the two boards to reduce power requirements. Swapping them should not make a difference.

edit: on further thought, maybe it does make a difference:

The two slots have the rows addressed in opposite orders (so the physical memory expands outwards from the 1MB address location).

The refresh is done in conjunction with video cycles, but the refresh rows are not done in opposite orders in the two slots.

Hence if video is coming from the slot that has reversed addressing, but the refresh happens simultaneously from the non-reversed addresses, perhaps there is contention with two rows accessed during one video cycle?

However, only one row's column will be accessed when the data is read, so no, there should not be contention... false alarm, I'm back to thinking that "Swapping them should not make a difference"

[AlexTheCat123]

In the meantime, I noticed in your MB wiring that the signal R1 and R2 (pins 71 and 72 of the J2 CPU Board connector) go to pins 8 of the Mem2 (R1) and Mem1 (R2) connectors, respectively. The schematics calls for these to go to Mem1 (R1) and Mem2 (R2). In other words, they were inverted. Could this explain the issue I have when I have a 512k card in the Mem2 board ?

What a coincidence! Someone else reached out to me this morning and noticed the same thing! It turns out that I somehow accidentally swapped the footprints of the two RAM slots when designing the board, so the slot labeled MEM 1 is actually MEM 2 and vice versa. This won't affect the functionality of the Lisa at all (which is why I never noticed it), but it might be a little confusing if the self-test finds a RAM error because it would report the wrong slot being bad. I already updated the Gerbers on Github to fix this problem, so anyone who makes boards in the future won't have to worry about this. I'm really sorry about my mistake!

I don't think this would cause any of the memory issues that you're seeing because my boards have the same design flaw and work fine, so it's likely to be something else!

[pintoguy]

Thanks sigma7 ! Much appreciated

In response to your and AlexTheCat123 comments:

did you use an LS367 or an 8T97 for U2F? It's an LS367. I had seen your post regarding Error 57 and this chip. I'll keep this in mind

What happens if you install in Mem2, leaving Mem1 empty? Same result: garbage on screen

The I/O ROM version is collected from the RAM shared with the 6504/Floppy Disk Controller. If the 6504 isn't running, it won't have moved the ROM version into the shared RAM and you'd get random RAM contents as it seems you have. If the 6504 is fine but the CPU's access to the I/O board is not working properly, then you could have the same symptoms. If the I/O Board wasn't responding at all, you'd get a bus error, so I suspect at least some of the circuitry is working some of the time: Thanks. The 6504 was swapped with a spare one, with no change

As Alex said, only the "lower" drive is supported by the Lisa 2. The lower drive cable is the shorter one. Leave the long one disconnected (unless connected to a Sun20, X/ProFile, etc. for power). All Lisa 2 computers (aside from the ones with the internal Widget) have the two floppy drive cables, so having two isn't an indication that it used to be a Lisa 1. Thanks.I also have a spare molex power cable which I thought was there to power the twiggies. Is this not the case ?

And thanks for all other great suggestions. I'll go back to the bench this weekend, and will update !

[pintoguy]

What a coincidence! Someone else reached out to me this morning and noticed the same thing! It turns out that I somehow accidentally swapped the footprints of the two RAM slots when designing the board, so the slot labeled MEM 1 is actually MEM 2 and vice versa. This won't affect the functionality of the Lisa at all (which is why I never noticed it), but it might be a little confusing if the self-test finds a RAM error because it would report the wrong slot being bad. I already updated the Gerbers on Github to fix this problem, so anyone who makes boards in the future won't have to worry about this. I'm really sorry about my mistake!

You don't have to apologize ! And yes, what a coincidence indeed !!

[sigma7]

The I/O ROM version is collected from the RAM shared with the 6504/Floppy Disk Controller. If the 6504 isn't running, it won't have moved the ROM version into the shared RAM and you'd get random RAM contents as it seems you have. If the 6504 is fine but the CPU's access to the I/O board is not working properly, then you could have the same symptoms. If the I/O Board wasn't responding at all, you'd get a bus error, so I suspect at least some of the circuitry is working some of the time:

Thanks. The 6504 was swapped with a spare one, with no change

A variety of problems will prevent a good 6504 from running; Alex's suggestions to confirm it is probably working such as checking the oscillator/clock is running and the bus is active are likely sufficient.

Lisa 2 computers (aside from the ones with the internal Widget) have the two floppy drive cables, so having two isn't an indication that it used to be a Lisa 1.

Thanks. I also have a spare molex power cable which I thought was there to power the twiggies. Is this not the case ?

That 3 pin cable is also in all Lisa 2 computers (unless they are wired for a Widget). It isn't used for Twiggies (or anything else that we know of).

[pintoguy]

So here is a progress report after the weekend bench work

Try probing pin 2 of U7A to see if you're getting a 16 MHz clock there: Yes, I see a clear 16MHz signal

If you're getting the clock, check pin 1 on the 6504 (the reset pin) to make sure that it's getting reset at power-on. Yes, the reset signal is high, and goes low when I push the reset button

If that looks good, try probing Q0-Q3 on the LS161 at U7A. This counter chip provides the state sequences that control the operations within the floppy controller: This is a bit beyond my skill set, but signals q0-q3 do show square waves of various duty cycles. I assume it's what you'd expect ?

Also go through and probe all of the address and data lines on the I/O board ROM to make sure that they all have activity on them: there is NO activity that I can see. Would this help us ?

[AlexTheCat123]

It's great that you have clock and reset! When you say that reset goes low when you push the reset button, I'm assuming that it goes high again around a second later, right?

If that looks good, try probing Q0-Q3 on the LS161 at U7A. This counter chip provides the state sequences that control the operations within the floppy controller: This is a bit beyond my skill set, but signals q0-q3 do show square waves of various duty cycles. I assume it's what you'd expect ?

Yep, that sounds about right. Each one of those pins should have a square wave of a different frequency on it!

Also go through and probe all of the address and data lines on the I/O board ROM to make sure that they all have activity on them: there is NO activity that I can see. Would this help us ?

Well, that's a big problem! You've already confirmed that Q0-Q3 on U7A are producing square waves as they should, but now maybe try probing pin 27 (PHI0) on the 6504 to make sure that the signal from Q2 on U7A is actually getting to the 6504 to clock it. If it is, then you might have a bad 6504. Assuming it's getting reset at power-on and it's being clocked correctly, you should be seeing activity on the bus, even if there are still serious problems somewhere else in the floppy controller circuit. I guess you could also have a bad EPROM (or one of the other chips connected to the bus) that's pulling those lines to 5V or ground, but that's probably pretty unlikely. Do you have a spare 6504 (or a 6507 from something like an Atari 2600) that you could swap in? That's probably what I'd try next!

[pintoguy]

Thanks Alex. Please see my replies.

When you say that reset goes low when you push the reset button, I'm assuming that it goes high again around a second later, right? Yes

try probing pin 27 (PHI0) on the 6504 to make sure that the signal from Q2 on U7A is actually getting to the 6504 to clock it: Yes, I get Q2 on pin 27

I guess you could also have a bad EPROM that's pulling those lines to 5V or ground: I checked every pin on the 6504, and only get the 5V at pin4 and ground at pin2, which I think is normal

Do you have a spare 6504 that you could swap in? Yes I do (from a working 2/10). It doesn't help

Should I look for an EPROM replacement ? Is this IO ROM re-burnable ?

[blusnowkitty]

Should I look for an EPROM replacement ? Is this IO ROM re-burnable ?

The ROM can be reburned or replaced easily, it's a standard 27(C)16. ROM images are up on Bitsavers.

[pintoguy]

Thanks. I haven't had a chance to do much in the past few days, but here is the latest:

1) The IO ROM placed in a good IO 2/10 board does display the proper H/A8 ROM codes. Is still shows error 57, but I think it's normal (2/5-2/10 floppy controller mismatch ?)
2) I actually have sporadic activity on the data lines of the IO ROM that comes and goes. But even when I see activity, I still have the error 57 issue
3) I tried to boot without the IO ROM chip in, and get exactly the same error
4) Then at some point, the board stopped working completely, and my 2/5 now boots with just the gray screen, with the CPU ROM letter "H" on the screen

I know the integrity of the gold pad from the edge connector J1 is important. They were quite corroded, and I cleaned them and coated them with solder as best as I could, but they still show missing areas. As far as I know, they still make good contact, but perhaps I should put some new copper strips on these pads. Any suggestion for what to use and how ?

Thanks

[sigma7]

I know the integrity of the gold pad from the edge connector J1 is important. They were quite corroded, and I cleaned them and coated them with solder as best as I could, but they still show missing areas. As far as I know, they still make good contact, but perhaps I should put some new copper strips on these pads. Any suggestion for what to use and how ?

I suggest checking any questionable circuits that pass through the card edge using an ohmmeter with the card plugged in. (eg. measure from a part on the I/O board to the bottom of the motherboard or a part on some other board.)

A durable repair of a card edge finger takes some extra care and if there are multiple pads to replace that's probably a big job.

The pads are epoxied in place, but to maintain the board thickness (to prevent damaging or deforming the socket), you probably need to grind a recess in the board where the pad will go to make room for the epoxy. You can then gold-plate a copper pad with a simple kit, or use an already gold plated pad removed from a donor board. Note that card edge fingers are plated with a different (more durable) gold alloy than the gold that covers all of some modern boards, so I suggest using a scavenged card edge finger for the repair.

Since you may be troubleshooting further corrosion problems on that board, another option is to populate a bare board (either with new parts or moving parts from the defective board) ... I believe the Sapient Technologies boards are available (or will be soon) as bare boards from John / VintageMicros.com