Print

[greniu]

Dear all,
I am restoring my old Apple Lisa 2/5 I/O board. I have a problem that I cannot get a correct boot image after turning on the Lisa but instead the screen displays garbage. During the turn on Lisa one beep appears (sometimes two short beeps). The board worked correctly before. I have a second good I/O board and after inserting it into the same Lisa there are no problems. So the issue is definitely somewhere in I/O board. Maybe someone knows this problem and knows hints where I should start with measurements on the oscilloscope?
Screen from boot process below. Thanks

[sigma7]

... the screen displays garbage. During the turn on Lisa one beep appears (sometimes two short beeps).
I have a second good I/O board and after inserting it into the same Lisa there are no problems. So the issue is definitely somewhere in I/O board.

Since it works with a different I/O Board, I agree the CPU and RAM are (probably) ok.

Since the board used to work, progressing corrosion damage may be a likely suspect, so a visual examination of the area where the battery used to be, down towards the card edge may reveal something.

IIRC, one beep means the CPU didn't find any RAM, which, if caused by the I/O board, suggests a bus contention issue. I imagine there are quite a few possible causes, so another Lisa with similar symptoms might have different causes.

A clue is that the CPU can control the I/O board enough to generate a beep, which suggests the address and data bus are at least partially working for writing data.

The video circuitry reads the screen directly from RAM, so in cases where the 68k CPU is not running but the address and data bus are working, the screen can have a steady but random image. In your case, is the screen image changing/moving, or is it steady with one random image?

If it is changing, then the I/O board would appear to be interfering with reading RAM in general, but if the screen is static, then the I/O board may be interfering only with 68k access to RAM.

It is useful to know you have an oscilloscope:

As a first suggestion, I would set the scope to trigger on the falling edge of /AS (Pin 3 of U8A) with a time scale that permits viewing through to the following rising edge, then probe the signals on the I/O board that connect to the CPU board, looking for signs of contention (signals that are between 0.8 V and 2.0 V for more than a moment) while /AS is low, or any that are permanently stuck high or low.

Signals to check:

 Data lines
 Address lines
 UDS
 LDS
 DTACK
 VPA
 READ
 INTIO

Hopefully a further clue will appear, or perhaps someone else has some more specific advice?

HTH & good luck!

[greniu]

It is useful to know you have an oscilloscope:

As a first suggestion, I would set the scope to trigger on the falling edge of /AS (Pin 3 of U8A) with a time scale that permits viewing through to the following rising edge, then probe the signals on the I/O board that connect to the CPU board, looking for signs of contention (signals that are between 0.8 V and 2.0 V for more than a moment) while /AS is low, or any that are permanently stuck high or low.

Signals to check:

 Data lines
 Address lines
 UDS
 LDS
 DTACK
 VPA
 READ
 INTIO

Hopefully a further clue will appear, or perhaps someone else has some more specific advice?

HTH & good luck!

Hi, Thank you for advices. The image is random and always static. I have two beeps soon after I power Lisa on. I/O board interfering only with 68k access to RAM sounds a good path to check.

[sigma7]

... I/O board interfering only with 68k access to RAM sounds a good path to check.

I forgot to mention that for some conditions, you need to press reset each time you probe a new signal to reproduce the problem.

Once the CPU decides there is a hardware problem it may loop in ROM doing nothing, or it may enter a troubleshooting loop where it repeats the operation that is failing.

In this case, the contention problem may be brief before you hear the beep(s), or it may continue after that (depending on the cause).

In the 2.48 Boot ROM listing, there is a loop at $0666 which (after detecting a memory error) repeats writing $A55A to one RAM address then reading it back. If the conditions are right, this will continuously repeat the problem reading/writing RAM, but I can imagine failure modes where it would not (requiring a reset each time you wish to reproduce the problem).

[greniu]

thank you. Any idea which component to check? I suspected U4E, but I test it on IC tester and it is ok. The image is static and I get 2 beeps very quickly soon after  power on.

[sigma7]

which component to check? I suspected U4E

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.

for the data lined (d0-d7), I measured them on U7C

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).

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).

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.

So I have to look for the source of the problem even earlier on other ICs during boot process.

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.

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.

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]

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.

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.

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.

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

[sigma7]

Since this is a 1/5 or 2/5 I/O Board, then I suppose it used to have NiCd batteries. If so, there is a good chance they leaked and the board has or had corrosion damage, and then probably some repairs.

So I wonder, does this board have any jumper wires that were installed to repair corrosion damage?

If so, perhaps one is misconnected. Hence this suggestion:

Check the bad board for any jumper wires that do not exist on the good board, and for each of those: check continuity on the good board between the same two points where the jumper wire is connected on the bad board. You may find that there is a jumper connected between two points that should not be connected.

[greniu]

yes, the board (from Lisa 2/5) had corrosion earlier due to battery leakage but I checked that it only has one jumper wire, which is connected correctly. I also measured the continuity on the pins on the card edge and did not notice anything suspicious. The big mystery to me is its behavior.

[greniu]

hi,

I repaired the board. The fault was in the IC U10D(LS09). Pin 3(/VPA) had static 0 value, but should have 1 (and small activity at the power on). Thank you for your help and tips.

[sigma7]

I repaired the board

That's wonderful news, congratulations, and good work!