Amiga 4000 takes eight minutes to boot (solved) sort of

[Pat the Cat]

I think got to be Warp card related, you are not alone;-

https://eab.abime.net/showthread.php?t=108853

Oh wait, that is you.

One thing I'd try is booting, then updating the file system on the hard drive with HDToolbox.

This will likely nuke the contents of the hard drive, but at least you might get to a shell prompt quicker than 8 minutes.

3,2 is totally different version of everything, including the file system copy on the RDB of the hard drive.

3,2 can need a mandatory clean install from 3.1. 3.1.4 it might be doable, but not 3.1.

[Pat the Cat]

You have to remember that 3,2 will boot with a 3.1 ROM.

It will check the ROM version and try to remap the 3.2 system.

That doesn't explain why it takes so long to start up.

When you say SCSI is disabled, do you mean disconnected or entirely shut down on the Warp?

The Warp ROM startup will always be done before the startup-sequence, so if it is doing a scan of every SCSI address and LUN combination, that will take quite a while to check no SCSI devices are available.

Perhaps a terminator on the SCSI connector would definitely remove the issue.

[Pat the Cat]

When I say shutdown on the Warp;-

"autoboot ROM (warpdrive.device) - can be disabled by a jumper"

From;-

http://amiga.resource.cx/exp/warpengine

Manual can be downloaded to check jumper connection (or lack of it).

The manual also uses the word "shunt" for jumper in one case.

[Pat the Cat]

Well... if it was checking each LUN of each SCSI address... allowing 4 seconds on each attempt to give the drive a chance to spin up...

... That would be 7 X 16 X 4 seconds, which is spookily close to 8 minutes.

It's not like the Warp SCSI lights up the hard drive activity light while it does that.

[Pat the Cat]

Jerky mouse is usually the chip U541, a 74HCT166 that multiplexes direction and forms MDAT signal going to Lisa.

Could also be track issue with same signals rather than chips.

Could that on its own slow down Workbench boot? I don't know.

[Pat the Cat]

I'm sorry, I was looking at the A4000T schematic, not the Desktop.

U975 on a Desktop version.

Roughly same position on either full or CR A4000D, about a couple inches from the clock battery, close to the edge of the motherboard.

Right in line to have dodgy connection from a spoiled battery.

[Pat the Cat]

Why always this amount of time?

Outside chance of it being a fault with the reset circuit,

This times a specific time by charging up a capacitor, if the resistor feeding it developed a higher resistance, it would take longer to charge.

Oh, that chip also handles some timing signals as well as the mouse, so  could just be that one chip (more likely connections to and from it).

[Pat the Cat]

When you setup the hard drive to install 3.2... did you use the Warp scsi tools utility or the 3.2?

After reading the manual, page 31 lists an option to check or uncheck to force the system to stop looking for extra drives and get on with booting.

After re-reading this thread, that's when the problem started - an unchecked entry on the RDB.

You might get away with just clicking the option and saving the RDB, rather than trying to reinstall everything from scratch.

Or not.

[Pat the Cat]

... E and L jumpers have to be set.

Maybe if they are not, the Warp tests all memory for errors?

[Pat the Cat]

It's probably fine. More likely to be OK than the CD drive.

The default of "all 3 jumpers on" assumes that all scsi drives will sync.

Most scsi drives default to asynchronous. And all will dumb down to single ended "Amiga era" scsi.

Warp scsi is very good when it's setup right, but it certainly isn't dumbed down or basic options only.

EDIT: OK, SAS SCSI drives excepted, and 68 and 80 pin SCSI drives need adapters to connect to a 50 pin cable.

[Pat the Cat]

An oldie but goodie... rough guide originally written with the A4000 user in mind;-

http://www.wonkity.com/~wblock/SCSI/SCSIExamples.html