Internal a1200 IDE interface

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

[fishy_fiz]

Thanks for all the responses everyone, there's some good info. amongst all that. I'll definately look into some alternate ide interface in the future when money allows, but I was wondering if for a temporary solution it'd be possible to connect both a 3.5 inch ide drive and a dvdrom from the internal ide interface + 2.5 inch to 3.5 inch convertor? (given a power source of course)

[Tension]

1MB/sec is perfectly quick enough for me!!  Reading more than a whole floppy disk in a second!!  Who could want any more than that !!  

[Cosmos Amiga]

I tried my FastATA MK3 with a new Sandisk 8 Gb UltraDMA 45 Mb/s = still many crashs in PIO4...

Why ?

[Mizar]

1MB/sec is perfectly quick enough for me!!  Reading more than a whole floppy disk in a second!!  Who could want any more than that !!  

Tension:

I agree.  And with an 030 it sounds like the original IDE interface does 2MB/sec plus.  So, it's more than a high density floppy per second!  Sounds good enough to me.

[fishy_fiz]

The thing is though it's not like a harddrive is constantly reading one area of a disk, so 1-2 meg is quite painful a lot of the time. Extracting/compressing large files can be quite torturous.

[Mizar]

The thing is though it's not like a harddrive is constantly reading one area of a disk, so 1-2 meg is quite painful a lot of the time. Extracting/compressing large files can be quite torturous.

You're right it's not like the HD is constantly reading from the disk when extracting or compressing large archives.  Because with compressed files,  I think it's CPU cycle intensive a lot more than dependent on a particularly fast IDE interface.  Even when extracting, but especially when compressing, CPU speed is a lot more relevant than IDE and HD speed.  My experience is even when compressing files, with a utility like LZX, it is rather fast to HD.  That is, as long as it's not set to the highest compression level, which compresses to the max., at the full expense of CPU time.  Any other setting is fast on compression (though still very efficient).  And extraction is very fast.

[freqmax]

Asfair A1200 internal is P-ATA.Then why the involvment of scsi.device ..?

[fishy_fiz]

You're right it's not like the HD is constantly reading from the disk when extracting or compressing large archives.  Because with compressed files,  I think it's CPU cycle intensive a lot more than dependent on a particularly fast IDE interface.  Even when extracting, but especially when compressing, CPU speed is a lot more relevant than IDE and HD speed.  My experience is even when compressing files, with a utility like LZX, it is rather fast to HD.  That is, as long as it's not set to the highest compression level, which compresses to the max., at the full expense of CPU time.  Any other setting is fast on compression (though still very efficient).  And extraction is very fast.

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.

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

[alexh]

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

IDE drives appear as "scsi" in Win7 even today.

[Daedalus]

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.

I dunno about this. Seek times will always be a bit of an issue, but transfer speeds aren't that big a deal. Last night I was extracting some lha files from one partition to another on my 030/50 A1200. The hard drive LED spent more time off than on, showing a short burst of flickering followed by a longer idle time. This points at the number crunching throughput rather than drive speed. I think though that compression level could swing that dramatically the other way - those archives used high compression, I'd imagine you could be stuck for IDE throughput with an archive that uses low or no compression...

[fishy_fiz]

I guess my perspective was more for a faster system. An '030 I guess is still slow enough for the cpu to be as much of an issue is the interfaces throughput. Using a real scsi drive or RAM is much faster for compression/decompression than the internal ide interface, even on the same machine, which shows that cpu isnt as much of a bottleneck as the interface itself.

[Mizar]

fishy fiz:

Actually it's quite accurate, for an 030 system, that I mentioned.  It's sounds like you're talking about extracting and compressing both from and to the HD.  I usually extract to RAM, then copy the contents to disk.  In addition to a speed increase over HD, though not huge, I usually do it that way because the destination path is more manageable to control with LZX.   I haven't regularly worked with archives of 50MB+.  I guess that depends how fast you expect it to still be with archives that huge.  But I can tell you LZX is significantly faster than something like UnArc (from OS3.9).  CPU time is the slower factor with any decent amount of compression, and that's with an 030@40 and 882@50.  I don't know what CPU you're using, 060, PPC?

Franko:

I was wondering that about the SCSI.device too.  Interesting :-).

[mongo]

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

scsi.device was named scsi.device for software, such as HDToolBox that by default assumes hard drives are using scsi.device.

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

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

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