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 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.
