General Category > LisaList2
Lisa Video, ProFile power issue, NiCad Leak fixes, etc.
rayarachelian:
--- Quote from: AlexTheCat123 on May 28, 2021, 05:16:07 pm ---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.
--- End quote ---
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: ---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
--- End code ---
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:
--- Quote from: AlexTheCat123 on May 28, 2021, 07:39:30 pm ---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.
--- End quote ---
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:
--- Quote from: AlexTheCat123 on May 28, 2021, 10:14:11 pm ---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.
--- End quote ---
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
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version