• Hello, Guest! Welcome back, and be sure to check out this post for more info about the recent service interruption and migration.

Whats the problem with this Apple Lisa 2/10?


Well-known member
I have a LISA 2/10, (H/88) that has been working good. The harddrive is dead but it has worked with the floppy drive and booting from that. Recently its not working. When I put it on the screen is white but no click, no sound , no error sound. Just a white screen. The lamp in the on button is OK. The PSU is Ok regarding +5, -5, +12 and -12 volt. +33v is not checked but as the screen is white I suppose that its OK.20230304_174941b.jpg

I have burned new EPROMs , (Intel D2764A-2) , 341-0175-H and 341-0176-H. The EPROM burner is Stager G540 which I have used before and it has been working OK. The check sum from bin file is the same as on the EPROMs. Nothing better with new ROMs. In the repair manual they suggests to put in a new CPU board, but thats not an option for me. I have reseated all chips that are mounted in sockets, including MC68000. Same result if I disconnect HD and floppy cable.


What to do next. is it time to replace the CPU or the static RAM 2148H-3? Easy to replace CPU as its mounted in a socket.

Greatful for any advice.


Well-known member
Hmm. It does seem like a logic problem.

The Lisa has many more ICs besides the 68000 and the static RAM. If you think of it as a numbers game alone, changes are that the problem is with a different chip!

So you've got a classic troubleshooting problem on your hands. The usual thing to do is to collect evidence, make a falsifiable theory, test the theory, and loop until you isolate the problem. I think we're now on the "collect evidence" phase of iteration 1. We know the PSU is good --- that's a great start.

1. Did anything happen to the Lisa between when it worked and when it didn't work? (Did you move it, for example?)

2. Get the Lisa into the state you've shown in your first photo. What exactly happens when you press the Reset button on the back?

