Internal a1200 IDE interface

[Franko]

DriveSpeed reports the following figures for both FFS & SFS HDs...

Using FastATA MKIII Buffered interface...
5,487,263 Bytes Per Second

Using 4xEIDE Buffered interface...
2,547,512 Bytes Per Second

You can run two 2.5" HDs on the Amigas motherboard IDE connector but you have to keep the cables to about 2 to 3 cm at most (but I don't recommend it)...

Finding the FastATA MKIII or the 4xEDIE can be tricky though, just bought another 4xEIDE board on eBay last week cost £27.50 and a FastATA MKII sold for £47...

[Franko]

Cosmos my friend, FastATA works per case sadly.
It worked on PIO4 ONLY with a speciffic HD of mine (in the past) and with every other HD or CF, PIO3 was the cap. (You can find a detailed thread of mine over EAB).
I never managed to go beyond PIO3 and that's why I decided to replace it with Idefix Express that's easier, and more compatible with all OSes.

Using FastATA MKII and ATA3.driver Ver8.x, every drive I have tested (various sizes and manufacturers) up to 500GB all work perfectly at PIO4...

With my 060 boards you can even put them to PIO5 and they read & write fine but I do prefer to stay at PIO4 to be on the safe side...

(CD/DVD Burners run fine at PIO5 too and I've never had any problems burning discs at PIO5...

[Franko]

Yep, that's why I said... PER CASE!
You're a lucky man Franko if everything works just fine for you.

I used my former FastATA in both 040 and BPPC 060 with the results I previously said.
The driver was the last available and tested it with many HDs and CFs.

FastATA is a nice piece of hardware (although too unstable for my taste).

Never tried the FastATA on an 040 but on various 30s & 060s I've honestly never came across any problems with it...

Whereas with the 4xEIDE board on various set ups I've had quite a few problems trying to get them to recognise HDs bigger than 60GBs...

As you say it seems to be a "Per case" situation when it comes to adding bigger HDs on the Amiga especially I find with the 2.5" type...

[Franko]

That's pretty innacurate though. When extracting/compressing there's both reading and writing happening at te same time with shifts back and forward on the disk platters. That's a big part of why its so slow. Extracting to RAM proves this. Extracting even a 50 meg file is painfully slow, let alone things like isos. Yes cpu makes a difference, but harddrive speeds are a bottleneck.

No quite true, when using the FastATA MKIII (PIO 4) extracting a large archived file to RAM: from HD is actually faster than extracting from RAM: to RAM: ...

(especially on an 030 or higher...

@freqmax

The scsi.device is a bit of a misnomer, most likely named by CBM as at that time IDE was not popular and scsi was used by CBM instead...

Without going into too much technical detail, all call/functions go through the scsi.device even if you have an IDE, EIDE , ATA, P-ATA drive. They all use SCSI commands at their core the only real main difference between IDE & SCSI are the physical connecters used ...

[Franko]

Not true. IDE hard drives don't use SCSI commands at all. ATAPI devices such as optical drives use SCSI commands.

I was about to say I've only ever written utils for ATAPI/EIDE DVD & CD drives which of course use SCSI (even though they are connect to the IDE port) commands and then say you are of course correct...

But, I have also written one piece of software for EIDE/IDE HDs for reading and writing the RDB block and this uses SCSI commands, so now I'll have to say your incorrect...

[Franko]

Nope. scsi.device includes limited emulation of some SCSI commands, so even though your program might be using SCSI commands, the hard drive isn't.

True... but the point is you still write the code using SCSI commands that the driver basically interprets into the correct hex values to send to the device. Also the later scsi.device Ver50+ covers virtually all the scsi commands needed for HD/Optical media and can hardly be called limited...