Print

[dmark]

Has anyone in this community dealt with a fully deterministic Error 45 on your Lisa 2?

The Lisa 2 that I have on hand is one that came with a faulty PSU and battery leakage, but I repaired it and got it to a fully functioning state a few weeks ago, which I chronicled over at the TinkerDifferent forums. It worked perfectly for several weeks.

However, a few days ago I noticed that booting from floppy was becoming slower and slower, until it got to a point where it no longer boots from any floppy disk. When booting into LisaTest 3.0 in particular, it throws Error 45 (bus error). Booting into MacWorks leads to a Sad Mac with code 0f000a (Line 1111). Using a Lisa Office System boot disk just ends up with the system rebooting itself. It doesn't matter if I'm using the stock 400k drive and physical disks, or a FloppyEmu in Lisa mode. The same disks lead to the same exact outcome.

The '83 Troubleshooting Guide suggests that either the I/O Board, CPU Board, or Motherboard has a fault. Not terribly helpful! I've tried various combinations of memory boards, so that can probably safely be eliminated as a factor.

I went back and checked my repairs and bodge wires, tested the 5V rail on the I/O Board and -12V rail on the Lite Adapter board. Voltage levels are in spec, and there are no obvious signs of damage.

What I was doing leading up to the issue, was to play around with a newly acquired Sun Remarketing SCSI adapter board, using a RaSCSI to create and format hard drive images to install a MacWorks environment onto. It was running for a few hours at a time, and restarted quite frequently, so I wonder if the heat and activity caused some component somewhere to degrade?

And to preempt the question: I've *not* done a shotgun recapping of either of the modules. Caps that looked iffy, or tested out of spec, I've replaced. But it still has 90%+ factory caps.

Anyhow, grateful for any pointers how to further troubleshoot this poor Lisa!

[rayarachelian]

Has anyone in this community dealt with a fully deterministic Error 45 on your Lisa 2?

...

However, a few days ago I noticed that booting from floppy was becoming slower and slower, until it got to a point where it no longer boots from any floppy disk. When booting into LisaTest 3.0 in particular, it throws Error 45 (bus error). Booting into MacWorks leads to a Sad Mac with code 0f000a (Line 1111). Using a Lisa Office System boot disk just ends up with the system rebooting itself. It doesn't matter if I'm using the stock 400k drive and physical disks, or a FloppyEmu in Lisa mode. The same disks lead to the same exact outcome.

So, indeed error 45 is a bus error, this happens when some device doesn't respond to the CPU in time. Question that's harder is which device. It might be the floppy controller since you've noticed issues there. 45 is also linked to the MMU as the MMU will throw bus errors if the CPU tries to access memory it hasn't mapped. Could be the adder/comparator chips or the RAM used as MMU registers or something messing with their signals or operation (dust? board corruption from an old battery leak? short? bad filter cap on the RAM used as MMU regs?)

Could also be RAM, but the RAM tests should catch that however.

I would remove all removable expansion slot cards, such as the SCSI board and trying to see if it goes away or not.
I'd clean the motherboard connector and the edge connectors on the I/O board, CPU board, and memory boards with a pink eraser, or DeOxit, etc and see if it goes away.

If you happen to have spare boards to swap out and test that might help narrow down the issue.

I/O devices can also cause error 45 in time if they're not responding as that too triggers a bus error but it will take much longer if DTACK is not signaled in time as that inserts wait states before giving up.

If your I/O board has socketted VIAs you could swap VIA 1 with VIA 2 to see if the behavior changes, but most likely you would have seen other VIA related issues if it was them.

[sigma7]

The Lisa 2 that I have on hand is one that ... I chronicled over at the TinkerDifferent forums.
...
... I wonder if the heat and activity caused some component somewhere to degrade?
...
I've *not* done a shotgun recapping of either of the modules. Caps that looked iffy, or tested out of spec, I've replaced. But it still has 90%+ factory caps.

Thanks for documenting the process of bringing your Lisa back to life; always an interesting adventure!

Running your Lisa for a long time at a normal operating temperature shouldn't cause any problems, so AFAIK that doesn't change the approach to the troubleshooting task. Maybe you're looking for something that was thermal related, but since the problem now occurs hot and cold it seems it isn't any more.

Replacing damaged and particularly old caps in the PSU is recommended, but not elsewhere typically. Since the large ones on your video board were suspect I suppose those should be on the list too. Check all the PSU output voltages if you haven't already.

If there is another Lisa owner in your neighbourhood, swapping parts about will probably help to localize the problem quickly.

Do you have any test equipment beyond a multimeter?

[AlexTheCat123]

I had a similar problem a month or so ago where the floppy controller started acting weird and the system kept giving bus errors. The problem turned out to be the 8T97 tri-state buffer at U2F on the I/O board. Looking at the I/O board schematics, that 8T97 buffers the /DTACK signal that goes back to the CPU and the absence of this repsonse from the floppy controller could definitely be causing your problem.

[dmark]