3. What happens if you run with just one of your RAM boards --- in either slot? (If the same thing, try the other RAM board too.) (I suspect nothing will change and that your problem is probably elsewhere, but it's an easy test.)

What test equipment do you have? (Multimeter, oscilloscope, logic probe, etc.) Are you comfortable with reading schematics? I ask these things because we may need to work together to understand the problem --- the Lisa is not like the C64, where thousands of people have learned how they break and have figured out the meanings of all kinds of different observable phenomena. We still have to do all the work by ourselves --- so it's good to know what resources we can bring to bear :)

(Incidentally, I think the most important question above is #2. Depending on what you observe, we'll be able to guess whether the CPU is running at all, and if it is, how far along it's getting in the boot ROM code.)


Well-known member
This is bases in your personal story story what ChatGPT4 would advise:

It sounds like you have already done a lot of troubleshooting on your Apple LISA 2/10. Given the information provided, I can suggest a few additional steps to help diagnose and potentially fix the issue. Keep in mind that working with vintage hardware can be challenging, and there's always a risk of further damage. Proceed with caution and at your own risk.
  1. Visually inspect the motherboard and other components for any signs of damage or corrosion. Look for any swollen or leaking capacitors, burnt traces, or broken solder joints. If you find any, consider repairing or replacing the damaged components.
  2. Clean the edge connectors on the motherboard, expansion cards, and any other connectors using isopropyl alcohol and a lint-free cloth. Over time, oxidation can build up on these connectors, causing poor electrical connections.
  3. Check the continuity of the traces on the motherboard, especially around the CPU and memory sockets. A multimeter in continuity mode can be helpful in this process. If you find any broken traces, you can try repairing them with a conductive pen or soldering a jumper wire.
  4. Test the individual chips on the motherboard, especially the CPU and the static RAM (2148H-3), using a chip tester if you have access to one. If any chips are found to be faulty, replace them if possible. The MC68000 CPU is socketed, so it should be relatively easy to replace if necessary. Make sure to use proper anti-static precautions when handling these components.
  5. Re-seat all socketed chips, including the CPU and memory, and make sure they are properly aligned and making good contact with their sockets. Use caution when removing and reinserting chips, as it's easy to accidentally bend or break pins.
  6. Try powering on the system with only the essential components connected (e.g., disconnect any expansion cards, hard drive, floppy drive, etc.). If the system works with minimal components, reconnect them one by one to isolate any faulty components.
If you've exhausted these troubleshooting steps and are still experiencing issues, it may be necessary to consult a professional experienced in vintage computer repair or seek out replacement parts. Keep in mind that components for these older systems can be hard to find and may be expensive, so weigh your options accordingly.


Well-known member

Thank You both for Your comments. I have already cleaned all connectors, inspected the boards etc and didnt find anything wrong. The only thing that happended between when it worked and didnt was that I moved it from the garage to the table. I have tested without any memory board and in different combinations. Only one thing differ.
If I press the interrupt button with both memory boards connected the screen shows this picture for less than a second.
When I press the reset button, same result but after approx 2 sec.

Without any memoryboards installed this picture shows briefly

The same time delay interrupt vs reset button.
Does this vertical bars indicate that the ROMs are doing the memory test?

I have an oscilloscope but no chip tester. I will test continuity around the CPU and static RAM as You suggested. I will report later.


Well-known member
There's no harm in testing continuity anywhere on the board, but the suggestion to check around the CPU and the static RAM was basically @mactjaap 's little joke. What @mactjaap did was put your initial post into an AI chatbot, which generated a fairly generic answer that wasn't really based on any knowledge of how the Lisa works.

If you had asked whether it was time to replace the video state ROM or one of the 6522 VIAs, then the chatbot would probably have told you to check continuity around the video state ROM or the 6522 VIAs --- that's because the only thing the chatbot is doing is trying to continue your conversation in a way that sounds convincing. You mentioned the CPU and the static RAM, so the chatbot said them too so that it could sound like it was responding to what you said. Sometimes it really can work quite well, but it's not really trying to help you, and in this case I don't think it managed to do that. Thankfully the chatbot didn't give you any advice that would damage your computer --- at least, not this time.

Thanks @mactjaap , I'm extra super glad to have needed to take time out of my morning to explain that to someone 😐


Now then. One thing that actually is more helpful is the pair of pictures you shared, but I think I'll need some more description. You said "the screen shows this picture for less than a second". Does that mean that the screen shows an all-white rectangle for less than a second? (It looks like an all-white screen to me.) What happens next?

The second photo is interesting too in its difference to the first one. Taking a picture of a very brief screen image is difficult, and it looks like you've managed to snap a photo right as the pattern was disappearing from the screen. I'm guessing that ordinarily the screen image is much more well-defined than that? What happens after that?

Is there a way for you to take a video of what happens when you press the Reset button? We'll want a few seconds before and after.


It's encouraging to hear that you have an oscilloscope. You must have a multimeter too, since you could check the power supply voltages. That's good.

Here is the strategy that I think we should execute.

FIRST: Find out if the Lisa is executing code in its boot ROM. Based on your pictures, I think it might be, but I'm not certain. If it is, proceed to the next step.

NEXT: Familiarise yourself with the boot ROM source code. Compare what the Lisa is doing with the initialisation steps in the source code. The instant that the Lisa's behaviour looks different (in some way) from what the source code describes --- that's probably a good clue that narrows down where the problem is.

The start of the executable code in the boot ROM is at the symbol BEGIN (do a search for the string "no reset check"). Now, as an example of this strategy, you'll notice that a little further down, the Lisa changes the contrast of screen in some circumstances. That's a behaviour that we ought to be able to observe --- in your broken Lisa and in my working machine. If your Lisa never changes the screen contrast, then we know that the problem is in a subsystem that the Lisa interacts with before that part of the code. From my read of things, that would probably point to trouble with the MMU.


Anyway, we are still on the FIRST step above; we need to verify that your Lisa is executing code in the boot ROM. Unfortunately, it's pretty hard to get your oscilloscope onto the CPU to check its clock or any of the address or data lines with your oscilloscope. We'll have to check those things indirectly. Let's start with the clock: the "easiest" way to check is probably to probe pin 8 of the expansion slot connector, which at least is not so deep into the machine. (See PDF page 77 of https://lisa.sunder.net/LisaHardwareManual1983.pdf for expansion slot connector pinouts.) Can you use your oscilloscope to verify that you have a clock signal there? If we don't have a clock, then of course that's a big problem.
Last edited:


Well-known member
I’m sorry that I didn't gave you a good start of the day. That was not my intention. My apologizes.

My case was to show what a AI model (ChatGPT 4, out this week) would say about this problem. And yes, also to give these questions we are asking ourselves a little ‘modern’ approach. You are right that the answers are generic, but the are also not totally out of order. Would be nice if AI could help us in the future.

But let’s not debate in this thread what the benefit or drawback of AI is in repairing vintage hardware or in general. What we both want is to help our fellow forum member to fix his problem.


Well-known member
Anyway, we are still on the FIRST step above; we need to verify that your Lisa is executing code in the boot ROM.

OK, that explains all the words without any specific help.

The CPU clock signal is present at pin 8 at the expansion board socket
KrbRoOl - Imgur.jpg

Below is two videos of when I press the reset button three times. LISA is powered on for one min and then reset is pressed.

First is when all bords are mounted,

second ( with vertical bars) is when both RAM boards are removed.


You can see in slow motion for details.

Is that of any help for further testing?


Well-known member
OK, that explains all the words without any specific help.

I am not writing all of this stuff because I love to type! I'm writing it for you.

If we are going to solve this problem together, then I think you'll need to play an active role as part of our troubleshooting team. It's not going to work if I'm just giving you instructions from far away --- that will take forever as we go back and forth. Just like me, you'll need to come up with theories of the problem too, and do experiments and look for clues to see if they are correct. Remember, we don't have a low-level troubleshooting guide for Lisas like the Dead Mac Scrolls for Macs or the millions of online resources for C64s. We have to figure it all out for ourselves.

I'm writing lots of text so that we can start to work together in this way.

Here are some useful references that we will probably refer to a lot in order to come up with troubleshooting steps:

It's great news that you have a clock: your oscilloscope shows it spot-on at 5 MHz. So that's not the problem. But you need more than just a clock to find out if the Lisa is executing the boot ROMs. Your videos suggest to me that if it is, it isn't getting very far. Here's a video of what happens if I press the Reset button on my Lisa 2/10:

As you can see, one of the first things the Lisa does is turn the screen contrast right down. Based on your videos, your machine is not doing this. If it were, that would be a good hint that it's running boot ROM code.


So we still need to find out if your Lisa is executing the boot ROM. You have a good clock, so that requirement is taken care of. Great!

But in the spirit of us working on this together, I want to ask first instead of telling: what else do you think we should check to see whether the 68000 is trying to execute any code at all, and to find out if it's trying to access and execute code from the boot ROM in particular?


Well-known member
Sorry stepleton. I apologize if I sounded rude. That was not my intention. I really appreciate your help and efforts to help me with this problem.

I have read in Larry Pinas : Macintosh , Repare and Upgrade Secrets. (https://vintageapple.org/macbooks/pdf/Macintosh_Repair_&_Upgrade_Secrets_1990.pdf) There is a chapter about Lisa. On p 249 he writes about the MMU register test. The picture regarding RAM failure looks like the brief picture in my LISA.

When I tested the LISA a year ago I got this picture before testing memory and I/O board
Now its stopping before that. Now its not trying to read from the floppy.
I dont get any error code.
The Apple Lisa boot ROM source code is really complicated and I don't know how to interpret it. I have looked in the Lisa hardware manual but not found any obvious solution of the problem.

As You know I have made new ROMs. I will see if I can find the check sum and compare with my new ROMs. I will test if the ROMs get 5 V.
One easy thing is to put in a new MC68000, its easy to find and not expensive. Unclear if that will help.

I will report later.
Once again thanks for all Your help and I apologize for being rude.


Well-known member
No worries. I am glad that you are up for this challenge!

As for your documentation finding, that's very interesting --- and I stand corrected about not having any written low-level diagnostic material! I think this MMU register issue sounds like a very plausible theory to me. I expect that we'll look into it soon.


The ROM source code is complicated! I studied it for a while, years ago, and this was actually one of my earliest introductions to 68000 assembly programming. It is possible to get something out of it even without being used to thinking about assembly, although it isn't easy! The comments on every line tell a story of what the Lisa is doing as it boots, but of course unlike a regular story, a computer program can Branch and Jump. Look for instructions that start with B, like BRA, BSR, BNE, BLE etc --- most B instructions are (sometimes conditional, i.e. they may or may not happen) jumps to other parts of the code, and comments nearby can give clues as to when the jumps are taken. The same is true with most J instructions (JSR, JMP, JLT, etc.). If you see "BRA FOOBAR", then you can search for "FOOBAR" to eventually find the code at the other end of that branch. (You can ignore suffixes like .S in BRA.S.)

I've been a bit grouchy about ChatGPT and other chatbots here already, but I wonder if it may actually have potential here as an understanding tool for this code. You might give it a try: write a bit of a header that says something like "this is part of the boot ROM for an old computer that uses the 68000 processor, and this bit in particular is for <whatever>". Then paste the code that you're interested in after that, and then as the last line: "Can you explain how this code works in ordinary language?" It might lie to you and make something up, but it might also be able to explain a lot! You never know with chatbots :)

If you look in the neighbourhood of START in the ROM, you can see that routines called ROMTST (check the ROM) and MMUTST (check the MMU) come not far after. Now, START might branch somewhere else before ROMTST and MMUTST, but maybe it's safe for us troubleshooters to just guess that those two tests are being attempted early on. We can see that ROMTST has a part that says "BNE SPIN" with the comment "loop if error", and if you look a bit above START, you can find SPIN. Here's all of SPIN:

SPIN    BRA.S   SPIN            ;hang system

Based on what I've told you above, you should be able to understand exactly what this very small piece of 68000 assembly does! If you keep reading, you'll find that you start to understand more and more of what you see, bit by bit.


The tests you suggest are reasonable clues for seeing whether the CPU is executing ROM code. But you might also consider looking for evidence of this in the Lisa directly, using your oscilloscope, which you can do for free. Unfortunately, the layout of the Lisa makes this a bit difficult!

When it reads the ROM, the 68000 CPU will need to emit ROM addresses on its address pins, and it will need to receive ROM data on its data pins. You can use your scope to eavesdrop on this conversation. We don't need to know that it's working well just yet --- we mainly want to see that it's happening at all.

What you want to do is get a pin-out for the 68000. If the 68000 is executing code, the following things should be true:

The \RESET pin should be at +5V --- otherwise, the CPU resets if this line is 0V
\HALT should also be +5V --- the CPU halts if this line is 0V
(Note that the \, or a ____ over the word, means that 0V means "on" for that signal.)
CLK should be the clock signal you observed already.

Many of the A lines, especially the lower-numbered ones like A1, should be wiggling. That's the processor indicating the address for data it wants to retrieve from RAM or ROM.

Many of the D lines should also be wiggling. That's the processor either receiving or sending out data.

If we see this, we can be reasonably certain that we're running ROM code. (There's really no other code to run!) But if you want to be even more certain, get pinouts for the ROM chips and check that they are receiving addresses and transmitting data. You'll want to check other signals on the ROM to verify that the ROM is actually enabled --- usually a line called CE or \CE (for "chip enable"). If you see that, then it's really very likely that the CPU works fine and that it's able to talk to the ROM.


Of course, as mentioned, the Lisa does not make it easy to probe like this: the CPU board is buried in the computer behind the I/O board. But maybe that's not a problem for us right now. You can see from reading START, ROMTST, and MMUTST that all of these very early tests are for systems that are on the CPU board.

I've never done this before, but I think you might want to try running your Lisa without its I/O board, since it's not needed for these early tests. Your Lisa will still be as broken as before (or else I'll be surprised), but I think it will remain broken in the same way. With the I/O board out, you'll be able to see the back of the CPU board, and you'll be able to touch CPU and ROM pins with your oscilloscope probe that way. Just remember that the pinout will be reversed from what you see in diagrams, since you'll be orientated "underneath" the chips!

So I recommend checking the pins mentioned above. If we see things behaving as I described, then we'll move on to trying to find out where the Lisa is encountering failures in attempting to execute the boot ROM.
Last edited:


Well-known member
So I recommend checking the pins mentioned above. If we see things behaving as I described, then we'll move on to trying to find out where the Lisa is encountering failures in attempting to execute the boot ROM.
Thank You for suggestions how to proceed with this LISA 2. This is definitely above my level regarding retrocomputing and programming. I will take out the I/O board and do the tests next week and report.


Well-known member
A plan could also be to swap boards with a fellow Lisa 2/10 owner. Then you can test if your boards are good. I’m not sure how many Lisa’s there are in Stockholm, but it is worth a try.
I live near Amsterdam, The Netherlands… so if you ever visit The Netherlands you could bring your boards and widget so we can test.


Well-known member
Not a bad idea. If you know someone with a Lisa of any kind, the CPU and memory boards should basically be interchangeable. It's only the motherboard and I/O board that are substantially different, and where you will need to find someone with another 2/10.

I think though that the problem is very likely to be on the CPU board.

Unfortunately, I've been very silly in my advice and forgot something really critical. Without the I/O board, I don't think the Lisa can turn on at all! 🤦‍♂️
What a total goof!

I think you might be able to force the Lisa to turn on without an I/O board. What you'd have to do is connect the +5 STBY standby power line (pin 82 on the I/O board connector) to the ON signal line (pin 120 on the I/O board connector). If I were going to do this, I would connect these pins through a resistor, maybe 1K ohm, just to be on the safe side.

But that feels pretty sketchy. While @BEU thinks of another way to probe those pins on the CPU board, I will ask folks over on LisaList2 about running the computer with no I/O board. The real experts over there will have a clearer idea of whether it can be done safely.


Well-known member
Unfortunately, I've been very silly in my advice and forgot something really critical. Without the I/O board, I don't think the Lisa can turn on at all! 🤦‍♂️
What a total goof!
In fact it's the exact opposite! If you power the Lisa without an IO board installed she will immediately power up, and if all else is OK will display a 41 CPU card error.


Well-known member
Ah, well that's great news. It sounds like the probing plan is back on track!

Also for @BEU : An update to probing the ROMs. In the Lisa, a look at the schematics (PDF page 3 of http://www.bitsavers.org/pdf/apple/lisa/hardware/050-4009-F_CPU.pdf) shows that the ROM chips not only have a \CE (which is tied to ground, so the chip is always enabled in the Lisa) but also an OE line (for "output enable"). This is another line that controls whether the ROMs are sending data to the CPU.


So it's pin 22 of the ROMs (along with the data and address lines, UDx and UAx) that we can to probe to see if the ROMs are active and being read.


Well-known member
Looking further ahead, here is a kind of plan we might undertake. There may be simpler ideas, of course!

I suspect that the problem we're dealing with is in the Lisa's MMU, which as Larry Pina notes is what uses the static RAM that we've been worried about. If we find that the Lisa is executing ROM code, then I think the MMU is the prime suspect.

The MMU is made out of several components in addition to the static RAM. A failure of almost any of them could cause trouble like what we're seeing. So, a good first thing to do is just to probe around the various MMU chips and see if any signals look strange --- not jumping crisply between 0V and +5V, showing intermediate voltages, and so on. That kind of thing is suspicious and might help us narrow down broken parts.


If that doesn't work, it's handy that you have a way of burning ROMs. What we might try doing is temporarily replacing your boot ROMs with our own diagnostic code.

A broken MMU is a tricky problem since the 68000 uses memory-mapped I/O. That means that when it wants to talk to any peripheral, including ones that might be useful to us (like the screen, or the speaker for making beeps), it does this by doing actions that look just like reading and writing from memory. And in the Lisa, just about everything that looks like a memory access has to be steered to where it's going by the MMU:


(From PDF page 27 of the hardware manual)

Without a working MMU, the 68000 can be a bit like a hypothetical brain in a jar: it thinks but it can't talk to anybody. So how can we do any kind of diagnostics if the 68000 can't tell us what's wrong?

In the worst case, if we can't access the speaker or the video memory, then perhaps we can just toggle address or data pins on the 68000 in a way that makes a distinct pattern on your oscilloscope. It's a very limited kind of communication. But it could be better than nothing!


Well-known member
Hi, its amazing how much knowledge is accumulated in this forum. Thank You all.
In fact I tried yesterday to take out the I/O board and start it. RAM boards , KB, mouse and floppy drive connected.
As lisa2 said its starting direct. Power lamp is on and the screen looks a little different. Most often a scrolling image like in this video. As You see its blinking.

Sometimes a steady picture like this.


I have tried with different ROM chips , 341-0175-h and 341-0176-H with the same result. Burned to EPROMs from different sites.

Floppy drive not working. can it be a problem with the video board?
I have connected an external monitor to the videoconnector on the rear side but no picture on that.
Last edited:


Well-known member
Your video board appears to me to be in great shape: it's drawing a nice, crisp display for you. It's just that the video data that it's getting from the CPU board is nonsense. The nature of the nonsense (and the reason it's different all the time) is because it all depends on whatever uninitialised data is present in memory and latch ICs right after the Lisa turns on or resets.

The blinking you see is from the beam being on (or off) during the vertical sync and the early part of the raster. This is something that can happen on the Lisa, and it's just indicative of the same thing as before: the video board getting nonsense data from the CPU board.

I still think the problem is likely to be on the CPU board. Your experiment proves that we can probe it with the I/O board removed. I'd disconnect all the drives, the keyboard, and the mouse (it's OK to leave the RAM installed) and try the probing steps we've discussed.

(Also: the signal coming out of the display connector at the back is nonstandard. Virtually no monitors support it.)


Well-known member
If I see the movie I think about my own experience with an Apple IIc monitor. I decided to make a short video.

Although you do not have a correct screen you can see something. This could be useful for debugging video problems. I my case you see the white and grey areas on the screen and the reaction on <Apple 2>.

Here is the link: