Amiga 3000T need help troubleshooting

[Castellen]

I'd agree to first remove any CPU board and return the jumpers to use the onboard 68030.  The CPU jumper configuration posted above looks as though it might be A3000D specific.  The A3000T is a bit different, see what I have documented here under A3000T CPU JUMPERS:
http://amiga.serveftp.net/A3000_HardwareGuide/jumpers.html

You'll likely need to use the left hand column in the table.

Regarding your other post about damaged contents of the NVRAM causing the issue; the system will work fine (using defaults) if the NVRAM contents are lost, or even if the RP5C01 real time clock IC is removed.  And invalid NVRAM is more likely to cause scsi.device to hang near the end of the ROM boot sequence, which isn't what you're seeing.  The RP5C01 is socketed in the A3000T (the DIP18 package near the edge of the board, by the battery), so to eliminate the NVRAM theory you could remove the RP5C01 and see if that makes a difference.

Regarding the lack of floppy drive connection, that will cause some boot delay as the system tries to read a drive that isn't there, but it'll eventually get over it without indicating a system error.

And regarding capacitors, the system will typically boot without electrolytic capacitors fitted, let alone if the existing ones are reduced in capacity.  That's a fairly wild stab in the dark.

Best guess it might have some kind of chip memory read/write issue, which since the minimalistic test in ROM only does a basic longword read/write every 16kB or something, and doesn't check for address issues, it will not indicate a green screen error for address faults.  Instead the system will fail early on when it attempts to use the memory it tested to be good.  Using DiagROM as suggested is helpful to see any obvious chip memory problems (but still won't detect address issues, which will also cause DiagROM to fail).  I'd need to attach the hardware debugger to the board to see where it's failing during boot and exactly what's going on.  It's not feasible to do this level of remote hardware fault finding using guesswork.

If you can't find anyone locally to repair the main board, I'm happy to take a look.  The main board weighs around 2.6kg with packaging, shipping to NZ isn't the cheapest for that weight/volume, though I expect the board would likely be repairable.

http://amiga.serveftp.net

[Castellen]

I've seen these symptoms a number of times before, and it's usually caused by a chip memory address fault.  See my previous post on this subject where I'd hypothesised this.  This latest clue adds plausibility.

From experience, it's most likely a fault in one of the DRAMs.  Address faults are tricky to isolate to a specific device, so the best bet is probably to replace the chip memory DRAMs with new or known good devices.  You'll need a good desoldering station as half of the DRAMs are soldered into the board in the A3000T.

And in case you've not done so yet, remove the socketed chip memory DRAMs and repeat the test as this will force DiagROM to use the bottom half of the memory.  If the problem remains, then you've got the options of attempting some very complicated address fault finding, or replacing the DRAMs.

Would be useful if you can post the serial (text) output from DiagROM or post a screen shot, I don't do YouTube.

[Castellen]

Coincidentally, I just noticed that Chucky has been working on some memory address tests for DiagROM:
http://www.diagrom.com/index.php/download/

I've not tried it yet, but would certainly be worth a look in your case.  For the time being, you'll need to use the daily build until this feature makes it into to the 'stable' version.

[Castellen]

From the DiagROM output, there's quite obviously a chip memory problem.

For a start, it consistently reports:
  - Test of writing byte (even) $ff to $400 FAILED

If you're using a terminal in ANSI/VT220 mode, this will appear in red, to highlight the problem.



It then correctly reports the memory address range, and correctly decides on a base address of $ECCEA:
Startaddr: $00000400  Endaddr: $000FFFFF
  - Fastmemcheck skipped as we found chipmem
- Parallel Code $fb - Memorydetection done

  Using $000ECCEA as start of workmem (Base) 



But the base address is then somehow reported as $EEEEAAAA:

Detected Chipmem: 1024kB
Detected Motherboard Fastmem: 00kB
Basememory address: $000EEEEAAAA 

Of course there's no memory at that address, so it could never work with that.  It's more likely to be an issue with the string being written as EEEEAAAA instead of the expected ECCEA.


