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:
Code:
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.