SD2SCSI Multiple HDD Woes

[GadgetUK]

Hi,


I hope someone can help with this - I've spent the last 3 days trying to understand what's going on and I am getting nowhere with it.


I have an A2091 (rev 7 BIOS) - later WDC IC too.


I managed to setup the 1st drive on the SD2SCSI with a 950MB drive, partitioned into DH0 and DH1.


Got WB 1.3 installed and booting fine.
Upgraded to 3.1 and booting fine.


The problem then is if I add another drive (eg. 950 or 2GB - size doesnt seem to matter), I partition the drive as say DH2 (or split it into DH2 and DH3), ensuring that neither partition is bootable.


When I reboot I then find the system will not boot from DH0 again.




If I then take that SD card and boot it using WinUAE, it boots fine (and presumably removes some config related to DH2 (the 2nd HDD). I can then boot the SD card (DH0) again properly on the SD2SCSI.


WTF is going on? Is there some config that sits on DH0 related to when you add a new drive like this (eg. DH2), and why would adding another SCSI drive that is not marked as bootable cause it to then not boot from DH0?


I've gone around and around trying various things to make sense and I am just lost! It seem that the SD2SCSI only works with 1 drive on an A2091.


Is this something to do with drive IDs? The DH0 and DH1 are on ID 0, the larger 2GB drive I added is on ID 2. I thought lowest took priority?


EDIT: To be clear, both HDD are virtual drives provided by SD2SCSI (5.1). I have termination enabled on the SD2SCSI too.

[GadgetUK]

UPDATE: I think I've turned a corner!
I cannot explain WTF is going on but this is what I am finding:-
When it would not boot from DH0 after adding, partitioning and formatting DH2 (incidentally I had to use that "other" format utility to stop it telling me there was no drive inserted), I tried booting the SD card (just first drive - that's all the PC can see) using WinUAE, and it booted fine. Took the SD card out, put it back into the SD2SCSI in the A2000 and bam, not only did it boot, DH2 is there and working without issue.

It seems the process of taking the (none booting) card out of the SD2SCSI and booting in WinUAE, must somehow remove some dodgy previous config related to that new drive, and when booting back up on the actual Amiga after that it is able to re-add the drive?!?

Anyone know how that works? I am now imaging the SD card again (so I have a backup of both drives working), and I am going to then try and add a 3rd 2GB drive using the same steps.

[Fastdruid]

Just to be clear, you are connecting WinUAE to the SD2SCSI using USB connected to it and not removing the SD card from the SD2SCSI adapter?

Because IIRC the partition information is only on the SD2SCSI, if you take the card out and plug it in directly then you lose that.

[Jope]

Yeps, SCSI2SD V5.x and older store the logical units on the SCSI2SD. SCSI2SD V6 stores it on the SD card.

With SCSI2SD V5.x you can only take out the card and use it natively if you map the entire card as a single SCSI unit! In a V6 you can't take the card out and use it natively at all, it's the SCSI connector or built in USB only for the V6.

The SCSI connector is the most foolproof way to access the card in either of these, they really aren't meant to be used like a CF IDE adapter where you take the card out and jam it in a reader.

[GadgetUK]

As Jope says - the geometry is stored on device itself, not on the SD card for the version I use. I've found everything works now - except when I copy say 70MB of files from one drive to another, somewhere along the way (after say 20MB) it crashes the system. This SD2SCSI is more hastle than its worth I think =/ Certainly with the A2091!

I tried reducing the MaxTransfer value (as needed on CF cards) that doesn't seem to affect this behaviour.

[GadgetUK]

UPDATE: Still early days but it may be OK now - not 100% sure until this format of DH2 finishes. I temporarily disabled the 2MB on the A2091 to rule out some wierd issue there, and for the first time it has got over 50% into the format. The RAM tests out fine, but I am thinking that might be the problem. Will see if the format completes, then try copying a load of stuff onto that drive to see if it crashes then.

[Jope]

Uh oh, please format quick every time with hard disks and flash devices.

[GadgetUK]

OMG, I've kinda sorted it - but I have no clue what the exact solution is...

So, I tested the A2091 with same SD2SCSI on my rev 4 board - wouldn't boot at all on that one. I added a couple of pull downs under the 245's in the Zorro area (as per rev 6 boards), that made no difference. I removed the resistor packs nearest the CPU on the rev 4 (same as rev 6), that made no difference - no boot at all still after those mods.

I then tried my 2630 card in that board and it boots every time! Not only that, I get no crashes at all with the SD2SCSI and A2091.

Tried the same 2630 card on the rev 6 board, and I've found the same thing.


So the question (and I hope there's someone that's seen this before) - why does the 2630 make the A2091 more stable? (on two boards that work perfectly with everything else I throw at them). One is rev 4.x, the other is 6.x, both are only 100% stable with the 030 processor running things.

[Kin Hell]

Originally Posted by GadgetUK

OMG, I've kinda sorted it - but I have no clue what the exact solution is...

So, I tested the A2091 with same SD2SCSI on my rev 4 board - wouldn't boot at all on that one. I added a couple of pull downs under the 245's in the Zorro area (as per rev 6 boards), that made no difference. I removed the resistor packs nearest the CPU on the rev 4 (same as rev 6), that made no difference - no boot at all still after those mods.

I then tried my 2630 card in that board and it boots every time! Not only that, I get no crashes at all with the SD2SCSI and A2091.

Tried the same 2630 card on the rev 6 board, and I've found the same thing.


So the question (and I hope there's someone that's seen this before) - why does the 2630 make the A2091 more stable? (on two boards that work perfectly with everything else I throw at them). One is rev 4.x, the other is 6.x, both are only 100% stable with the 030 processor running things.

In those Famous words of Clarkson, "More Speed".

[GadgetUK]

Originally Posted by Kin Hell

In those Famous words of Clarkson, "More Speed".

Haha =D That doesn't help me work out how to get a straight 68000 running with it though =/

[Kin Hell]

Originally Posted by GadgetUK

Haha =D That doesn't help me work out how to get a straight 68000 running with it though =/

For sure, but why use 68000 when you have an 030 card?

Can you disable Caches on 030 card & does it still work?

[pipper]

Make sure all scsi IDs are distinct (i.e. the controller and all virtual HDDs have individual ids).
Also be aware that the Amiga stores a “Last Drive ID on the bus” somewhere on the drive. (Likely in the RDB). During boot it will not scan for bootable devices past the LastId. Adding more drives at the end requires you to boot once, open HDToolBox, so it’ll scan the bus and find the new devices. It’ll then show the drives as ‘changed’. Save the changes and that should have now updated the LastId, allowing to boot from the added drives.

[GadgetUK]

Originally Posted by Kin Hell

For sure, but why use 68000 when you have an 030 card?

Can you disable Caches on 030 card & does it still work?

It works fine with caches disabled on the 030! When using just the 68000 I get crashes when copying large blocks or files (or formatting a drive). The CPU isn't the issue, neither is the A2000 motherboard. I see the same behaviour on 2 different A2000 boards (1 rev 4.x, 1 rev 6.x).



Both A2000 work when using the 030, both also crash when copying large files when using only stock 68000. I am guessing its about how certain control signals are driven. The A2630 is driving some signal better - not sure which.

[GadgetUK]

Originally Posted by pipper

Make sure all scsi IDs are distinct (i.e. the controller and all virtual HDDs have individual ids).
Also be aware that the Amiga stores a “Last Drive ID on the bus” somewhere on the drive. (Likely in the RDB). During boot it will not scan for bootable devices past the LastId. Adding more drives at the end requires you to boot once, open HDToolBox, so it’ll scan the bus and find the new devices. It’ll then show the drives as ‘changed’. Save the changes and that should have now updated the LastId, allowing to boot from the added drives.

Thanks, ID's weren't the issue. The issue is a standard 68000 causes the problem on two different A2000 motherboards, and I've tried different brand 68000 chips too. With the A2630 running the issue doesn't occur.

[trixster]

is this going to be documentated in another video, Gadget?

[GadgetUK]

Originally Posted by trixster

is this going to be documentated in another video, Gadget?

Most likely =D I just need to work out what is causing unreliability with 68K on these two A2000's, vs A2630 rock solid on both boards. It's really wierd!


My guess is some signal(s) from the CPU are stronger / cleaner on the A2630, vs the stock CPU.

[Kin Hell]

Originally Posted by GadgetUK

It works fine with caches disabled on the 030! When using just the 68000 I get crashes when copying large blocks or files (or formatting a drive). The CPU isn't the issue, neither is the A2000 motherboard. I see the same behaviour on 2 different A2000 boards (1 rev 4.x, 1 rev 6.x).



Both A2000 work when using the 030, both also crash when copying large files when using only stock 68000. I am guessing its about how certain control signals are driven. The A2630 is driving some signal better - not sure which.

I'm not a pro with different Mask's for partitions in any manner, but technically, you should get better drive speeds with an 030 in the System. Would a different Mask allow a more reliable transfer under 68000?

[trixster]

Did you get to the bottom of the crashes with 68000?

I’m sure I read on here somewhere that due to a clash between accelerator card memory and memory on a scsi card when the 030 is enabled SCSI accesses are CPU (ie PIO) initiated rather than DMA. This would suggest that your crashes are dma related when using the 68000. Maybe!