Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: James1095 on October 26, 2016, 08:03:50 PM
-
So after not doing much Amiga related for a while, I found myself in possession of a nice looking Amiga 3000. Unfortunately the battery leaked and did some damage but I caught it before it got as bad as most of the pictures I've found online. Unfortunately it acts essentially dead. I've verified the power rails all look good and gotten as far as observing a roughly 1-second burst of activity on the buses and ROM enables when power is applied or I manually assert the _FAIL signal but then it goes dead. The clocks are still active but the address and data buses are static. I'm not real familiar with the Amiga architecture but my suspicion at this point is that it's starting to load the ROM and then crashing. Are there any common issues that can cause this? I was under the impression that the area around the battery is primarily video circuitry so I haven't yet desoldered any of the ICs in that area to inspect closely for hidden damage but it cleaned up pretty well and I don't see any rotted out traces. Does the Amiga have any sort of built in diagnostic like the POST codes on a PC? The machine was found in a hoarder house that was being cleaned out so I have no knowledge of it's previous status.
-
So after not doing much Amiga related for a while, I found myself in possession of a nice looking Amiga 3000. Unfortunately the battery leaked and did some damage but I caught it before it got as bad as most of the pictures I've found online. Unfortunately it acts essentially dead. I've verified the power rails all look good and gotten as far as observing a roughly 1-second burst of activity on the buses and ROM enables when power is applied or I manually assert the _FAIL signal but then it goes dead. The clocks are still active but the address and data buses are static. I'm not real familiar with the Amiga architecture but my suspicion at this point is that it's starting to load the ROM and then crashing. Are there any common issues that can cause this? I was under the impression that the area around the battery is primarily video circuitry so I haven't yet desoldered any of the ICs in that area to inspect closely for hidden damage but it cleaned up pretty well and I don't see any rotted out traces. Does the Amiga have any sort of built in diagnostic like the POST codes on a PC? The machine was found in a hoarder house that was being cleaned out so I have no knowledge of it's previous status.
http://www.skepticfiles.org/cowtext/comput~1/ami-init.htm
-
A3000 issues like this a really hard to nail down. Its one of the few machines I despise working on. I have been able to fix several, but with acid it can be deep issues in that area. I would start with pulling all the chips and making sure 100% of the traces to all sockets are good. You can find the schematics online here: http://www.amigawiki.de/doku.php?id=en%3Aservice%3Aschematics
-
Well that schematic is certainly a lot nicer than the one I was squinting at yesterday. Tonight I pulled the hex inverter at U477, it was pretty nasty but actually tested good out of circuit. I found an open trace between that and the phase pot on the back so I cleaned the area, installed a socket and repaired the trace. There was some corrosion in the socket for Denise so I replaced that too. The video circuitry seems a bit more lively now but the CPU is still not doing much. I removed the ZIP RAM that was installed and moved the extra chip RAM over into the fast RAM DIP sockets in attempt to eliminate RAM as a cause but that made no difference. Whatever is happening it's not getting very far, I can power cycle the machine or manually assert the _FAIL signal and it gives me less than a second of activity and then the CPU hard locks with no activity on any of the address or data lines, it's very consistent. I never get anything at all on the screen although I did get valid sync and a few random white bars at one point after I reset it. I think that's just a case of the lights are on but nobody's home. The video circuitry is running but with the CPU crashed there's nobody at the wheel.
-
Do you have a CPU board you can test with? Replacing the soldered on 030 is difficult but not impossible on the 3000. USe a hot air desoldering station if you attempt it and try using some of the chipquik stuff. It makes it very fast and easy, but its messy to remove that junk once done.
-
I have seen a dead 030 throw yellow screens (just like if the daughter card was removed), don't know if that helps. Acill is right, test with a cpu board to make sure.
I have seen lots of 3000s in my life, from my experience the PALS going bad and bad traces/vias are 99% of the failures I have seen. Caps never go bad on the 3k. I doubt it is the CPU.
The real nice thing about the 3000, if it is well maintained and never had a battery leak, and the PALS were replaced with GALS, the darn things never fail. Make sure that you diligently clean the board, the acid leaks everywhere, so neutralize the entire board otherwise you may have future problems.
-
I don't have any other Amiga parts to try so that's not an option unless somebody wants to loan me a CPU board for testing. I am capable of surface mount rework but I'd really prefer to avoid it unless I'm quite certain the CPU is bad, especially since I can't just go out and buy a 68030. I hadn't thought of the PALs failing but if the code is available my device programmer does support at least some of those, what part(s) are appropriate for replacing them?
-
I think the code is available from Dave Haynie's site. I will look when home from work if you cant find it. I know he released the code for the 3640 boards.
-
I found a German site with the jdec files but it didn't say what GALs to use. I've worked with FPGAs and CPLDs but PALs and GALs are a bit before my time so I'm not all that familiar with them. Does anyone have a list of specific part numbers that are known to work?
I don't suppose there's anyone in the greater Seattle area with a CPU card we could try in this thing? I'd be happy to bring the machine by sometime to mess with it. I just have nothing to test the parts in and no spare parts to swap for diagnostic purposes. With what Amiga parts tend to cost, I don't want to just blindly throw money at it and hope something fixes the problem.
-
Save yourself lots of time and pickup a set of GALS. They are cheap.
http://www.amibay.com/showthread.php?65230-Amiga-3000-GALS-to-replace-PALS-For-Sale&highlight=GALS
Even if they don't fix the problem, they will run cooler once you fix the rig.
-
Cool, that thread has a list of part numbers that will work. I'll make sure my programmer supports them and then I'll buy some blank GALs, looks like they're still cheap.
-
So while I'm waiting for the new GALs to get here, I found the Amiga diag ROM which looks very promising. http://www.diagrom.com/
I found a place that has some 27C400-150 EPROMs, will those be fast enough to work in a 25MHz A3000 or do I really need the 105ns ones the author of the test ROM is using? Another potential option is to make an adapter for some 4Mb PLCC32 flash chips I have but I've got too many irons in the fire already.
-
Well I got the new GAL16V8D's and programmed them with the code I found for the A3000 PALs. Unfortunately it made no difference, although they do run quite a lot cooler than the old PALs did. Looks like I need to wait for the EPROMs to come so I can make some test ROMs. Hopefully that will provide some clues of what to check next.
-
Did you fix it? I see an A3000 for sale in the Seattle area on eBay now ;)
http://www.ebay.com/itm/Commodore-Amiga-3000-Working-With-New-Battery-/132010755276?hash=item1ebc7444cc%3Ag%3AxqcAAOSwA3dYM8UU&nma=true&si=jlGN0%252FWePa9fZt6sK%252F%252BPq7euEs0%253D&orig_cvip=true&rt=nc&_trksid=p2047675.l2557
-
Well I got the new GAL16V8D's and programmed them with the code I found for the A3000 PALs. Unfortunately, it made no difference, although they do run quite a lot cooler than the old PALs did. Looks like I need to wait for the EPROMs to come so I can make some test ROMs. Hopefully, that will provide some clues of what to check next.
That test ROM is John Hertell's work. He is a good friend of mine from Sweden. If you join the Commodore Amiga group on Facebook you can get in touch with him and get some direct support. The ROM works fantastic too, and he updates the code a lot, so plan to reflash that eprom several times, lol!!
-
Well I finally got the EPROMs and programmed them successfully, unfortunately there's still enough wrong with the system that not much happens. It doesn't lock up now, I see continuous activity on the address and data lines but I'm not getting anything intelligible out of the serial port and nothing on the display. Checking with a logic probe I can see the tx pin is pulsing but I've not put a scope on it yet to see what's actually happening. At this point there are a few more things I want to try, going over the battery area with a fine tooth comb and testing all the vias, replace a couple of TTL ICs that had some minor corrosion which I now have replacements for. If that doesn't give me signs of life then I think it's time to send the motherboard out to someone who has more resources and experience with these. I'm capable of replacing the CPU chip if I can confirm that it's bad, but I don't want to perform the potentially risky operation only to find that I'm no better off. Everything I do in search of the existing problem has the potential to create new ones.
In contrast to the standstill here I did manage to partially resurrect an A2000 that belongs to someone else though it crashes before fully booting up. It had battery corrosion and the CPU socket was shot, it would only show a white screen until I replaced the socket and cleaned it up and now it shows the kickstart screen just fine and starts booting. I plan to have another go at it when he has time to come over again.
-
Did you fix it? I see an A3000 for sale in the Seattle area on eBay now ;)
http://www.ebay.com/itm/Commodore-Amiga-3000-Working-With-New-Battery-/132010755276?hash=item1ebc7444cc%3Ag%3AxqcAAOSwA3dYM8UU&nma=true&si=jlGN0%252FWePa9fZt6sK%252F%252BPq7euEs0%253D&orig_cvip=true&rt=nc&_trksid=p2047675.l2557
No, I'm afraid that's not mine. When I do get it working this one is a keeper, unless a nicer Amiga falls into my lap like this one did. It's going to be a prized addition to my collection of vintage computers.
-
After setting this aside for a while I pulled it out again last night and had another look. I was originally going to hook up a logic analyzer but I found that the ROM sockets are too close together to get a test clip on both at once, and a QFP-132 test clip for the CPU is $200 for a used one. Accelerator slot is an option but even the mating connector for that is $30 and I'd have to build a harness for it.
Anyhow I decided to poke around with my scope instead and found some ugly waveforms on most of the data bus lines. I need to get out a pad of paper and make a list of which ones look like this and maybe that will narrow things down a bit. This is with the Amiga diag ROMs that are supposed to do something on even a rather broken machine and they don't even get far enough to spit out anything meaningful from the serial port. Can anyone who has scoped the bus in one of these confirm that the spikes are abnormal? They're certainly not valid TTL levels but it occurred to me that they may be occurring when the nothing is using the bus.
Is there anything on the data bus besides the CPU, ROM and DMAC? I was looking over the schematic and didn't see much that directly connects. A few bits here and there but not the whole bus.
-
I was originally going to hook up a logic analyzer but I found that the ROM sockets are too close together to get a test clip on both at once.
Unless you're at the point of analysing 680x0 bus cycles, which isn't overly useful at this stage, that's a lot of time and effort that probably isn't going to get you very far. You can already see there are bus cycles happening, so the CPU is obviously trying to do its normal thing, then failing for some other reason.
Anyhow I decided to poke around with my scope instead and found some ugly waveforms on most of the data bus lines.
That's a better approach. I can't see your image for some reason, though bus termination isn't great on the Amiga so it's normal to see a bit of over/undershoot and ringing. An example of typical waveforms here (http://amiga.serveftp.net/Temp/A1200_ROM_timing.pdf) that I once took during an A1200 project, A3000/A4000 look much the same.
I'm fitting a new SCSI2SD to replace the grindy old hard drive in my A4000T later today, so that document will be unavailable for an hour or so at some stage.
I need to get out a pad of paper and make a list of which ones look like this and maybe that will narrow things down a bit.
Nothing wrong with your approach of checking activity after reboot on data and address lines. Almost all lines should have valid 0-5V p-p activity immediately out of reset. And normally you'll see constant activity on _ROM_ENABLE (ROMs pin 12) in normal operation.
If you're seeing 0-2.5V on a couple of lines, that usually indicates a short between them. If you're seeing no activity on one line or more, do a simple DC resistance check to ground/5V with the machine off. As I recall, all of the CPU data/address bus is terminated with about 3k Ohms to 5V, so normally you'll measure the same static resistance on each line. If there's one that's significantly different, there's your problem.
This is with the Amiga diag ROMs that are supposed to do something on even a rather broken machine and they don't even get far enough to spit out anything meaningful from the serial port.
Unfortunately that's the problem with that test method, you need a mostly working machine to run the test software to tell you where the problem is. The DiagROM actually does a pretty good job for other faults though.
Depending on your EPROM programmer, you might need to swap the 16-bit words or you'll get the same result you're seeing now. It's usually not obvious if you need to do the swapping or not. One way is to write the binary image to an EPROM and see if it runs in a working Amiga or not. If not, swap the bytes in each 16-bit word and try again. I can generate swapped images pretty quick if you need.
Can anyone who has scoped the bus in one of these confirm that the spikes are abnormal? They're certainly not valid TTL levels but it occurred to me that they may be occurring when the nothing is using the bus.
Can't see your waveform, but as above, you're probably seeing overshoot and ringing, which is normal. As with every shared bus, if something isn't using it, then that device's output should be in a high impedance state. If you've got two devices trying to write to the bus at the same time, of course you'll have a collision, which is where you'll see a lot of 0-2.5V p-p waveforms. That probably isn't going to be your case though because that type of fault is rare in the A3000.
Is there anything on the data bus besides the CPU, ROM and DMAC? I was looking over the schematic and didn't see much that directly connects.
Yes, there's a lot more. And there's the address bus to consider as well. As I recall, there's the FPU, CPU bus/register bus bridge, CPU bus/expansion bus bridge, 8520 CIAs, the address decoder (Gary). Plus the real time clock as well. If that's been corrosion damaged (or the address latch beside it) then remove the RTC (and address latch), the machine will boot fine without either fitted.
Other things to check:
Make sure the ROM Overlay line, from pin 2 on 8520 U350, goes low immediately after reset, then goes high after about 500mSec. If that's not happening then the machine is either not reading ROM data correctly due to some bus issue, or the ROM data is mostly bad (word swapped), or can sometimes be a U350 fault. Swap U300 and U350 and see if there's any change.
That'll give you an indication of how far it's getting. Though there's a lot of things that can stop it booting.
Can sometimes also be bad chip memory. The power on test is pretty crude and it's possible for the power on test to verify partially broken memory as good, at which point the system tries using it, then falls over with no indication. That's pretty hard to fault find without special tools however.
Sorry for the long post. If you get stuck, I can have a look at the board on my run-time Amiga analyser, though I'm a bit backed up with Amiga jobs at present.
-
Look for Dave Haynie on Facebook. This was his baby after all. He would have some good input to offer if you ask him I bet.
-
Odd that you can't see the waveform, I attached it as a standard png file. What I'm seeing is some ~2.5V spikes intermingled with normal looking 0-5V transitions.
Uhg, I *loath* facebook, but I might have to see if I can figure out my password and log in. I haven't used it in years.
-
Odd that you can't see the waveform, I attached it as a standard png file. What I'm seeing is some ~2.5V spikes intermingled with normal looking 0-5V transitions.
Uhg, I *loath* facebook, but I might have to see if I can figure out my password and log in. I haven't used it in years.
I can see various other posted images fine, just not yours. Not sure, maybe I haven't sacrificed the right number of goats or virgins or whatever you're supposed to do to make these things work. Email (http://amiga.serveftp.net) me a copy and I'll check it out.
The brief ~2.5V waveforms are probably transitions between different devices doing bus writes, as in something has just ended a write cycle at the same time as something else is starting a write cycle. You'd need to compare with a working machine to be sure, but I don't think this is your problem.
Don't blame you, I don't do Fascistbook either. By all means ask Dave, but not sure what else he's going to say on top of the starting suggests I posted. While he's an incredibly clever guy, he doesn't have a crystal ball.
-
Maybe if I convert it to a .jpg that will work, I'll give that a go.
Yeah I realize it's very difficult to troubleshoot remotely, I've been on the other end of that effort many times. That's why I was thinking the logic analyzer might offer some good insight combined with the knowledge of precisely what the test ROM code is doing.
-
Maybe if I convert it to a .jpg that will work, I'll give that a go.
That didn't work either, but turns out it's some kind of compatibility problem using IBrowse. Worked OK on a computer running FireFox.
Where exactly are you measuring that waveform? I happen to have a stack of freshly repaired A3000 boards on the bench at the moment, so easy enough to take a comparative measurement.
-
I think that particular waveform came from pin 20 of the lower ROM. I did some poking around the other night and almost all of the data bus lines looked similar so it may be normal. I'm really running up against a wall trying to fix this thing, I'm tempted to try to find someone semi-local to work on it, shipping to and from New Zealand would cost a small fortune just for the shipping.
-
I think that particular waveform came from pin 20 of the lower ROM. I did some poking around the other night and almost all of the data bus lines looked similar so it may be normal. I'm really running up against a wall trying to fix this thing, I'm tempted to try to find someone semi-local to work on it, shipping to and from New Zealand would cost a small fortune just for the shipping.
I had a look at the same line (CPU bus D11) on a working A3000 just now and see the same thing as you are, so I don't think that's an issue. This capture (http://amiga.serveftp.net/Temp/A3000_D11.JPG) doesn't show it particularly well, but you get the idea.
As mentioned, have a look at what the Overlay line is doing for a start as that'll give you the next set of clues.
Shipping an A3000 main board (1.2kg) to NZ is something like US$35 with USPS, so if that breaks the bank, do ask around locally. Though I'm not aware of anyone else who has the level of diagnostic tools required to easily trace faults such as these.
-
Well shoot, I thought I was onto something there, oh well, thanks for checking on that for me. I'll try to pull it out again tonight and have a look at the overlay line.
$35 is not as much as I had assumed it would be, international shipping has gotten hugely more expensive in recent years, sending stuff to the UK costs at least 4x what it did 10 years ago. Still $35 over, assume roughly the same to get it back and that's $70 in postage alone and doesn't count paying you for the work. It's not that I can't afford it, but I've got a mountain of projects competing for my money and time. Also I'd really like to figure this out, sending it out feels a lot like giving up.
-
Keep in mind that the Overlay line probably won't be the fault, unless it's something as simple as a CIA (8520) problem, which can happen. But activity of OVL will give you more clues about what's happening.
So if Overlay is working as expected, see if it's getting as far as the memory test. The easy way to do this is to look at any write enable (WE) line on any one of the eight soldered in DRAMs. Can't remember if it's active high or low, but you'll work it out.
The memory test begins with writing the 46 exception vectors, so you'll see 46 x 32-bit longword writes from address $00000000 (then $00000004, etc), then it reads them all back to make sure they're OK. The same value of $00F80598 is written in all 46 writes. So for example, if the read-back detects a problem at $00000000, then you'll get a green screen fault after one read cycle, though you said you're not getting that. Depending on which DRAM bits might have failed (stuck high or low), it's still possible for it to pass this test and the boundary test, then it'll try to use the memory for system stuff and fall over with no warning.
Gets a bit tricky from then on without more diagnostic tools. So unless you intend developing something yourself (which is what I did) you might be struggling to get much further.
-
Ok that gives me some ideas on where to look, I haven't had a chance to get it out again but I'll report back with the results when I do. So this is with the original kickstart ROMs fitted rather than the diag ROMs?
-
Yes, use the standard ROM for those tests because we know the behaviour of it. I've got no idea exactly what DiagROM does on startup. Pretty sure it'd have to clear the Overlay line in the same way, this moves the ROM from address $00000000 to $00F80000 so that the system can use the memory from $00000000.
-
One of the things that complicates the A3000 is the built in SCSI controller.
The settings for this are stored in NVRAM, but removing the battery also removes the settings. How you get them back in and saved properly is one issue.
Some A3000s require at least one SCSI device connected even to fire up and boot from floppy. That might be the core issue.
http://bboah.com/index.php?action=artikel&cat=7&id=1854&artlang=en
They certainly can play possum, that can mean they're just lonesome for a drive to talk to.
-
Well the battery is gone because it leaked on the board and made a mess which I believe I've cleaned up. Hard to say if there's more damage lurking when I can't get it to do much at all. I never get anything on the screen, only thing that happens is the power LED goes from dim to brighter, IIRC with the Kickstart ROMS there is a brief burst of activity on the bus immediately after reset and then it halts. Still haven't had a chance to mess with it more but will do further tests soon.
-
Would definitely try terminating the scsi. My 3000t had similar symptoms until I put a terminator on the end of the scsi chain.
-
Would definitely try terminating the scsi. My 3000t had similar symptoms until I put a terminator on the end of the scsi chain.
I did have a terminator on there initially when I was messing with it, haven't tried terminating with the diag ROM. I'll reinstall it for further testing.