Print

[AlexTheCat123]

You guys helped me fix my heavily corroded Lisa a while back, but unfortunately it's having problems again. I started having problems where it wouldn't turn on and when it occasionally would power up, it would give error beeps indicating that the I/O board was bad and the CRT wouldn't display anything. I got tired of the corroded and flaky I/O board, so I ordered a bare I/O PCB from John at VintageMicros around a week ago and got it fully assembled. I also made an X/COPS to replace the COP421. Now the computer will turn on when I press the power switch and the CRT turns on, which is an improvement, but clearly things still aren't working right (see the attached picture). There is also no sound of any kind from the speaker (no clicks or beeps). I'm assuming that this problem has something to do with the CPU board since it handles video generation, but I can't really probe it with the oscilloscope to figure anything out since it's inaccessible while the card cage is installed. Does anyone have any tips or suggestions of what to try next? Thanks for the help!

[rayarachelian]

It could be something to do with the VSROM which is used by the video state machine to generate the horizontal and vertical sync signals.
Could also be an issue with the RAM.

But both of these would indeed point to the CPU board, if there's not even a beep it could be the CPU never starts (although a bad COPS VIA6522 would stop it from beeping even if the CPU is running.)

See if you can hook up your scope to ground + one of the CPU pins, maybe A1 or D0 and see if anything is moving there. That would at least tell you if anything's running.

[AlexTheCat123]

I just probed the address and data lines of the CPU and there's definitely activity. What should I try next?

[rayarachelian]

I just probed the address and data lines of the CPU and there's definitely activity. What should I try next?

That's a good sign. I'm guessing the RAM boards are ok as they worked before, right? You could also try with just one CPU board or the other if you happen to have two.
Without RAM, there's nothing that can be displayed.

I'd look at the CPU board schematics and locate the VSROM and the things it talks to - that's the video state machine. Something around there's not working - though it could be something related to the analog board. I do see some diagonal lines on the display, those are a sign that some horizontal retrace is happening.

I take it you've played around with the trimpots on the video board using a plastic screwdriver already.

Some other things to try, pin #19 (CB2) on VIA #1 (with the other end to GND) produces sound via a timer + shift register output so I'd attach the scope to that and power it on, it might be trying to beep some codes but if the speaker isn't working you won't hear them. The scope should be able to pick up the tones graphically and you could figure out what they're trying to say: https://lisafaq.sunder.net/single.html#lisafaq-hw-rom_beeps - you might have trouble telling high vs low tones apart graphically if they're all high or all low, so you might need to guess around those codes. Might help if the scope has some audible mode to help you with that, or if you have something you could attach to that pin that leads to an amplifier - but be careful not to fry your VIA.  An old pen style logic probe that beeps might do the trick to get sound out also.

If you see nothing, either the CPU can't talk to the VIA or something else is broken along the path from the CPU board to the I/O board.

If you have a spare VSROM to swap out that would help eliminate that. If not you might try this one: https://www.ebay.com/itm/142796459701 - but it could also be something else around there.

Inserting a blank or PC formatted floppy might be useful too though it might also eat it and not let go until you fix the problem - the idea here is that it will see the floppy as unreadable and should eject it. That would tell you that the 68000 and the Boot ROM are working.

Another thought which you might be able to verify if you don't detect any beeps: Since you're not seeing video, and you're not hearing beeps or clicks or anything like that, it might also be the motherboard. Perhaps some contacts aren't touching or are dirty and so the CPU board video state machine can't read the RAM and turn it into a video signal and it can't talk to the I/O board so it can't beep.

Checking for broken solder joints on the motherboard where the CPU connector is might help, as would cleaning the contacts, reflowing the solder, etc.

[AlexTheCat123]

Good news! It lookes like one of the address lines going to the CPU was broken, so I patched the trace and now it actually displays something meaningful on the screen! It's great to have the Lisa at least sort of working again after months of attempts to fix it. Both the CPU and memory boards pass the self test, but the I/O board takes around 20 seconds to test (I remember it testing almost instantly back before I started having problems with the computer) and it gives an error code of 57. I also hear a beep code, so the speaker seems to be working as well. I looked up error 57 and it seems to be related to the floppy disk controller, but the schematic for the disk controller section of the I/O board looks pretty complicated and I'm not really sure where to start for troubleshooting this section of the board. Also, the ROM revision for the CPU board correctly shows up in the upper right hand corner of the screen as revision H, but the I/O ROM shows up as revision 00, which definitely isn't right. Please note that I am using the Sun Remarketing 800K ROM instead of the original Apple one.

