Print

[fri0701]

Hi all,
I'm working to fix a CPU board of mine that's been broken for quite some time. I'm wondering if anyone has any thoughts.
The power button works and the light comes on. The screen is all white, with no beeps or clicks.
(it sounds very similar to this issue: https://68kmla.org/bb/index.php?threads/whats-the-problem-with-this-apple-lisa-2-10.43757/)

However, after probing around with my oscilloscope, it's a bit different than the linked issue.

I have a clock signal that looks fine, but the CPU seems to be doing... nothing. /RESET and /HALT are both high, the clock is on the clock pin, and the only other changing output is pin E of the CPU at ~0.5MHz, which seems expected after reading through the data sheet. There is no activity on any of the pins of the SRAMs - some are high, some are low, but none change.

I can confirm that all other boards in this Lisa work - I'm just swapping in the dead CPU card.

Any ideas would be appreciated! I unfortunately only have a few more days with access to this machine for a while, so I'm trying to get as much testing in as I can.

[patrick]

Check or replace the electrolytic capacitor next to the 68000. This is a common failure. It gets leaky and the Reset is not generated properly.

[fri0701]

Check or replace the electrolytic capacitor next to the 68000. This is a common failure. It gets leaky and the Reset is not generated properly.

I’ve tested (and replaced) that capacitor with no change. The reset line seems to stay low, then jump high as expected when I turn the system on.

[sigma7]

What is the activity on pin 6 "/AS" after you push reset?

This goes low at the start of a bus cycle, and then the 68K would wait forever for a response from the hardware via /DTACK (pin 10) or /VPA (pin 21).

Rather than hanging forever, the CPU Board hardware will time-out the bus cycle with /BERR (pin 22) and if there is a double bus fault, the CPU will halt. See Troubleshooting Bus Errors

Any activity on those signals after reset?

Good luck!

[fri0701]

What is the activity on pin 6 "/AS" after you push reset?

This goes low at the start of a bus cycle, and then the 68K would wait forever for a response from the hardware via /DTACK (pin 10) or /VPA (pin 21).

Rather than hanging forever, the CPU Board hardware will time-out the bus cycle with /BERR (pin 22) and if there is a double bus fault, the CPU will halt. See Troubleshooting Bus Errors

Any activity on those signals after reset?

Good luck!

/AS goes high momentarily when I push RESET, then goes low again shortly after.
/DTACK and /VPA are both high, regardless of the RESET button.

[sigma7]

/AS goes high momentarily when I push RESET, then goes low again shortly after.
/DTACK and /VPA are both high, regardless of the RESET button.

Since /AS goes low, the 68K is attempting to do a bus cycle.

If /DTACK and /VPA are never asserted (ie. stuck high), then no bus cycle is being completed after reset.

Ordinarily this should trigger a bus error, by the 556 timer driving /BUST low and that propagating through U3B to drive /BERR low.

Also ordinarily, the initial bus cycles should always proceed normally as the reset vector and code are fetched from ROM, but that's a rather more complicated process so the fact that /BERR isn't being asserted may be a quicker route to locate the problem.

See if /BERR on pin 9 of U3B is stuck high after reset.

If so, look at what happens at U3B after reset ...
- confirm there is a clock signal on pin 12
- confirm that /AS is making it to pin 15
- confirm pin 13 is pulled high
- confirm pin 14 is not stuck
- confirm pin 11 (/BUST) is high, then goes low

If U3B-9 is not stuck high, then see if it is getting to pin 22 of the 68K. If pin 22 is going low and the 68K is still not giving up on the bus cycle by de-asserting AS, then I'd guess the 68k is broken.

If /BERR is being asserted but not getting to pin 22 of the 68K, check if the 68K is making good contact in the socket. eg. clean the pins, or perhaps tweak the pins slightly to change the contact point/pressure.

HTH

[fri0701]

Progress!

I checked, and yes, /BERR was stuck high. After tracing back the signal, I saw that the /AS signal was not making it through the buffer at U8C (LS244). I replaced it, and I'm now getting a rolling picture (with no clicks or beeps, again): https://u.pcloud.link/publink/show?code=XZ6mCk0ZVD0VAsR7MSJDScWNDy6OhhkwhXIX

The CPU seems to be doing something now, at least!

I'll have to read over the 68kmla link I mentioned at the start of this post, since it now looks even more similar... but until then, any further things I should check?

(Thanks for all your help so far!)

[sigma7]

Progress!
/AS signal was not making it through the buffer at U8C (LS244). I replaced it, and I'm now getting a rolling picture

Progress is great!

The 68k isn't directly involved with moving video data from RAM to the screen, so the fact that there is now a semi-random video image does not confirm the 68k is running properly or at all. eg. you can remove the 68k and still get an image.

After locating and fixing a major fault, you often need to go back to the beginning at looking for the problem; so check to see what /AS, Reset, Halt, /BERR are doing after reset.

If /AS cycles continuously after reset, then Halt and Reset are probably working.

If /BERR is also cycling then I suggest using the technique in the Troubleshooting Bus Errors thread to disable the bus timeout: Once BUST is disabled, the 68k will wait forever for the problematic bus cycle to complete, so you can probe all of the address lines to see what address it is trying to access, and also trace through the downstream logic to see which part of the circuitry that is supposed to respond to that address is not working. In this particular case you want to follow the logic path that should assert /DTACK (or /VPA in similar cases), so you might skip over the complexities of the MMU once you confirm that the ROM is being selected.

If /AS cycles a couple of times then stops, then I'd guess you've got a double bus fault; proceed as in the previous paragraph to figure out what is not working to cause the first bus error.

If /AS is cycling and /BERR stays high, then you'll need to poke around for some more clues. Are /UDS and /LDS also active? Is the ROM being enabled? Are all 16 data lines active? Any interrupt signals active?

The 74LS244 is generally a pretty durable part, so the fact that it failed might (or might not) indicate the CPU board encountered a substantially traumatic event. The more susceptible parts are the EPROMs and the SRAM, so try swapping them with known good parts (some Lisa CPU boards have the SRAM in sockets, on some others they are soldered in).

[sigma7]

... now getting a rolling picture (with no clicks or beeps, again): https://u.pcloud.link/publink/show?code=XZ6mCk0ZVD0VAsR7MSJDScWNDy6OhhkwhXIX

The phrase "rolling picture" often means the video board's vertical sync needs adjustment, but in this case it looks (to me) like the sync is correct and the pixel data is changing to make the video appear to be moving, which is not the way a broken CPU board typically displays symptoms as usually there is nothing happening to change the pixel data.

Another detail of this movie is that the retrace lines blink on and off, which is another symptom that seems uncommon or even unheard of.

Retrace lines sometimes appear due to a software crash or non-running CPU, but they don't blink. Whether the retrace lines are white or black depends on the data just after the end of the regular pixels in the video page of memory. ie. the CPU normally writes some black pixels after the screen pixels in the video page, making the retrace lines black. If a software crash writes white pixels into that area, then the retrace lines show up. Similarly, if the CPU board is not working, the random data in the RAM may result in white pixels in those memory locations, making the retrace lines appear.

Since it seems the CPU isn't changing the data in the video page, I speculate that the reason the retrace lines are blinking and the pattern changing is due to the video not being pulled from a consistent location in RAM. One way this could happen is if the counters that load the video data for output to the screen are not being reset back to the beginning of the page when the raster scan comes to the end.

You can test this theory by examining the "clear" input to the video address counters eg. U6F-2. If this is stuck then the counters aren't resetting to the beginning of the page/screen when they should.

If it is stuck, the cause could be the main CPU timing logic and/or the video state machine. Since the CPU isn't working properly, I'd guess the former, but it could be both.

To confirm the CPU timing logic is part of the problem, check to see if U4A-4 (aka CMUX) is active.
To confirm the video state machine is part of the problem, check to see if U4A-5 is active.

If U4A-4 is stuck, then the logic on page 2 of the CPU schematic needs investigation.

Since there is a working CPU clock, that suggests U1C is working. The outputs of U1C control U1D.

U1D's outputs function as a free-running sequence from /T0 to /T7, each being active for half of a CPU clock cycle. I suspect these are arranged to match Motorola's "S" states of a 68k bus cycle. ie. a 68k bus cycle with no wait states will progress from S0 to S7, each being half a clock cycle. (See the MC68000 User Manual for technical details.)

In the Lisa, these "T" states control the timing of interleaving video and 68k access to RAM, along with finer details such as controlling the timing of row and column addresses for the RAM boards.

So if U1D's outputs are not operating properly, the 68k won't run, as well as causing the video problem theorized above.

Hence, check all 8 outputs of U1D are active, and if working, check the flip-flops on page 2 and identify the ones that appear to be stuck.

[fri0701]

Thanks for this detailed writeup! I took another look at things, and here's what I discovered.
First of all, for whatever reason, the screen seems to have changed somewhat since the last time I powered on this Lisa. Now the raster lines don't blink, and what I get is a rhythmic cascading of dots down the screen. I can share another video if that helps.

The counters U1C, U6F, and U5E are both counting and output as expected.

U4A-4 and U4A-5 are both active.

U1D seems to be working; all outputs are active at ~2.5MHz (half a clock cycle) as you described.

I checked the flip-flops at U3C, U2B, U3B, and U4B. None of the Q - /Q outputs seem to be stuck, and they work as I expect.

[sigma7]

If the timing logic looks to be working properly, then we're headed back to square 1 to investigate what is currently happening.

Suggestions:

After you press reset, does /BERR do any cycling?

If /BERR cycles:

• does it continue cycling perpetually, or stop until reset again?
• (and) disable the bus timeout and probe the 68k address lines to find out what address is causing the first bus error after reset.
  

If /BERR doesn't cycle, does /AS cycle perpetually?

If /AS cycles:

• check that the EPROM output enables are cycling (U13D-22 and U14D-22)
• check /DTACK is cycling
  

If /AS does not cycle, check /RESET, /HALT, /BR, /BERR at the 68k.

edit for future cases: also check CLK at the 68K is about 5 MHz, as without a running clock, nothing is likely to work.