General Category > LisaList2
Help please for my Lisa 2/5
pintoguy:
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
AlexTheCat123:
--- Quote ---1) There are two floppy cables (see pic). Does it matter which one we plug in (I tried both with no luck)
--- End quote ---
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.
--- Quote ---2) How is the dskdiag signal generated ? How can I test upstream of that, perhaps on the LisaLite adapter ?
--- End quote ---
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!
pintoguy:
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 ?
sigma7:
--- Quote from: pintoguy on July 31, 2023, 04:46:54 pm ---
I was able to successfully reformat the two Profiles
--- End quote ---
Wow, two working ProFiles, good deal!
--- Quote ---
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
--- End quote ---
What happens if you install in Mem2, leaving Mem1 empty?
--- Quote ---
5) The IO ROM version which should be H/A8 shows H/9F or sometimes H/91 or H/9D (see pics)
--- End quote ---
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.
--- Quote ---
1) There are two floppy cables ...
--- End quote ---
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.
--- Quote ---
2) How is the dskdiag signal generated ? How can I test upstream of that, perhaps on the LisaLite adapter ?
--- End quote ---
"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.
--- Quote ---
3) Could the floppy/speaker/keyboard problem be related ?
--- End quote ---
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.
--- Quote ---
3) The next obvious test would be to swap the IO ROM with a known good one.
--- End quote ---
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
sigma7:
--- Quote from: pintoguy on August 02, 2023, 12:10:53 pm ---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 ?
--- End quote ---
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"
Navigation
[0] Message Index
[#] Next page
Go to full version