Amiga 3000 repair Faqs

[Castellen]

To answer your questions....

#1 Can the Amiga 3000 run without the daughter board?
For OS2.x and OS3.x the Zorro riser board must be fitted.

#2 without a floppy drive?
Yes, though I think you end up with a DF0: icon on WB.

#3 without a hard-drive?
Yes, you'll eventually end up with select kickstart screen (V1.4 ROMs) or the insert disk screen (OS2.x or 3.x).

#4 without a mouse?
Yes.

#5 without a keyboard?
Yes.

#6 without the battery?
Yes, the RTC doen't need to be fitted either.

#7 Can you buy the weird 15 pin molex type power connector anywhere to make a longer power supply cable?
Haven't seen them for sale, but your best bet would be Digi-Key for small volumes.

#8 Is there a way to test for bad roms?
Put them in a known working computer.  It's incredibly rare to have bad ROMs, unless someone has dome something stupid with them (bent pins, wrong polarity).  Swapping positions of the two ROMs won't damage anything, but the computer won't boot as every 32-bit word read from the ROM pair will be swapped.

#9 Can you use other Amiga Model parts to use in the 3000, CIA's, Denise, Paula, etc....
Yes, a majority of the parts are swappable with the A500 and A2000.

#10 Can you use other Amiga Hardware, say an A500 internal floppy on a A3000? (I don't care if it mounts or fits (we know it wont) I just care if it would actually boot a floppy)
Yes, the floppy interface on all models is the same.

Also...
The computer doesn't require any fast RAM to boot.

Reseat all the socketed ICs, socket connection problems can cause non-booting and unstable operation.

Check you have correct clock distribution throughout the computer, this mainly comes from U103.

Check the various reset lines are high (5V).

Check FAIL_ is high (5V).

Try disabling the FPU using the.

Check the ROMs are being read by using an oscilloscope, measure on the ROM output enable pin, 20, going low during most of the CPU read cycles.

Check you have a valid TICK signal at J350.


There's various other things you can check too, but I'm running late for work.  Look on my webserver for more documentation and schematics.
http://amiga.serveftp.net

[Castellen]

You can measure the FAIL_ signal on pin 2 of the real time clock and on one of the pins of Gary.  I'm too lazy to get out the schematic... Should be 5V on this line for the system to operate.

If the ROM pin 20 is staying high all the time, it indicates a more low-level problem.  As the timing of this signal is fairly quick (a few µSecs) then you'll ideally need a digital scope to look at it properly, you can use 'single sweep' or 'wait for trigger modes'.

The active low ROM OE signal is generated by the gate array, Gary, when it decodes a specific address range on the address bus.

So check that there is activity on both the address and data bus.  If not, either the CPU is not running for some reason (in reset state, no clock, faulty CPU).  The CPU is easy enough to replace if you can borrow one from a known good A3630 card or whatever.  Assuming you can SMD solder.

If the CPU generates a few address cycles then freezes and no ROM OE signals are generated, then there's possibly a problem with the address decoder in Gary.  Perhaps a bad contact with the IC socket or Gary is faulty?

Failing that, there's not too much more you can easily look at aside from checking other CPU control lines, though I don't think there's much that should prevent it from putting address words on the bus in order to look at the boot vector in ROM.

Non-booting problems can often be rather tricky as I'm sure you now understand :-P

[Castellen]

You'll ideally need a 60MHz or faster digital scope to have a look at what's going on.  Of course the signal is going to be fast, electronics has evolved slightly since the days of the Colossus :-P
I forget the exact cycle timings in the 68030, but a ROM read cycle is going to be much less than 1µSec, probably more around the 100nSec mark??

The PCB is fairly resilient.  Top and bottom copper is mostly used for signal layers, with the internal two layers mainly carrying 5V and ground, plus a few signal tracks which couldn't quite fit on the top or bottom.  Besides, I don't think there are any signal tracks running under the RTC area.  In denser parts of the board, like under the CPU, there are a lot of internal signal tracks however.  Unlikely you've damaged anything when the battery was removed.

If the battery has leaked, it's possible it's damaged the sockets of the neighbouring Denise or Paula.  The system won't boot unless they are working correctly.  Fit new sockets if the contacts are green, or better yet, solder the ICs directly into the board.  Check vias around the battery area as well, they can get corroded open circuit.  Here's a drawing I did showing it in more detail.

[Castellen]

Hmmm, I didn't write that particular piece, not sure where the detail even came from now?  Given the low value of resistance, they're probably series resistors in the power supply to something as part of an R/C filter.  The A3000 has a separate 5V supply for the video section, they were probably trying to minimise digital noise on the analogue video output.  Personally I would have just designed an adequate filter, but that's another story...

The 5V video supply is the violet wire in the corner of the power connector.  Forget which pin is it now.  Just measure the supply randomly on some of the video logic (e.g. U450 pin 19) and it's immediately obvious if the video supply is working.  The computer will boot without it (and you should hear the floppy drive "ticking"), but of course you'll have no video output.


To answer your other post...
I have a pin information diagram for Gary on this page, about 2/3rds of the way down.  It's for the A4000, but it's the same part.

Schematics for the entire computer here.  The internal operation of the gate array (Gary) is semi-complicated.  Don't expect to be overwhelmed with detail from the schematics.

Since the ROM Output Enable is never going low, it kind of suggests one of:
- Bad CPU
- No CPU clock
- CPU in reset state
- Something holding up the address bus
- Faulty address decoder in the U110 gate array (Gary)
- Damaged U110 socket (check for cracks in the corners)

This kind of problem isn't very easy to track down.  In the case of address bus problem... well nearly everything in the computer sits on the address bus.  So any of these could be what's causing the problem.

One approach to this sort of problem is to monitor each address bus line in turn with the scope, just after you set then release the reset line (keyboard reset should also work for you).  You should get a quick burst of bus activity on most of the lines before it freezes.  If not, it's probably a CPU related thing (bad or no clock?).

Look out for logic output clashes on the data and address bus.  That's where the peak value of the waveform is around 2.5V as opposed to the normal 5V.  This happens when you have two logic outputs trying to drive a single line in opposite directions.  That kind of fault could be a problem on the data bus chip/fast bridge, so around the U251 - U258 area.  Yuck.