So, indeed error 45 is a bus error, this happens when some device doesn't respond to the CPU in time. Question that's harder is which device. It might be the floppy controller since you've noticed issues there. 45 is also linked to the MMU as the MMU will throw bus errors if the CPU tries to access memory it hasn't mapped. Could be the adder/comparator chips or the RAM used as MMU registers or something messing with their signals or operation (dust? board corruption from an old battery leak? short? bad filter cap on the RAM used as MMU regs?)

In what area of which board are there chips located? Are you talking about RAM on the RAM boards here, or is there RAM on other boards as well?

Could also be RAM, but the RAM tests should catch that however.

I would remove all removable expansion slot cards, such as the SCSI board and trying to see if it goes away or not.
I'd clean the motherboard connector and the edge connectors on the I/O board, CPU board, and memory boards with a pink eraser, or DeOxit, etc and see if it goes away.

Expansion slot cards are removed! Taking out the SCSI adapter card was the first thing I tried.

I've been frequently applying contact cleaner (not Deoxit brand) to all edge connectors and sockets, but I can certainly try again to rub away oxidation from the edge connectors. In particular the edge connectors that lead from the Motherboard into the front of the machine aren't in great shape.

If you happen to have spare boards to swap out and test that might help narrow down the issue.

Not at hand, but I know a local collector who has a battery damaged Lisa that he's been working on. Might try collaborating with him if I don't make headway by myself.

I/O devices can also cause error 45 in time if they're not responding as that too triggers a bus error but it will take much longer if DTACK is not signaled in time as that inserts wait states before giving up.

If your I/O board has socketted VIAs you could swap VIA 1 with VIA 2 to see if the behavior changes, but most likely you would have seen other VIA related issues if it was them.

They are indeed socketed, but switching them out did not make a difference.

Anyhow, thanks for your suggestions! This is very helpful.

[dmark]

Thanks for documenting the process of bringing your Lisa back to life; always an interesting adventure!

You're very welcome; thanks for reading it!

Running your Lisa for a long time at a normal operating temperature shouldn't cause any problems, so AFAIK that doesn't change the approach to the troubleshooting task. Maybe you're looking for something that was thermal related, but since the problem now occurs hot and cold it seems it isn't any more.

Replacing damaged and particularly old caps in the PSU is recommended, but not elsewhere typically. Since the large ones on your video board were suspect I suppose those should be on the list too. Check all the PSU output voltages if you haven't already.

I did replace the two large caps on the video board as a precaution, so that's done.

Do you have advice where good test points for each voltage rail is? I have it on my todo list to study the schematics to find out, but if you have suggestions off the top of your head that'll save me a little time.

If there is another Lisa owner in your neighbourhood, swapping parts about will probably help to localize the problem quickly.

As mentioned above, yes I do, although it is more heavily battery damaged than mine.

Do you have any test equipment beyond a multimeter?

I do have a digital scope! I was going to jump into looking at signals next...

[dmark]

I had a similar problem a month or so ago where the floppy controller started acting weird and the system kept giving bus errors. The problem turned out to be the 8T97 tri-state buffer at U2F on the I/O board. Looking at the I/O board schematics, that 8T97 buffers the /DTACK signal that goes back to the CPU and the absence of this repsonse from the floppy controller could definitely be causing your problem.

How did you narrow down the root cause? Any particular signals I should try measuring?

[AlexTheCat123]

How did you narrow down the root cause? Any particular signals I should try measuring?

I started by checking the clock and reset signals on the 6504 microprocessor that controls the floppy drive to make sure that it was being properly clocked and reset, which it was. After that checked out, I probed all of the address and data lines between the 6504, its two 444C-3 RAM chips, and the I/O board ROM to make sure that there was activity on everything and that nothing was stuck high or low. I also checked a couple of the other signals feeding into the chips, like the R/W signals on the 6504 and the chip select signals on the RAM chips. By the way, you can find all of this stuff on the upper half of page 4 of the I/O board schematics.

When all of that looked good, I moved on to the bottom half of the schematic, particularly the circuity that generates /DTACK since I knew that the 68000 needs this signal in order to finish a bus cycle and will cause a bus error if it's never received. I didn't feel like going through all of the complicated flip flop stuff in the schematic, so I started at the end of the chain, just before the 8T97, to see if /DTACK was getting that far. It was, so I guessed that the 8T97 that buffers this signal to the processor might be the problem. I happened to have a spare 8T97 lying around from another project, so I figured that it would be quicker to swap it out than it would to take a deeper dive into what /DTACK was doing after it left the tri-state buffer and headed to the processor. And sure enough, that fixed my problem!

If you happen to have a chip tester of some kind, like the Retro Chip Tester Professional or the more limited TL866 programmer, you can save some time by throwing any suspicious chips in there to see if they're working properly instead of having to order replacements to see if the originals were faulty.

