maxtransfer setting of 0x1fe00

[videofx]

I am using a 4GB CF with CWB 3.1. I am using a SCSI to IDE adapter to connect the IDE CF adapter. Everything seems to be working fine with the default HDTools partitions.

They say if you are using IDE then maxtransfer setting of 0x1fe00 should be used.

Does this apply if I am using SCSI to IDE adapter?

Thanks!

[Loedown]

I believe it does yes, I know I used it for my SCSi to IDE adapter and no problems or issues, if I also recall rightly it's to do with the block size of data sent rather than a speed, a buffer size if you will.

[Jope]

It usually is not needed if the connection to the Amiga is SCSI. For the reason, read the IDE & Max transfer sticky thread in this forum.

[Cymru]

On very old IDE drives this was important; some swear that CF cards (being IDE devices) do also, but unless the laws of physics differ in my home than the rest of the world, it has never mattered. Fat95 devices on the Amiga do screw up if the transfer rate is set too high (USB thumb drives) but this is a Fat95 implementation -- set the massstorage.class to 64K in Poseidon.

[thomas]

It's exactly the other way round: very old drives work correctly and new drives (like CF cards) don't. That's because the ATA specs have changes since and the Amiga's IDE driver relies on the old specs.

As Loedown already pointed out, MaxTransfer is not a transfer rate but a transfer chunk size. For IDE/ATA the buffer has to be split into 128k chunks anyway. By specifying small MaxTransfer you only tell the file system to do it because the IDE driver does not do it right.

[Cymru]

Excuse me, "max transfer chunk."

Odd that my Amiga's don't care about the "max transfer chunk" and yours do. I have used IDE drives from the late 1980's up to SATA 2TB and SSD drives along with a dozen or more CF's and SD cards without issue and the Maximum Transfer Data Size has never mattered. As the Chinese say, "Black cat, white cat, does it matter if they catch mice?"

[fitzsteve]

Originally Posted by Cymru

Excuse me, "max transfer chunk."

Odd that my Amiga's don't care about the "max transfer chunk" and yours do. I have used IDE drives from the late 1980's up to SATA 2TB and SSD drives along with a dozen or more CF's and SD cards without issue and the Maximum Transfer Data Size has never mattered. As the Chinese say, "Black cat, white cat, does it matter if they catch mice?"

Here's a quick easy test for you, use the default HDToolbox Max Transfer and setup a CF card with that. Try to play some WHDload Games that use Disk images or have large files.

They wont load and will compain about DOS error 205 (can't find file Disk....) You know why? because that file is becoming corrupt whilst loading due to incorrect max transfer setting

You might not notice it during normal OS routines but when you load files over a certain size this is when the errors show up.

[thomas]

Originally Posted by Cymru

Excuse me, "max transfer chunk."

Odd that my Amiga's don't care about the "max transfer chunk" and yours do. I have used IDE drives from the late 1980's up to SATA 2TB and SSD drives along with a dozen or more CF's and SD cards without issue and the Maximum Transfer Data Size has never mattered. As the Chinese say, "Black cat, white cat, does it matter if they catch mice?"

Perhaps you forgot to mention some details about your system? I am quite sure that you don't use a 2 TB drive with the original IDE driver because it has a 4 GB limit.

[john1979]

Originally Posted by Cymru

Excuse me, "max transfer chunk."

Odd that my Amiga's don't care about the "max transfer chunk" and yours do. I have used IDE drives from the late 1980's up to SATA 2TB and SSD drives along with a dozen or more CF's and SD cards without issue and the Maximum Transfer Data Size has never mattered. As the Chinese say, "Black cat, white cat, does it matter if they catch mice?"

On my Amiga 1200, Fast File System, 4GB CF over IDE. Leaving the transfer settings at default caused lots of corruption. It certainly wasn't my imagination.

[alexh]

If you're using a SCSI->IDE bridge then you should not need to limit max transfer. For all intents and purposes you are connecting to a SCSI device which should not suffer from problems (unless there is a bug in the bridge).

When connecting an ATA-IDE drive to an Amiga via the native IDE interface, setting the MAX TRANSFER effectively limits the maximum value the filesystem/IDE driver will try to use in the "Sector Count" field of the ATA commands.

This Sector Count field has changed over the years since the Amiga IDE drivers were written.

[thomas]

Originally Posted by alexh

When connecting an ATA-IDE drive to an Amiga via the native IDE interface, setting the MAX TRANSFER effectively limits the maximum value the filesystem/IDE driver will try to use in the "Sector Count" field of the ATA commands.

This Sector Count field has changed over the years since the Amiga IDE drivers were written.

This is not completely right.

Firstly the file system does not send ATA commands. The file system (e.g. PFS3) tells the driver (e.g. scsi.device) to read or write data. This is the same for all kinds of massstorage devices, be it ATA, SCSI or whatever. The driver then forms the needed hardware command (if hardware is in charge, which is not the case for a RAM disk or for a virtual harddisk).

In case of ATA, if the amount of data requested is larger than 128k (256 blocks) the driver automatically splits the request into several ATA commands because the used ATA commands have only one byte as Sector Count.

Secondly it is not the Sector Count field which has changed but the status of the hardware registers as set by the device. Formerly the current address was changed to the next block. In the new specs this is not necessary any more and new devices don't to it. But scsi.device relies on it and therefore fails to write the second and following chunks to the right places.

By setting MaxTransfer to 128k or less you just move the splitting from the driver to the file system. If the file system requests less then 128k at once, the driver is not required to split the request and does not fail to write the data correctly.

[alexh]

Originally Posted by thomas

Formerly the current address was changed to the next block. In the new specs this is not necessary any more and new devices don't to it. But scsi.device relies on it and therefore fails to write the second and following chunks to the right places.

Ah, so when the IDE driver had to split the incoming commands over multiple ATA commands it used a part of the returned Status as the start address of the next command which on newer ATA devices need not be valid? Yeah I do seem to remember either yourself or Toni Willen explaining this in the past.

Did someone every try to patch the Gayle scsi.device to fix this bug? (Not that it really matters)

[thomas]

Originally Posted by alexh

Ah, so when the IDE driver had to split the incoming commands over multiple ATA commands it used a part of the returned Status as the start address of the next command which on newer ATA devices need not be valid? Yeah I do seem to remember either yourself or Toni Willen explaining this in the past.

Yes, that's right. Toni did find it out.

[videofx]

Thomas so even if I use SCSI to IDE bridge I should still set max xfer to x1fe00?

Thanks

[thomas]

It does not hurt. Perhaps at some time in the future you might need to connect the HDD to the internal IDE port and then it is good to have it. As long as it is connected to SCSI it should not have a problem.

[Cymru]

Originally Posted by thomas

Perhaps you forgot to mention some details about your system? I am quite sure that you don't use a 2 TB drive with the original IDE driver because it has a 4 GB limit.

Two CSPPC A4000Ts.

[Bamiga2002]

Originally Posted by Cymru

Two CSPPC A4000Ts.

You won the lottery or something?

[Loedown]

Sorry Cymru but I would take Thomas and Toni Wilen's word over yours, if you've not had any issues then great but for the sake of correct data I would set the max transfer as suggested.

[Toni Wilen]

It is not 100% guaranteed to have any max transfer problems.

Some drives still support obsoleted ATA-1 feature that ROM IDE driver requires if transfer needs to be split.