In fear of sounding like a broken record, this looks exactly like a chip memory fault, which is probably caused by one of the eight soldered in 256k x 4bit DRAMs being defective, but it's not easy to pinpoint which DRAM has the issue.  Fortunately they're not that hard to find new and were around $3ea when I last bought some.  Your cheapest and easiest route from here would be to buy eight new 256kx4 DRAMs in ZIP package, find someone local who is very good at through hole component soldering work, and get them to replace all 8 DRAMs.  Note that these parts are different from the 1Mx4 DRAM as used for A3000 fast memory.

As a source of DRAMs, contact Michael M (mechy on Amiga.org) who may have stock of these in America.  I can share his Email address privately if needed.



And FYI, I quickly ran DiagROM v1.2.1 in a good A1200 for a comparison of what to expect on a correctly working machine:

Code: [Select]

[With A1200, 2MB memory, DiagROM v1.2.1]

Garbage before this text was binary numbers: 1, 2, 4, 8, 16, 32, 64, 128, 240
5, 170 and 85
To help you find biterrors to paula. Now starting normal startuptext etc

Amiga DiagROM V1.2.1 - 16-Jul-20  - By John (Chucky/The Gang) Hertell


Testing if serial loopbackadapter is installed: <> NOT DETECTED
- Parallel Code $ff - Start of ROM, CPU Seems somewhat alive
    Checking status of mousebuttons for different startups:

    Set all Interrupt enablebits (INTENA $dff09a) to Disabled: Done
    Set all Interrupt requestbits (INTREQ $dff09c) to Disabled: Done
    Set all DMA enablebits (DMACON $dff096) to Disabled: Done

Testing if OVL is working: OK
- Parallel Code $fe - Test UDS/LDS line
  - Test of writing word $FFFF to $400 OK
  - Test of writing word $00FF to $400 OK
  - Test of writing word $FF00 to $400 OK
  - Test of writing word $0000 to $400 OK
  - Test of writing byte (even) $ff to $400 OK
  - Test of writing byte (odd) $ff to $401 OK
- Parallel Code $fd - Start of chipmemdetection

Addr $001F8400   OK  Number of 32K blocks found: $40
Startaddr: $00000400  Endaddr: $001FFFFF
  - Fastmemcheck skipped as we found chipmem
- Parallel Code $fb - Memorydetection done

  Using $001ECCEA as start of workmem (Base)

- Parallel Code $fa - Starting to use detected memory

Testing if serial loopbackadapter is installed: <> NOT DETECTED
Detecting if we have a working raster: DETECTED
Detected Chipmem: 2048kB
Detected Motherboard Fastmem: 0kB
Basememory address: $001ECCEA
As a very fast test of variablearea working this SHOULD read OK: OK!
- Parallel Code $f9 - Detected memory in use, we now have a stack etc
 - Doing Initstuff
 - Setting up Chipmemdata
   - Copy Menu Copperlist from ROM to Chipmem
   - Copy ECS TestCopperlist from ROM to Chipmem
   - Copy ECS testCopperlist2 from ROM to Chipmem
   - Fixing Bitplane Pointers etc in Menu Copperlist
   - Copy Audio Data from ROM to Chipmem
   - Do final Bitplanedata in Menu Copperlist
 - Initstuff done!

    Set Start of copper (COP1LCH $dff080): Done
    Starting Copper (COPJMP1 $dff088): Done
    Set all DMA enablebits (DMACON $dff096) to Enabled: Done
    Set Beam Conter control register to 32 (PAL) (BEAMCON0 $dff1dc): Done
    Set POTGO to all OUTPUT ($FF00) (POTGO $dff034): Done
- Parallel Code $f8 - Starting up screen, text echoed to serialport
Amiga DiagROM V1.2.1 - 16-Jul-20  - By John (Chucky/The Gang) Hertell



Doing ROM Checksumtest: (64K blocks, Green OK, Red Failed)
$5A39AC3E $C5724DFE $7C779F2B $00000000 $00000000 $00000000 $00000000 $006C00


CPU: 68EC20 FPU: NONE  MMU: NOT CHECKED

Checking for fastmem
Pressing left mousebutton will cancel detection (if hanged)

Checking if a 24 Bit address cpu is used: YES
 - Checking for Memory in 24 Bit area (NON AUTOCONFIG)
 - Checking for Memory in Ranger or Fakefast area