Thank You mactjaap for that video. The videomonitor I use is an old Samsung LCD with a analog connection. Is working with the Apple II Europlus and my Apple IIc. see picture
Its not working with Lisa. But if I connect the IIc monitor to Lisa I get this picture and video
Rather strange but I suppose that is evidence that the video board in the Lisa is OK. Exactly as You wrote before stepleton.
I will continue to measure the pins on MC68000.
Thanks for making all of these measurements! I think we may have made an important discovery.
From the looks of things, something seems to me to be reading the ROM. That's great news, but: the \RESET pulses seem odd! But there's a chance that they could have a valuable explanation... keep reading. For now: you are measuring this \RESET behaviour at the CPU? Let's do a few more checks.
0. I/O board is removed, right? (So that can't be the problem!)
1. Now, let's verify: 68000 pin 18 is \RESET, it should be three pins down from CLK. (I don't doubt you --- it's just always good to double-check!)
2. \RESET also turns up on pin 7 of an expansion slot connector (just across from CLK): do you see the same thing there?
3. Please measure pins 1, 2, 3, and 4 of U12E, a 7417 open-collector buffer.
We would expect pin 1 to stay high and pins 2, 3, and 4 to show the same pulsing, along with pin 7 of the expansion connector. If we see this, we feel that U12E is at least behaving in a way we would expect, so that should be good to confirm.
If we do confirm this, then we would tend to assume that the \RESET is happening because the 68000 is executing RESET instructions --- as I read the schematics (look at the \HALT and \RESET circuitry wrapping around the top of the CPU), that's the only way for \RESET to assert without \HALT asserting too. So, where does the 68000 execute RESET instructions? I think we have an extremely interesting clue in the boot ROM:
Code:
01D8| ;----------------------------------------------------------------------------
01D8| ; The following code is used to toggle every address and data line
01D8| ; going to the MMU if an error in the MMU context 0 tests is found.
01D8| ; Reset signals indicate read/write or addressing error.
01D8| ;----------------------------------------------------------------------------
01D8|
01D8| 4A47 MMUERR TST D7 ;check error type
01DA| 6702 BEQ.S @2
01DC| 4E70 RESET ;two reset signals for address error
01DE| 4E70 @2 RESET ;only one for R/W error
01E0|
01E0| ; Toggle every data and address bit
01E0|
01E0| 207C 0002 8000 MMULP MOVE.L #$00028000,A0 ;set MMU limit reg start address
01E6| 7201 MOVEQ #1,D1 ;and starting data pattern
01E8| 7407 MOVEQ #7,D2 ;and loop count
01EA| BSRS4 TSTLOOP ;go toggle for limit regs
01EA| 49FA 0004 # LEA @1,A4
01EE| 6010 # BRA.S TSTLOOP
01F0| #@1
01F0| 207C 0002 8008 MOVE.L #$00028008,A0 ;set MMU base reg start address
01F6| 7405 MOVEQ #5,D2 ;and loop count
01F8| BSRS4 TSTLOOP ;go test base regs
01F8| 49FA 0004 # LEA @1,A4
01FC| 6002 # BRA.S TSTLOOP
01FE| #@1
01FE|
01FE| 60D8 BRA.S MMUERR ;and loop indefinitely
Check it out! The Apple engineers have used a very similar kind of tactic to what I was talking about earlier: they're using RESET instructions as a way for the brain-in-a-jar 68000 to communicate about problems with the MMU. Not only that, but when a problem is detected, the RESETs loop over and over, which could potentially make pulses just like the ones you're seeing in your probing.
The comment about how you'd see one RESET for one kind of error vs. two RESETs for two kinds of error are useful! Since your probing shows what looks to me like a repetition of a single pulse, my bet is that you have a R/W error on your hands. Bad SRAMs in the MMU are one possibility for what could be going on.
So: let's double-check the \RESET pulsing just to be sure. If things look the way we expect (see above), then I think we're pretty sure about where the RESETs are happening and why, and the next thing to do is to pinpoint where the MMU problem is. Maybe further study of how the TSTLOOP routine in the boot ROM works (it's pretty small, just 11 instructions --- give it a read and see what you think!) would help us come up with strategies for figuring out more precisely where the trouble is!
I couldn't resist studying the code just a bit more.
TSTLOOP and MMUERR are dead-end routines. If the CPU winds up executing that code, there's actually no more testing being done: it's already decided that the MMU is in bad shape.
What it's doing is bouncing on \RESET so that you (the troubleshooter) notice. It's also iterating through setting individual bits in the MMU SRAM (called "registers" in the code) and reading them back. I think it's pretty likely that the reason it's doing this is so that people like us can go in with probes (ideally a logic analyser if we had one) and find bad bits.
-----
It may be useful for you to get more familiar with the MMU, which is a device that routes the 68000's attempts to access memory (and memory-mapped devices) to different physical parts of the computer. In order to determine how to do that, the MMU must be programmed with tables that say how this routing should behave --- that's because the routing is configurable and can change as the Lisa's OS software requires. Those tables are what are stored in the MMU registers --- the SRAM chips on the CPU board.
To learn more, read PDF pages 35-45 of the Lisa Hardware Manual (1983). There's a lot of information in there, but the part that we care about the most right now is how the CPU talks to the MMU registers. Learn about the ways the CPU can read and write to those registers, since that's what's (probably) failing here. The addresses that the CPU has to use to refer to those registers are particularly interesting: they can help us understand TSTLOOP, for example.
I'll be reviewing that documentation too. But in the meantime, if your study inspires you to probe anything else on the CPU board, especially around the MMU: go for it! Maybe you'll make another important discovery.
Thank You stepleton for studying this ROM code. I double checked the CPU pins of earlier measurements and it was OK.
Here is a picture of pins 1, 2, 3, and 4 of U2E, same signal of pins 234 and pin 7 of the expansion connector. Zero level slightly different for clarification. A neg puls of 25 us every 200 us
In fact I have a logic analyser, a 8 channel Saleae . I used it for finding a defect LS166 in a Mac30/SE 10 years ago that showed "Mac in Jail" ( with help from 68kmla.org). I will see if I can get it running. Will study the ROM code further.
Hi, I managed to get the logic analyzer working. Measured to all incoming pins of the MC68000. As I understand after reading the spec of the CPU. Its easy to attach test hook clips on the CPU. I had to solder thin wire on U2E to get proper signal.
The analyzer save files in .sae format. her is two pictures when restarting with reset button and here after restart with interrupt.
A logic analyser is a very useful thing to have indeed!
I don't think that what you have here tells us much more than we already know, though. All of these signals look correct to me. We will have to check something else.
-----
Meanwhile, your 'scope screenshot shows us what we expected to see: pin 1 stays high, the other three are pulsing. Our current theory about an MMU error is still our best guess. We think that the CPU is busy looping forever in MMUERR (quoted above), and each time it executes MMUERR, it also runs TSTLOOP.
TSTLOOP does a useful thing for us. Remember how the MMU stores configuration in a big table: the MMU registers. TSTLOOP writes values to a few of the addresses in the MMU registers, and then it reads them back. MMU registers are twelve bits wide, and MMU register addresses are identified by 8 bits.
Between each pair of RESET pulses, MMUERR's calls to TSTLOOP make the following pattern of twelve reads and writes to MMU registers:
In the first call to TSTLOOP:
Register 0000 0010: Write and then read 0000 0000 0001
Register 0000 0100: Write and then read 0000 0000 0010
Register 0000 1000: Write and then read 0000 0000 0100
Register 0001 0000: Write and then read 0000 0000 1000
Register 0010 0000: Write and then read 0000 0001 0000
Register 0100 0000: Write and then read 0000 0010 0000
Register 1000 0000: Write and then read 0000 0100 0000
In the second call to TSTLOOP:
Register 0000 0011: Write and then read 0000 1000 0000
Register 0000 0101: Write and then read 0001 0000 0000
Register 0000 1001: Write and then read 0010 0000 0000
Register 0001 0001: Write and then read 0100 0000 0000
Register 0010 0001: Write and then read 1000 0000 0000
You can see how every address bit is used at least once, and every data bit is used at least once. There are good reasons for why this pattern takes the shape that it does, but we don't have to worry about that right now.
-----
What we are going to want to do is watch these reads and writes happen to the registers --- and that is to say, we want to watch reads and writes to the three SRAM chips U8A, U9A, and U10A. If we're lucky, we'll find situations where a 1 gets written and a 0 comes out, or a 0 gets written and a 1 comes out. This will be a sure sign of a problem nearby!
That sounds pretty easy, but the thing that makes this difficult is that the SRAMs sit on the 68000's address bus, right alongside the ROMs and the RAM and everything else. The SRAMs will hear any address that goes out on the address bus, and they'll emit data even if other bits in the address (bits that the SRAMs don't notice) mean that the 68000 is talking to some other part of the computer. (The reason this doesn't matter is because further on, downstream of the SRAMs, there are electronics that stop the signals coming out of the SRAMs from interfering with the data that the 68000 is really interacting with.)
This means that if we just monitor any of the SRAMs' data bits, we'll see a lot of random chatter, and not necessarily the writes and reads that we care about. The SRAMs are always talking, but the 68000 is only listening some of the time.
-----
Happily, there is a solution. Each SRAM chip has a \WE pin --- "write enable". This pin is asserted (it goes low) if and only if we want to write data to the SRAM. So, unless there is a problem somewhere else, we can be certain that if \WE goes low, the Lisa is talking to the SRAM and not something else.
We also know that in TSTLOOP, each write to an SRAM is followed immediately by a read from that SRAM:
The truth is that it's not really immediate as far as the address bus is concerned, since after executing MOVE D1,(A0), the 68000 has to fetch MOVE (A0),D3 from the ROM before it executes that instruction and reads the value out of the SRAM. But we can at least be certain that a read from the SRAM follows shortly after a write.
Do you have an idea of what to look for now? Hint: we will want to trigger on \WE on an SRAM going low...
I think you should use your oscilloscope. Set up one probe on \WE (SRAM pin 10) and set your oscilloscope to trigger on a \WE falling edge. Then set up another probe on any data pin of any SRAM --- pins 11, 12, 13, 14. Wait for the Lisa to get in the phase where it repeats RESET, and monitor the SRAM data pins as \WE triggers. We hope that most of the data pins are working fine, and that they all look pretty much the same: the Lisa usually writes a 0 and reads a 0 back soon after. Sometimes it writes a 1 and reads a 1 back soon after. But if you see anything that looks unusual --- any time a read and a write don't match, any signal that doesn't look quite like it's jumping between 0V and +5V, that's interesting...
Hi stepleton and others. Something really strange happend when I was working with the oscilloscope and the static RAMs. Suddenly the monitor is showing this.
Testing after it started to work: after pressing reset button:
Its really great that its working, Thank You stepleton, You have saved it.
Now is the question, were was / is the defect? Inside SRAM or in other chips. Shall I replace the SRAM s or other, LS245 or F283??
I have looked on the chips and soldering but everything looks OK.
I have studied the ROM code but I cant really understand this language to know were to find the defect parts.
They say sometimes that it's better to be lucky than good, and it looks like we got lucky!
I don't know why the computer has decided to work, but sometimes when components are marginal, on the edge of breaking, then poking at them can coax them into a working state. This is usually not a permanent fix.
For now I wouldn't do much --- we still don't know 100% what the problem was, so we probably shouldn't try to fix it.
I'd say: see if the problem comes back, and if it does, we'll resume investigating. However, since the change occurred when you were probing the SRAMs, this does lead me to guess that the component that had the problem was one of the SRAMs itself and not a component that an SRAM was connected to downstream.
What I would do is something you suggested earlier: get a good magnifier of some kind and really inspect the solder joints for the SRAMs. Maybe you moved the chips a bit while you were probing; perhaps you bent a leg just a little bit. See if you can find any cracks in the solder at all --- if you can, that was probably the problem. Reflow the joint.
May you have lots of happy Lisa usage ahead of you!
Thank You both stepleton and mactjaap for excellent support. The HD is not working. HD error code 82. When I start Lisa the fan in the widget drive spins up. But if that is deconnected the HD is absolutly silent.
I have tried to rotate the HD and its possible but it will not spin. There is resistance to rotate it. When I now turn it on there is a weak click from the drive and the drive is moving 1 mm to the left but nothing more. I suppose its the bearing in the HD thats stuck.
Hello Colleagues.
I found this interesting thread and I have the same problem as BEU, but unfortunately I don't get error 41. I still have the same symptom of flickering black and white squares on the CRT with only the CPU board inserted like BEU had on the beginning of this thread. I know that CPU board is bad, because I have a second working Lisa and there is the same symptom when I swap the CPU board.
From an interesting study of the pin values analysis with an oscilloscope, I discovered that pin 41 on the CPU (UA13) has a value of 1.82V but there is activity on it. There is also 1.82V on pin 2 of both ROMs and the activity. Also pin 44 of the CPU (UA16) has 1.82V and activity is observed on it on the oscilloscope.
I have the same behavior on RESET pin 18 on CPU as BEU (it is not static HIGH) , Pin 15 clock is perfect. I have checked these values on a working CPU board and they are different.
Interesting find is that CPU RESET pin (18) has the same shape of wave and value as SRAMs 7 pin - there is no activity on that pin.
I have also checked 3 SRAMs - I swapped them to a working CPU board. I also changed the processor - everything is here and working.
I have checked continuity on SRAM pins and the 3 sockets pins by multimeter when chips are inserted - they seem to be ok. I have not resoldered the sockets of SRAM chips. Do you think I should do it?
I have IC tester and checked 7417 (U2E), 74F283 (U8A, U9A, U10A), 74lS1002 (U5B), 74LS245 (U11A), 74LS245 (U11B), 74LS245 (U15E), 74LS138(U13F), 74LS139 (U14F) and they are ok.
and here after restart with interrupt.
Is that of any value??