[rayarachelian]

Good news! It lookes like one of the address lines going to the CPU was broken, so I patched the trace and now it actually displays something meaningful on the screen! It's great to have the Lisa at least sort of working again after months of attempts to fix it. Both the CPU and memory boards pass the self test, but the I/O board takes around 20 seconds to test (I remember it testing almost instantly back before I started having problems with the computer) and it gives an error code of 57. I also hear a beep code, so the speaker seems to be working as well. I looked up error 57 and it seems to be related to the floppy disk controller, but the schematic for the disk controller section of the I/O board looks pretty complicated and I'm not really sure where to start for troubleshooting this section of the board. Also, the ROM revision for the CPU board correctly shows up in the upper right hand corner of the screen as revision H, but the I/O ROM shows up as revision 00, which definitely isn't right. Please note that I am using the Sun Remarketing 800K ROM instead of the original Apple one.

So for sure, showing version 00 is not right, it means the 6504 failed to report the version. The 6504 runs from the I/O ROM. They share about 1KB of RAM - so when the Boot ROM tried to talk to the I/O ROM it failed to get what it wanted, so next you should check that the CPU can access the shared floppy RAM. Error 57 actually means "57 = bus error accessing disk controller" - which explains both the slow access as well as the 00.

Here's the code for it:

Code: [Select]

1136|                       ;  Check disk alive indicator
1136|
1136| 4282                          CLR.L   D2              ;clear for use                          CHG022
1138| 227C 00FC D901                MOVE.L  #VIA2BASE,A1    ;set ptr to parallel port 6522
113E| 0229 00BF 0010                ANDI.B  #$BF,DDRB2(A1)  ;ensure bit 6 is input
1144| 203C 001C 8000                MOVE.L  #DSKTMOUT,D0    ;set up timeout count for 15 secs
114A| 0811 0006             @2      BTST    #DSKDIAG,IRB2(A1) ;check indicator
114E| 6606                          BNE.S   @3              ;skip if set
1150| 5380                          SUBQ.L  #1,D0           ;else loop until timeout (about 8 us per loop)
1152| 66F6                          BNE.S   @2
1154| 7439                          MOVEQ   #EDISK,D2       ;error if not set                       CHG022

There's also some code that decides what type of machine it is by reading the I/O ROM version from 00FCC031 - if you go in service mode you can try to read from this address and see what's there.  It should be A8 for a 2/5, or 88 for a 2/10 - even with the 800k drive.

My guess is you might have yet another address line somewhere, this time one that leads to the floppy controller that is broken. However, that timeout loop above that sets code EDISK also happens if FDIR isn't responding. So that might be an issue with VIA #2.

[AlexTheCat123]

I tried swapping the two VIAs around and the problem didn't go away, so I think that the VIAs are fine. I checked all of the data lines coming from the floppy RAM (BD0-BD7) and they all look fine, but the 8th address line that connects to the floppy RAM, the ROM, and the 6504 is showing some weird behavior. All of the other lines are around 5 volts peak to peak, but this address line is only around 1 volt peak to peak. It looks like this behavior is coming from the line MA8 (I'm not really sure about its purpose) that feeds into the multiplexer at U4C that in turn connects to the RAM, ROM, and 6504 address lines. I'm assuming that this is likely the source of the problem, right? If I hit the reset switch, the address line looks normal for around half a second, but then it goes right back to this weird one volt peak to peak behavior again.

[rayarachelian]

I tried swapping the two VIAs around and the problem didn't go away, so I think that the VIAs are fine. I checked all of the data lines coming from the floppy RAM (BD0-BD7) and they all look fine, but the 8th address line that connects to the floppy RAM, the ROM, and the 6504 is showing some weird behavior. All of the other lines are around 5 volts peak to peak, but this address line is only around 1 volt peak to peak.

Maybe something's pulling it down to (near) ground. MA8 is just the 8th address line going to the 6504. I see it's on the I/O ROM EEPROM, no?
Yeah U4C is yet another mux, likely used in address decoding/chip selection.

A thought occurs, likely this mux is used in allowing access from the 68000, if so, maybe something on the CPU board leading to it is the cause of the issue? Maybe A9 since both MA8 and A9 are inputs to adder 2 on that mux?

