General Category > Lisa Troubleshooting and Repair
Apple Lisa 2 I/O board problem - garbage on the screen
sigma7:
--- Quote from: greniu on January 27, 2025, 09:12:52 am ---which component to check? I suspected U4E
--- End quote ---
There are many possible causes of this type of failure, so you'll need to find a more specific symptom.
What did you find surveying signals with the oscilloscope? I presume you found something that made you suspect U4E...
If you didn't find anything suspicious using the oscilloscope (which is certainly possible if we were looking in the wrong place), what procedure did you use?
greniu:
Hi, sorry I didn't reply, but I had a long break in this problem and decided to come back to it. I have Lisa in the workshop now and maybe this time I will succeed.
Back to the boot problem. As for the data lined (d0-d7), I measured them on U7C, because this is where the TONE signal is located, which transmits sound to the speaker system. I preceded each measurement by pressing the reset button. Each time Lisa booted, the value on the oscilloscope D0-D7 was 1.75v, but immediately after pressing the reset button, 2 irregular signals appeared for a moment, looking the same on each data line d0-d7 and were synchronized with 2 Lisa beeps. I suppose that this is the encoded signal of these 2 sounds, which come out of TONE. Or maybe I'm wrong?
Interestingly, on the Lisa screen during boot I get the same static image both when I have ICs (5C, 7C and 9C) inserted and without them.
Additional information is that when I have the IC (5C, 7C and 9C) pulled out and Lisa boots, the static image changes once and freezes. The first image (garbage) that appears and right after it the second one slightly shifted (also garbage).
So I have to look for the source of the problem even earlier on other ICs during boot process.
Any ideas?
sigma7:
I think the situation is still this (correct me where I'm wrong):
- with a different I/O Board installed, the Lisa works correctly
- with the problem I/O Board installed, you have the unchanging garbage screen image, and two beeps
So while the CPU board can access the memory board under normal circumstances (with the good I/O Board), with the problem I/O Board installed, the CPU Board cannot access the memory.
And, with the problem I/O Board installed, beeps are heard. This indicates the CPU Board is still running from ROM, and can access the I/O Board to generate the beeps.
So the problem is that something at the card edge of the I/O Board is interfering with a signal that the CPU uses to access memory.
--- Quote from: greniu on April 08, 2025, 01:27:38 pm ---for the data lined (d0-d7), I measured them on U7C
--- End quote ---
The data lines are one possibility. You've got the right idea by looking at the 8 data lines at U7C, but this is not quite the right place to look. The buffer at U4D isolates U7C from the card edge data lines, so at U7C you won't see if something is going wrong at the data lines connecting the CPU and memory. So re-inspect at the high side (pins 11-18) of U4D. One possible fault is that U4D is turned on all the time, so check pin 19 to confirm it is high except when the CPU needs to access U7C (to eg. beep or communicate with the mouse and keyboard).
--- Quote ---Additional information is that when I have the IC (5C, 7C and 9C) pulled out and Lisa boots, the static image changes once and freezes. The first image (garbage) that appears and right after it the second one slightly shifted (also garbage).
--- End quote ---
I think the static garbage image indicates the display is showing the semi-random data in memory that exists when the memory is powered up. Since the CPU can't access memory to clear the screen, the garbage remains. I speculate that on startup the CPU ROM initializes the video page register to something other than the random state in which it powered up, so the display switches to showing a different part of the semi-random data in memory. Since the display isn't changing otherwise, it seems the CPU Board video circuit is successfully reading the data from RAM in a consistent manner.
--- Quote ---So I have to look for the source of the problem even earlier on other ICs during boot process.
--- End quote ---
I'd phrase it more that the problem is closer electronically to the CPU and Memory boards rather than earlier in time. I'd guess the problem is present at the time of power-up, but only reported later on after the CPU had gotten a bit further into the self-test.
So looking at the schematic, you'll want to look at signals that go to J1 (the card edge connector).
greniu:
thank you very much for your quick response and helping hand. I appreciate it very much. Below are the answers and conclusions to your tips:
1.The problem appears only with the problem I/O board and beeps are heared here.
--- Quote ---
So the problem is that something at the card edge of the I/O Board is interfering with a signal that the CPU uses to access memory.
--- End quote ---
This is good path to look at.
2. I measured pins 11-18 on U4D during boot (I pressed reset each time). I see normal activity of 3.6V. Additionally, during boot I measured the value of pin 19 and it is HIGH, but at the moment of these 2 beeps I see activity and then it returns to HIGH permanently. This explains that U4D is working correctly because during these 2 beeps signals are transferred to pins2-9, which reach d0-d7 on U7C.
On the other hand, comparing the boot process on pin19 U4D on a good I/O board, I see after the HIGH signal only one activity signal then it returns to HIGH and after some (longer) time you can hear such a low boot signal (correct during the LISA boot process). So I do not see this second activity, which was related to the first activity on the problematic I/O board and additionally related high beep signals.
Looking at the diagram, pin 19 U4D is controlled by U7B and U4E. Maybe there is something wrong here?
sigma7:
--- Quote from: greniu on April 08, 2025, 03:24:25 pm ---I measured pins 11-18 on U4D during boot (I pressed reset each time). I see normal activity of 3.6V. Additionally, during boot I measured the value of pin 19 and it is HIGH, but at the moment of these 2 beeps I see activity and then it returns to HIGH permanently. This explains that U4D is working correctly because during these 2 beeps signals are transferred to pins2-9, which reach d0-d7 on U7C.
Looking at the diagram, pin 19 U4D is controlled by U7B and U4E.
--- End quote ---
I agree mostly - from your description, the signals controlling U4D appear ok. I don't think you can absolutely declare that U4D is working correctly (eg. perhaps one of it's pins is misbehaving in some circumstance), but I agree that it is not a likely suspect.
--- Quote ---comparing the boot process on pin19 U4D on a good I/O board, I see after the HIGH signal only one activity signal then it returns to HIGH and after some (longer) time you can hear such a low boot signal (correct during the LISA boot process). So I do not see this second activity, which was related to the first activity on the problematic I/O board and additionally related high beep signals.
--- End quote ---
Comparing with the good board is an excellent technique, thanks for thinking of that!
In the case of this particular problem, the self-test does not continue once it finds there is no available (accessible) memory, so with the problem board, the self-test code never gets to the point where that second activity would occur. (With other less critical problems, the self-test does continue.)
Although I think you've found that the data bus is not the issue, while we are thinking about the data bus buffers, I suggest you check the enable pin of the other data bus buffer on the I/O board - U3D-19. It should behave similarly to pin 19 of U4D, aside from the fact that when (if) it goes low, it would be to access some hardware (the PRAM or floppy disk controller) instead of the tone generator etc.
While you are at U3D, also check the READ signal on pin 1. It should be high most of the time, but go low when the CPU is writing to something (which may be RAM or I/O). While it is running the self-test from ROM, READ should remain high almost all the time.
I suspect U3D won't show anything suspicious, so I suggest then checking the address lines:
U2C, U3C, U4C at the bottom left of page 4 have pins connected to address lines A1 through A10.
A11 is connected to U4E-3, and
A12 is connected to U7B-10.
edit: corrected typo U7B-10, not A7B-10
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version