LisaList2
General Category => LisaList2 => Topic started by: pintoguy on July 31, 2023, 04:46:54 pm
-
I was hoping to solve this on my own, but today I thought I needed to swallow my pride and ask for help.
The background: A Lisa 2/5 (with parallel card) plus two 5MB Profiles that I bought on eBay. The seller was in the LA area, and since my daughter lives there, she picked it up and brought it over to me in Palo Alto. This saved a few $100s in S/H. This 2/5 looks like it's actually a converted Lisa 1, as evidenced by the Twiggy power cable and the two floppy ribbon cables (see pic)
I was able to successfully reformat the two Profiles using the parallel card on one of my two 2/10. The CPU and both memory cards also tested OK. PS is good, after the two RIFA caps blew up and were replaced. The batteries of the 2/5 had never been removed, and the corrosion on the IO board and MB was extensive. I have not given up on the MB as yet, but decided to build a new one, using AlexTheCat123 github PCB info (Thanks !). I bought most of the components on AliExpress, and saved a ton of money (sorry Digikey...).This allowed me to do some good work on the IO board, and after replacing the 10uF Nichicon caps on the video board, taking the 400k FDD apart for de-seizing/lubing, removing corrosion on all sheet metal parts, retrobriting the case, and changing the light bulb in the on/off switch, I'm almost there.
I have a few remaining issues
1) The system boots only with one memory board in position Mem1. If I put the second board in Mem2, I have garbage on the screen
2) I still have the dreaded Error 57, stemming from the Disk Diag ROM test (documented in a previous post here). I did check that the Dskdiag signal (pin 11 on LS259 in U3E) was low, when it's high on my working 2/10
3) The keyboard is also not seen, nor do I have the "keyboard missing" error upon boot. The speaker also does not work
4) Past error 57, I can start booting from the Profile (with either MB or extension parallel ports), but get stuck after a while
5) The IO ROM version which should be H/A8 shows H/9F or sometimes H/91 or H/9D (see pics)
6) My good 2/10 IO board also throws error 57 when placed on the 2/5, but displays the correct H/88 ROM versions. It also boots from the Profile, using my parallel card. After booting, it gives me a diskette error ("not a proper Lisa diskette" etc..)
7) I swapped all common socketed chips with my 2/10 IO board, including the VIA2 chips, with no progress
8 ) I tested the 400k FDD on my 2/10 and it works
Thanks for reading this. Any help would be much appreciated, especially from AlexTheCat123 if he has time. Some of the questions I have
1) There are two floppy cables (see pic). Does it matter which one we plug in (I tried both with no luck)
2) How is the dskdiag signal generated ? How can I test upstream of that, perhaps on the LisaLite adapter ?
3) Could the floppy/speaker/keyboard problem be related ?
3) The next obvious test would be to swap the IO ROM with a known good one. Would one of you be coming to VCF-West this weekend, and be kind enough to give me a loan of one for a day ?
Thanks in advance
(https://lisalist2.com/index.php?action=dlattach;topic=423.0;attach=594;image)
(https://lisalist2.com/index.php?action=dlattach;topic=423.0;attach=595;image)
(https://lisalist2.com/index.php?action=dlattach;topic=423.0;attach=596;image)
(https://lisalist2.com/index.php?action=dlattach;topic=423.0;attach=597;image)
-
1) There are two floppy cables (see pic). Does it matter which one we plug in (I tried both with no luck)
Yeah, the LisaLite should be plugged into the cable for the lower Twiggy drive. I'm not sure what would happen if you used the upper cable, but I'm pretty sure it wouldn't work.
2) How is the dskdiag signal generated ? How can I test upstream of that, perhaps on the LisaLite adapter ?
From what I understand (my knowledge of the floppy controller is somewhat limited), DISK_DIAG is generated by the 6504 once the floppy controller has passed its internal self-tests. So if it's not getting asserted, the controller isn't passing those tests. The LS259 is just an addressable latch, so it latches the state of MA0 into the DISK_DIAG latch (addressed by MA1-MA3) whenever the 6504 tells it to.
A couple of people have had issues where the 16 MHz clock on the I/O board never starts up thanks to Q1 and Q2 presumably not having enough capacitance. Try probing pin 2 of U7A to see if you're getting a 16 MHz clock there. Don't probe the traces coming out of the transistors directly because the extra capacitance from your scope probe will probably cause the clock to start running, making it look like things are working fine! If there's not a clock on that pin, those transistors might be your problem! I know one person who just threw a crystal oscillator in there to fix this, so that's definitely an option if this ends up being your issue.
If you're getting the clock, check pin 1 on the 6504 (the reset pin) to make sure that it's getting reset at power-on. If that looks good, try probing Q0-Q3 on the LS161 at U7A. This counter chip provides the state sequences that control the operations within the floppy controller, as well as the 6504's clock, so things could definitely go wrong if the counter isn't counting.
Also go through and probe all of the address and data lines on the I/O board ROM to make sure that they all have activity on them.
And one other thing: did you use an LS367 or an 8T97 for U2F? The original design uses an 8T97 (despite the silkscreen insisting otherwise) and I discovered that the LS367 is just too slow and can cause some really preplexing issues. This probably isn't the cause of your current problems, but it could definitely eliminate some confusion down the road!
The floppy controller is probably the subystem that I understand the least out of everything on the I/O board, so I apologize if the above suggestions aren't super helpful!
-
Thanks AlexTheCat123 for the great suggestions. I will check on this shortly.
In the meantime, I noticed in your MB wiring that the signal R1 and R2 (pins 71 and 72 of the J2 CPU Board connector) go to pins 8 of the Mem2 (R1) and Mem1 (R2) connectors, respectively. The schematics calls for these to go to Mem1 (R1) and Mem2 (R2). In other words, they were inverted. Could this explain the issue I have when I have a 512k card in the Mem2 board ?
-
I was able to successfully reformat the two Profiles
Wow, two working ProFiles, good deal!
1) The system boots only with one memory board in position Mem1. If I put the second board in Mem2, I have garbage on the screen
What happens if you install in Mem2, leaving Mem1 empty?
5) The IO ROM version which should be H/A8 shows H/9F or sometimes H/91 or H/9D (see pics)
The I/O ROM version is collected from the RAM shared with the 6504/Floppy Disk Controller. If the 6504 isn't running, it won't have moved the ROM version into the shared RAM and you'd get random RAM contents as it seems you have. If the 6504 is fine but the CPU's access to the I/O board is not working properly, then you could have the same symptoms. If the I/O Board wasn't responding at all, you'd get a bus error, so I suspect at least some of the circuitry is working some of the time.
1) There are two floppy cables ...
As Alex said, only the "lower" drive is supported by the Lisa 2. The lower drive cable is the shorter one. Leave the long one disconnected (unless connected to a Sun20, X/ProFile, etc. for power)
All Lisa 2 computers (aside from the ones with the internal Widget) have the two floppy drive cables, so having two isn't an indication that it used to be a Lisa 1.
2) How is the dskdiag signal generated ? How can I test upstream of that, perhaps on the LisaLite adapter ?
"Disk Diag" is a misleading name IMHO; it is a software generated signal controlled by the 6504. It isn't connected to the Lite adapter or the floppy drive.
During normal operation, it indicates the FDC is performing a time sensitive routine (ie. reading/writing to the floppy), and so the 68K should not access the shared RAM (and is locked out if it attempts to do so). (When the 68K accesses the shared RAM, the speed of the FDC is briefly reduced giving the 68K time to access the RAM without contention with the 6504.)
In the I/O ROM listing, the Disk Diag signal is controlled via accesses to "DISL" and "DISH" with the comment that these are "Memory Enable/Disable for the 68k"
Since this signal is accessed through the parallel port VIA, it must also be working to read the signal properly.
3) Could the floppy/speaker/keyboard problem be related ?
The speaker is connected to the motherboard via the J2 card edge connector. The floppy and keyboard are connected via the J1 card edge connector. All 3 go to the I/O board. Since there are other issues with the CPU talking to the I/O board, I'd guess the I/O board is the problem. If a known working I/O Board has the same problems, then I'd suspect the motherboard... check the card edge connector contacts are in good shape.
3) The next obvious test would be to swap the IO ROM with a known good one.
The I/O ROM is involved with the FDC only. Since there are other I/O problems (keyboard, speaker), there must be another problem (perhaps in addition to the I/O ROM, or the ROM may be fine).
HTH
-
I noticed in your MB wiring that the signal R1 and R2 (pins 71 and 72 of the J2 CPU Board connector) go to pins 8 of the Mem2 (R1) and Mem1 (R2) connectors, respectively. The schematics calls for these to go to Mem1 (R1) and Mem2 (R2). In other words, they were inverted. Could this explain the issue I have when I have a 512k card in the Mem2 board ?
R1 and R2 control which Memory slot is doing refresh cycles. The refresh alternates between the two boards to reduce power requirements. Swapping them should not make a difference.
edit: on further thought, maybe it does make a difference:
The two slots have the rows addressed in opposite orders (so the physical memory expands outwards from the 1MB address location).
The refresh is done in conjunction with video cycles, but the refresh rows are not done in opposite orders in the two slots.
Hence if video is coming from the slot that has reversed addressing, but the refresh happens simultaneously from the non-reversed addresses, perhaps there is contention with two rows accessed during one video cycle?
However, only one row's column will be accessed when the data is read, so no, there should not be contention... false alarm, I'm back to thinking that "Swapping them should not make a difference"
-
In the meantime, I noticed in your MB wiring that the signal R1 and R2 (pins 71 and 72 of the J2 CPU Board connector) go to pins 8 of the Mem2 (R1) and Mem1 (R2) connectors, respectively. The schematics calls for these to go to Mem1 (R1) and Mem2 (R2). In other words, they were inverted. Could this explain the issue I have when I have a 512k card in the Mem2 board ?
What a coincidence! Someone else reached out to me this morning and noticed the same thing! It turns out that I somehow accidentally swapped the footprints of the two RAM slots when designing the board, so the slot labeled MEM 1 is actually MEM 2 and vice versa. This won't affect the functionality of the Lisa at all (which is why I never noticed it), but it might be a little confusing if the self-test finds a RAM error because it would report the wrong slot being bad. I already updated the Gerbers on Github to fix this problem, so anyone who makes boards in the future won't have to worry about this. I'm really sorry about my mistake!
I don't think this would cause any of the memory issues that you're seeing because my boards have the same design flaw and work fine, so it's likely to be something else!
-
Thanks sigma7 ! Much appreciated
In response to your and AlexTheCat123 comments:
did you use an LS367 or an 8T97 for U2F? It's an LS367. I had seen your post regarding Error 57 and this chip. I'll keep this in mind
What happens if you install in Mem2, leaving Mem1 empty? Same result: garbage on screen
The I/O ROM version is collected from the RAM shared with the 6504/Floppy Disk Controller. If the 6504 isn't running, it won't have moved the ROM version into the shared RAM and you'd get random RAM contents as it seems you have. If the 6504 is fine but the CPU's access to the I/O board is not working properly, then you could have the same symptoms. If the I/O Board wasn't responding at all, you'd get a bus error, so I suspect at least some of the circuitry is working some of the time: Thanks. The 6504 was swapped with a spare one, with no change
As Alex said, only the "lower" drive is supported by the Lisa 2. The lower drive cable is the shorter one. Leave the long one disconnected (unless connected to a Sun20, X/ProFile, etc. for power). All Lisa 2 computers (aside from the ones with the internal Widget) have the two floppy drive cables, so having two isn't an indication that it used to be a Lisa 1. Thanks.I also have a spare molex power cable which I thought was there to power the twiggies. Is this not the case ?
And thanks for all other great suggestions. I'll go back to the bench this weekend, and will update !
-
What a coincidence! Someone else reached out to me this morning and noticed the same thing! It turns out that I somehow accidentally swapped the footprints of the two RAM slots when designing the board, so the slot labeled MEM 1 is actually MEM 2 and vice versa. This won't affect the functionality of the Lisa at all (which is why I never noticed it), but it might be a little confusing if the self-test finds a RAM error because it would report the wrong slot being bad. I already updated the Gerbers on Github to fix this problem, so anyone who makes boards in the future won't have to worry about this. I'm really sorry about my mistake!
You don't have to apologize ! And yes, what a coincidence indeed !!
-
The I/O ROM version is collected from the RAM shared with the 6504/Floppy Disk Controller. If the 6504 isn't running, it won't have moved the ROM version into the shared RAM and you'd get random RAM contents as it seems you have. If the 6504 is fine but the CPU's access to the I/O board is not working properly, then you could have the same symptoms. If the I/O Board wasn't responding at all, you'd get a bus error, so I suspect at least some of the circuitry is working some of the time:
Thanks. The 6504 was swapped with a spare one, with no change
A variety of problems will prevent a good 6504 from running; Alex's suggestions to confirm it is probably working such as checking the oscillator/clock is running and the bus is active are likely sufficient.
Lisa 2 computers (aside from the ones with the internal Widget) have the two floppy drive cables, so having two isn't an indication that it used to be a Lisa 1.
Thanks. I also have a spare molex power cable which I thought was there to power the twiggies. Is this not the case ?
That 3 pin cable is also in all Lisa 2 computers (unless they are wired for a Widget). It isn't used for Twiggies (or anything else that we know of).
-
So here is a progress report after the weekend bench work
Try probing pin 2 of U7A to see if you're getting a 16 MHz clock there: Yes, I see a clear 16MHz signal
If you're getting the clock, check pin 1 on the 6504 (the reset pin) to make sure that it's getting reset at power-on. Yes, the reset signal is high, and goes low when I push the reset button
If that looks good, try probing Q0-Q3 on the LS161 at U7A. This counter chip provides the state sequences that control the operations within the floppy controller: This is a bit beyond my skill set, but signals q0-q3 do show square waves of various duty cycles. I assume it's what you'd expect ?
Also go through and probe all of the address and data lines on the I/O board ROM to make sure that they all have activity on them: there is NO activity that I can see. Would this help us ?
-
It's great that you have clock and reset! When you say that reset goes low when you push the reset button, I'm assuming that it goes high again around a second later, right?
If that looks good, try probing Q0-Q3 on the LS161 at U7A. This counter chip provides the state sequences that control the operations within the floppy controller: This is a bit beyond my skill set, but signals q0-q3 do show square waves of various duty cycles. I assume it's what you'd expect ?
Yep, that sounds about right. Each one of those pins should have a square wave of a different frequency on it!
Also go through and probe all of the address and data lines on the I/O board ROM to make sure that they all have activity on them: there is NO activity that I can see. Would this help us ?
Well, that's a big problem! You've already confirmed that Q0-Q3 on U7A are producing square waves as they should, but now maybe try probing pin 27 (PHI0) on the 6504 to make sure that the signal from Q2 on U7A is actually getting to the 6504 to clock it. If it is, then you might have a bad 6504. Assuming it's getting reset at power-on and it's being clocked correctly, you should be seeing activity on the bus, even if there are still serious problems somewhere else in the floppy controller circuit. I guess you could also have a bad EPROM (or one of the other chips connected to the bus) that's pulling those lines to 5V or ground, but that's probably pretty unlikely. Do you have a spare 6504 (or a 6507 from something like an Atari 2600) that you could swap in? That's probably what I'd try next!
-
Thanks Alex. Please see my replies.
When you say that reset goes low when you push the reset button, I'm assuming that it goes high again around a second later, right? Yes
try probing pin 27 (PHI0) on the 6504 to make sure that the signal from Q2 on U7A is actually getting to the 6504 to clock it: Yes, I get Q2 on pin 27
I guess you could also have a bad EPROM that's pulling those lines to 5V or ground: I checked every pin on the 6504, and only get the 5V at pin4 and ground at pin2, which I think is normal
Do you have a spare 6504 that you could swap in? Yes I do (from a working 2/10). It doesn't help
Should I look for an EPROM replacement ? Is this IO ROM re-burnable ?
-
Should I look for an EPROM replacement ? Is this IO ROM re-burnable ?
The ROM can be reburned or replaced easily, it's a standard 27(C)16. ROM images are up on Bitsavers.
-
Thanks. I haven't had a chance to do much in the past few days, but here is the latest:
1) The IO ROM placed in a good IO 2/10 board does display the proper H/A8 ROM codes. Is still shows error 57, but I think it's normal (2/5-2/10 floppy controller mismatch ?)
2) I actually have sporadic activity on the data lines of the IO ROM that comes and goes. But even when I see activity, I still have the error 57 issue
3) I tried to boot without the IO ROM chip in, and get exactly the same error
4) Then at some point, the board stopped working completely, and my 2/5 now boots with just the gray screen, with the CPU ROM letter "H" on the screen
I know the integrity of the gold pad from the edge connector J1 is important. They were quite corroded, and I cleaned them and coated them with solder as best as I could, but they still show missing areas. As far as I know, they still make good contact, but perhaps I should put some new copper strips on these pads. Any suggestion for what to use and how ?
Thanks
-
I know the integrity of the gold pad from the edge connector J1 is important. They were quite corroded, and I cleaned them and coated them with solder as best as I could, but they still show missing areas. As far as I know, they still make good contact, but perhaps I should put some new copper strips on these pads. Any suggestion for what to use and how ?
I suggest checking any questionable circuits that pass through the card edge using an ohmmeter with the card plugged in. (eg. measure from a part on the I/O board to the bottom of the motherboard or a part on some other board.)
A durable repair of a card edge finger takes some extra care and if there are multiple pads to replace that's probably a big job.
The pads are epoxied in place, but to maintain the board thickness (to prevent damaging or deforming the socket), you probably need to grind a recess in the board where the pad will go to make room for the epoxy. You can then gold-plate a copper pad with a simple kit, or use an already gold plated pad removed from a donor board. Note that card edge fingers are plated with a different (more durable) gold alloy than the gold that covers all of some modern boards, so I suggest using a scavenged card edge finger for the repair.
Since you may be troubleshooting further corrosion problems on that board, another option is to populate a bare board (either with new parts or moving parts from the defective board) ... I believe the Sapient Technologies boards are available (or will be soon) as bare boards from John / VintageMicros.com
-
Thanks. One repair that I used for some very badly damaged pads was to hammer down a thin copper wire on an anvil, until it became a thin strip. I them soldered that strip to the old pad. Not the cleanest way to proceed, but it did work OK, with minimal thickness increase.
And yes, I communicated with John (vintagemicros) but he does not have 2/5 IO bare boards in stock. I might go the AlexTheCat123 github route, just like I did with the MB
-
I communicated with John (vintagemicros) but he does not have 2/5 IO bare boards in stock.
Perhaps that was a miscommunication or a while ago... moments ago John confirmed that he does have some in stock now (unless I misunderstood).
-
Perhaps that was a miscommunication or a while ago... moments ago John confirmed that he does have some in stock now (unless I misunderstood).
This was 2 weeks ago. Perhaps he understood I wanted to finished board. I'll ping him again. Thanks
-
The ROM can be reburned or replaced easily, it's a standard 27(C)16. ROM images are up on Bitsavers.
There are also the relatively recent 400k/800k "universal" variants in the files section: Lisa I/O Board ROMs (https://lisalist2.com/index.php/topic,163.0.html)
IIRC, the I/O Board EPROMs are 2732; the expansion boards' are 2716 (there are a couple of exceptions).
-
This week's update: Looks like the EPROM is OK. It reads and verifies the 341-0290-B BIN file perfectly. So I think we can put this to bed.
I noticed that +5B only reads 4.8V or so, when +VSTBY is 5.5V. On my "good" board, it's 5.3V. So I suspected that diode D9 was therefore bad, but after I changed it, I still have the problem.
But..., chip 8T97 at U1F is very hot to the touch, when it's perfectly cool on my good board. I had told Alex that it was an LS367, but I was wrong, as I simply read what's written on PCB. I'll trace the signal around that and see what happens, but I hope I have found the culprit.
-
I noticed that +5B only reads 4.8V or so, when +VSTBY is 5.5V. On my "good" board, it's 5.3V. So I suspected that diode D9 was therefore bad, but after I changed it, I still have the problem.
Note that +5B2 is different from +5B, they both are derived from +5STBY, but through different diodes.
+5B2 is via D9, which is an ordinary silicon rectifier, so a 0.7V voltage drop is not surprising.
+5B is via D3, a Schottky diode, so the drop should be less than 0.7V, making +5B higher.
So if +5B is indeed 4.8V; D3 is the suspect.
But I'd guess it doesn't matter because digital. To me, it looks like +5B2 only exists as a separate circuit to decrease the load on the battery, which drives +5B when power is disconnected.
chip 8T97 at U1F is very hot to the touch
U1F drives the long ribbon cable that goes to the floppy; try disconnecting the lite adapter and see if U1F runs cool. If so, then look for a problem with the Lite Adapter, floppy drive, or cabling.
U1F also drives /DTACK when the CPU accesses the FDC SRAM, so if the 8T97 is not working, the effects would line up with the symptoms you've reported.
-
Thanks sigma7. Yes, I misspoke, it is +5B2 that shows the .7V drop. And thanks for explaining the nature of these +5B and +5B2 lines. I was scratching my head on this for many days, but it makes a lot of sense now. B would stand for "battery" perhaps ?
And as I was tinkering around U1F, the system died. Upon turning on, the switch light turns on for a second or so, before shutting off. I suspect a short perhaps ? Might be consistent with the hot U1F chip that gave up? I have spare 8T97's ordered, so will update hopefully in a few days.
Thanks again
-
Upon turning on, the switch light turns on for a second or so, before shutting off. I suspect a short perhaps ? Might be consistent with the hot U1F chip that gave up?
Removing U1F will allow you to confirm that it is the problem. With U1F missing, the signals driving the Lite Adapter/Floppy drive will be missing, as will /DTACK generated when the 68k accessed the FDC shared RAM. So startup should go normally until the point where the self-test checks the FDC, which won't respond, causing an I/O Board error.
The 74LS367 has the same function as the 8T97, but with less output current. If you have those on hand, you could try one in place of the 8T97 while waiting for those to arrive, leaving the Lite Adapter unplugged or bending out the floppy signal output legs of the chip so they don't make contact with the socket. The drivers of /DTACK elsewhere in the Lisa are not 8T97s, so the LS367 may be adequate for driving /DTACK here (but likely not for the floppy signals).
HTH, James
-
Thanks James. The five 8T97 arrived today, so I'll report shortly, after I get a chance to go back to the bench.
-
Bad news today. I removed the 8T97, and the "short" is still there. I call it "short" because I think the symptoms (turns on for ~1 second and switches off) are consistent with it. But is it ? Any input would be greatly appreciated. I think I remember reading about these same symptoms earlier, but cannot find the post
What I know now is that it's not the PS, nor the COP421, nor any of the other socketed chips.
-
Will the system stay on if the I/O board is removed? This may tell you if the issue is on the I/O board or elsewhere in the system.
-
If I insert the board from a good 2/10, the light stays on. This is why I almost certain it's the IO Board
-
... almost certain it's the IO Board
Check the socketed chips for one in backwards (happens to all of us).
On the questionable I/O Board (out of the Lisa), check the resistance from +5V to ground, and from +12V to ground. If either of those are nearly shorted, the PSU will click.
Depending on the sensitivity of your ohmmeter, you may be able to locate a short within a few chips... keep moving the probes around until you find the area where the resistance (eg. from +5 to ground) is the least.
IIRC, this is a battery corrosion repaired board... visual check for further corrosion?
-
Thanks very much James
Check the socketed chips for one in backwards (happens to all of us).
Yep, all OK. I even removed them all - same result
On the questionable I/O Board (out of the Lisa), check the resistance from +5V to ground, and from +12V to ground. If either of those are nearly shorted, the PSU will click.
800 Ohm or so for +5V-gnd and 4Mohm for 12V-gnd, so OK I guess ? I didn't check the -5V though. My PS actually does not click. The power just shuts off after one second or so. So perhaps not a short ?
IIRC, this is a battery corrosion repaired board... visual check for further corrosion?
Yeah, I'm almost sick of looking at the board and checking all the traces after 2 month of that :). But I'll persevere
-
800 Ohm or so for +5V-gnd and 4Mohm for 12V-gnd, so OK I guess ?
4 MegOhm isn't right, way too much resistance -- I'd guess you didn't get the right test point or a good connection. On a sample here, +12V to ground is about 59 KOhm. +5 to ground is about 500, close enough to yours that I'd not suspect it.
My PS actually does not click. The power just shuts off after one second or so. So perhaps not a short ?
Ah yes: no. If there is a short, the PSU will click as the over-current protection kicks in, then resets, repeatedly. No clicking very likely indicates the problem is not a short.
Presumably then the COPS power control circuit is telling the PSU to shut off.
Refer to sheet 2 of the 5 page schematic...
Check the ON signal at U7F-12.
If it is low, then that will turn off the power.
I see that "ON" is pulled up by R42 to "+5B2" which came up earlier, so re-check that +5B2 is roughly 5V.
Presuming that "ON" is low and +5B2 is around 5V; pushing the power switch should make "ON" go high... does it go high briefly or stay low?
Depending on what you find, work back through the circuit to the COPS and see if it is generating the ON state or not, and/or see if some other part of the circuit is over-riding that.
-
Thanks James. You helped me solve this problem today. As I was carefully measuring voltages on all the COP421 pins, I found out that pin 19 had a significantly higher standby voltage (1.33V) on the failed board than on the good one (0.66V). So I followed this trace to D5 that connects to the +12V line. I quickly realized that this +12V line was open near the edge connector ! This explains the ~1s ON state from the PS that got all the right signals, but then quickly noticing that there was no load on the +12V line, and switching to OFF ::)
So now I'm back to Status #3. #1 was no power at all. #2 was power and IO error 57. #3 was blank screen with letter "H", indicating good CPU. #4 was where I was yesterday.
Never giving up :)!
-
Second update: Major progress! I put a brand new 8T97 chip at U2F, and I'm back to Status #2: IO error 57 :)
So at the end, I had two different problems: a faulty 8T97 and a bad +12V trace. Back to where I was a month ago 8)
-
Thoroughly impressed by the investigative work happening in this thread. Kudos. 8)
-
Major progress! I put a brand new 8T97 chip at U2F, and I'm back to Status #2: IO error 57 :)
Awesome!
I take it that the new 8T97 is not getting hot; if so that problem should take priority over the IO error.
I'm not clear on some details of status #2. Does the ROM version show as H/xx where xx is random, or is it H/ with nothing following?
-
Yes, the new 8T97 is not getting hot.
And yes, as I described earlier in this thread, the ROM version shows H/9F, and sometimes H/91 (not H/A8). As I was playing around today, I notice that the activity on the data lines of the 6504 is quite erratic. Upon multiple resets, it sometimes shows something, and sometimes not. But in both cases, it still shows error 57.
I noticed that the P6A "PROM State Machine" socketed chip (U4B) is also quite hot. If I remove it, I have activity 100% of the time on the 6504. Could the failure of this chip explain code 57 ? What's the purpose of this chip ?
Oh, and the memory issue I had earlier (gibberish when I had the two 512k boards) solved itself. I put the second board in, and still got gibberish. But after I hit the reset button once, everything was OK. Not too sure what happened though.
Thanks again !
-
I noticed that the P6A "PROM State Machine" socketed chip (U4B) is also quite hot. If I remove it, I have activity 100% of the time on the 6504. Could the failure of this chip explain code 57 ? What's the purpose of this chip ?
U4B is a bipolar PROM and will naturally run warm/hot as its power consumption is about 1/2 Watt. The video PROM on the CPU board is the same type (with different programming) so you can compare to its temperature.
P6A is the same PROM as on the common version of the Apple II Disk Controller board. It is used to encode/decode the bitstream to/from the floppy disk drive. The explanation of The Logic State Sequencer in chapter 9 of "Understanding the Apple II" is an explanation of its function (perhaps there is a better one, dunno). This state machine is indicative of the talents of Steve Wozniak... if you find it interesting or even challenging to understand, imagine coming up with it!
The "HardInit" portion of the I/O ROM reset routine will return an error if the state machine doesn't respond appropriately, so I suppose a failure of U4B could cause error 57. See this topic: Troubleshooting self-test Error 57 (https://lisalist2.com/index.php/topic,431.0.html) for a suggestion on checking for this situation.
-
Thanks so much ! I also noticed that the +5V line of P6A (pin 20) is open vs. all the other pins. Shouldn't resistance always show some finite numbers (say a few Mohms), like it does for all others pin-to-ground values on that chip? In any events, I did buy a spare one on eBay.
And thanks for the troubleshooting info. Interesting that on the 2/10, they changed the P6A/LS323 chips to a pair of LS85.
I'm off for a trip abroad, so I probably won't report again until after Sept 16. Much appreciate your help again, as always !!