[AlexTheCat123]

Since the only things connected to MA8 are the 6504 and the ROM, I would guess that one of them is causing the weird problem. I think I might just try replacing the 6504 and the ROM to see if that does anything unless you can think of any other reasons for MA8 to be acting strangely.

[rayarachelian]

Since the only things connected to MA8 are the 6504 and the ROM, I would guess that one of them is causing the weird problem. I think I might just try replacing the 6504 and the ROM to see if that does anything unless you can think of any other reasons for MA8 to be acting strangely.

Yeah, but the 68k does get shared access to that bus, that's why there's the FDIR and DISKDIAG lines - to gate access, but for whatever reason MA8 + A9 go through U4C LS157 ( https://www.ti.com/lit/ds/sdls058a/sdls058a.pdf?ts=1622261683812 ) as 2A and 2B and output as 2Y which goes to RA8 and the U1B + U2B 444C-3 SRAMs, perhaps there's something there with A9 to check.

I'm assuming 444C-3's are SRAM because the pinouts of these two seem a lot like what you'd see in an 4 bit SRAM, and their power goes to the battery backed up +5B which matches the HWG, however I wasn't able to find a datasheet for these by searching the web.

A9 has an address of 512, however the 68000 accesses only the odd bytes of the shared memory, it's going to hit address 256+(A1-A8) which is in the range of the shared 1K SRAM, not just the 6504's ROM.

So what I'm trying to say is that if, and that's a big if, A9 is stuck on, and the I/O lines bypass the usual shared address semantics, it would interfere with the 6504's access to the bus, and we've already seen a similar issue with your Lisa, so maybe this is more of the same? So if the 6504 is blocked by lines from the 68000 stuck on, then it wouldn't be able to go through it's power on test and it wouldn't be able to write it's ROM version in the shared SRAM address or do much else, and then when the Lisa Boot ROM reads it, it would see 00 for the version number.

I mean, unless I'm misreading the schematic? https://lisaem.sunder.net/cgi-bin/bookview2.cgi?zoom=0?page=8?book=6?Go=Go

[AlexTheCat123]

I see what you're saying now. I just checked A1-A10 at the inputs to the muxes and five of them (A5, A7, A8, A9, and A10) are stuck either high or low, which doesn't seem normal, so you were probably right about the problem being on the CPU board after all. Now it's just a matter of figuring out what exactly the problem is.

Edit: It actually looks like those five address lines have activity up until the Lisa starts testing the I/O board. They only get stuck after the I/O board test begins.

[rayarachelian]

Edit: It actually looks like those five address lines have activity up until the Lisa starts testing the I/O board. They only get stuck after the I/O board test begins.

that is truly bizarre, is there something on the I/O board doing that? I don't see how anything other than the CPU should be able to set the address lines, and why would they lock?

Do you have a spare CPU (not board) to swap out with?

I can understand the CPU hitting addresses 00fcxxxx as it touches I/O space, but it should also go back and forth with the ROM which is at 00fexxxx and lower RAM - at least where the video display page is, which should be the highest 32K of the physical RAM, so those lines should be bouncing around, not fixed.

[AlexTheCat123]

I have two spare known-good CPUs and they both do the exact same thing as this one. I also have a spare CPU board, but something's wrong with it and there isn't any activity on the CPU's address or data buses. This is a really weird problem! Maybe the CPU's getting stuck in some sort of a loop as a result of not being able to read the contents of the shared floppy RAM?

[rayarachelian]

There is a STOP opcode, but it's unlikely to be invoked. Generally it's used to sit in an idle state until an interrupt happens.

Even if things so south, generally in the Lisa Boot ROM, you should still be able to use the mouse and keyboard, and so the CPU should still function and the address lines shouldn't be locked down, even then, it should switch between reading from the boot ROM, accessing RAM, COPS, VIA, etc.

[AlexTheCat123]

Both the mouse and keyboard are inoperative for me. I don't know if it's a COPS error (unlikely, since it has been replaced with a brand new and freshly assembled X/COPS) or if it's something related to the strange address line behavior. I hope that the replacement 6504 and I/O board ROM that I ordered will free up that stuck MA8 line and maybe get everything working again, but I'm not too confident about that. The 6504 does get pretty hot, so maybe something is wrong with it.