So clearly there was a lot of luck involved in my repair here (especially the part where I happened to have an 8T97, which in my experience isn't a very common chip, lying around), but hopefully you'll get lucky with your issue too!

[rayarachelian]

So, indeed error 45 is a bus error, this happens when some device doesn't respond to the CPU in time. Question that's harder is which device. It might be the floppy controller since you've noticed issues there. 45 is also linked to the MMU as the MMU will throw bus errors if the CPU tries to access memory it hasn't mapped. Could be the adder/comparator chips or the RAM used as MMU registers or something messing with their signals or operation (dust? board corruption from an old battery leak? short? bad filter cap on the RAM used as MMU regs?)

In what area of which board are there chips located? Are you talking about RAM on the RAM boards here, or is there RAM on other boards as well?

They're 1Kx8 SRAMs on the CPU board.

see: https://lisaem.sunder.net/LisaSchem/CPU4.gif and https://lisaem.sunder.net/LisaSchem/CPU5.gif

They're around U8A, U9A, U10A They're the 214H8 SRAMs.

I'd also look at the adders at U8E, U9E, U10E - the F283s.

I'd also look at the latch at U4E.

[dmark]

They're 1Kx8 SRAMs on the CPU board.

see: https://lisaem.sunder.net/LisaSchem/CPU4.gif and https://lisaem.sunder.net/LisaSchem/CPU5.gif

They're around U8A, U9A, U10A They're the 214H8 SRAMs.

I'd also look at the adders at U8E, U9E, U10E - the F283s.

I'd also look at the latch at U4E.

Sorry if this is an obvious question, but how do you test the CPU board in operation? Is there something like an extender board to run the computer with the card cage outside the case?

[rayarachelian]

Sorry if this is an obvious question, but how do you test the CPU board in operation? Is there something like an extender board to run the computer with the card cage outside the case?

There's no such extender board, sorry. You might be able to create one, but the length of the wires would be an issue. You could desolder those 3 SRAMs and test them and then resolder them back with sockets?

[stepleton]

Is it possible to get into Service Mode after an Error 45? If so, could you run some programs (or just do some memory reads and writes) to check whether the MMU registers are working as expected?

[dmark]

Is it possible to get into Service Mode after an Error 45? If so, could you run some programs (or just do some memory reads and writes) to check whether the MMU registers are working as expected?

Yes, it is indeed possible to enter Service Mode from Error 45, inspect memory and run programs, run diagnostic tests etc! (TIL)
I'm not familiar with how to test the MMU registers on a Lisa, however. Do you have any pointers where I can read up on this?

[rayarachelian]

Yes, it is indeed possible to enter Service Mode from Error 45, inspect memory and run programs, run diagnostic tests etc! (TIL)
I'm not familiar with how to test the MMU registers on a Lisa, however. Do you have any pointers where I can read up on this?

I'd download a few versions of LisaTest and try those if you can boot at all. There's some way to go into the "Service Mode" advanced menu when it starts up and go into the individual tests.

Edit: looking at page 5.4 of http://bitsavers.org/pdf/apple/lisa/service/072-0085_Level_1_Lisa_Technical_Procedures_Mar85.pdf - it's the usual Apple-S to enter "Service Mode" in LisaTest as well as on the Boot ROM. D'oh! Surprised I forgot this factoid.

If you can't boot LisaTest, you could write some code to call the Boot ROM MMU routines, but that will be difficult to test unless you understand the Lisa's hardware and 68000 code. You'll need to write custom code, etc. As Tom mentions below there are a couple of routines to set/read the MMU registers.

There's also some code to do this in the ROM that you might be able to call - this might be harder if you do this with non "H" versions of the ROM as that's the only source we have for the Lisa Boot ROM, and earlier ones might not behave the same, etc.

But you'll have to play carefully with the MMU registers since any code you write will live in RAM and be invoked via service mode, and changing the MMU registers can cause that space (both the ROM routines and RAM you're writing code to) to disappear as it goes out of scope.

[stepleton]

Oh neat. Well, this would be a Project, but hopefully an interesting one.

Your first port of call is probably the Lisa Hardware Manual and its description of how the MMU works (starting on PDF page 35).

Whatever code you make would have to ensure that the MMU is in the mode that allows you to write to the MMU registers. (This may already be the case in Service Mode --- I don't really remember.) Then you would write to the memory addresses where the MMU registers are and read them back to compare. Some care may be required since changing the MMU configuration may change whether you're still able to speak to the MMU in the first place.

Now for me there is nothing better than an example, and if you're similar, you'll want to check out the Lisa Boot ROM source code and see how it talks to the MMU.

You'd have to write your own code in assembly language, assemble it into hex data, and then type it into Service Mode and execute it and see what happens. You might use some of the utility routines in the Boot ROM to print out results (see the Boot ROM manual PDF page 20 and page 28 onward), or you can just stash results in RAM somewhere and then inspect those memory locations with the Service Mode memory inspection tool.

(@Ray, it looks like LisaTest won't boot based on earlier posts... maybe still worth a shot to see if getting into individual test mode still works? I don't remember how to do it either.)