General Category > Lisa Troubleshooting and Repair

CPU Board Debugging - White Screen

<< < (2/3) > >>

sigma7:

--- Quote from: fri0701 on January 01, 2024, 04:10:12 pm ---/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.

--- End quote ---
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:

--- Quote from: fri0701 on January 01, 2024, 09:04:20 pm ---Progress!
/AS signal was not making it through the buffer at U8C (LS244). I replaced it, and I'm now getting a rolling picture

--- End quote ---

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:

--- Quote from: fri0701 on January 01, 2024, 09:04:20 pm ---... now getting a rolling picture (with no clicks or beeps, again): https://u.pcloud.link/publink/show?code=XZ6mCk0ZVD0VAsR7MSJDScWNDy6OhhkwhXIX

--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page